Skip to content

Instantly share code, notes, and snippets.

Avatar

Rondy Sousa rondy

View GitHub Profile
View an_ode_to_boring_code.md

Sometimes a Controller is Just a Controller

Abstract

You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!

But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.

But doubt lingers: what if they're right?

View acceptance_tests.md

Organização de testes de aceitação

Sabemos que testes de aceitação (ou "feature tests", no linguajar do Rspec) são os testes mais próximos da especificação que é projetada entre developers, analistas de negócios, stakeholders etc. No paradigma ágil, esses testes deveriam refletir os critérios de aceite definidos em uma user story (aqui, sem entrar no mérito da pirâmide de testes).

Há uma questão que parece ser recorrente durante o desenvolvimento desses testes. Como organizamos os arquivos correspondentes a esses testes?

Eis algumas dúvidas que podem surgir:

  • A localização física e o nome dos arquivos deveriam refletir a organização física ou as capabilities do software? Ex:
@rondy
rondy / testing_front_end_rspec_capybara.md
Created Nov 14, 2015 — forked from juliocesar/testing_front_end_rspec_capybara.md
Testing front-end for a Sinatra app with RSpec and Capybara
View testing_front_end_rspec_capybara.md

Testing front-end for a Sinatra app with RSpec and Capybara

I've used Cucumber quite a bit on my last job. It's an excellent tool, and I believe readable tests are the way to the future. But I could never get around to write effective scenarios, or maintain the boatload of text that the suite becomes once you get to a point where you have decent coverage. On top of that, it didn't seem to take much for the suite to become really slow as tests were added.

A while ago I've seen a gist by Lachie Cox where he shows how to use RSpec and Capybara to do front-end tests. That sounded perfect for me. I love RSpec, I can write my own matchers when I need them with little code, and it reads damn nicely.

So for my Rails Rumble 2010 project, as usual, I rolled a Sinatra app and figured I should give the idea a shot. Below are my findings.

Gemfile

@rondy
rondy / git_categories.md
Last active May 14, 2019
Categorizing git commit messages
View git_categories.md

Categorizing git commits and how it affects the test suite

  • If the applied change is a "feature creation" or a "feature evolution" (i.e., it changes the current system behavior), then:
    • It should include a system/acceptance test, or, in case it already exists, ensure that the test will reflect the change.
    • It can optionally include a unit test case, since not every change requires a unit test.
    • A "feature creation" will probably include a good amount of system test and a few of unit tests.
      • Lots of unit test might be a design smell.
    • A "feature evolution" (i.e., changing a feature that already exists) will probably include just enough system test and a good amount of unit tests.
      • Lots of system test might be a design smell.
  • If the applied change is a refactoring, then:
View oop-design-workshop.md

OOP Design workshop

Part 1

  • Initial step: Plan the user story (goals, acceptance tests).
  • Getting familiar with the CEP SOAP API.
  • Test as a documentation for external API usage.
    • Introduce spec/use_cases.
  • byebug as a tool for API learning & discovering.
  • Don't be bothered about duplication while enough use cases are not fully covered yet.
View chain.rb
# encoding: utf-8
module ChainOfResponsibility
attr_writer :successor
def can_handle_request?(request); end
def do_handle(request); end
def handle_request(request)
if can_handle_request?(request)
View organic.md

ORGANIC FRUIT'S WAY

  • Escreva um test case que reflita a interação sob a perspectiva do usuário (entrada => processo => saída);
  • Comece a implementação pela camada mais próxima do usuário ('controller', 'worker', 'views'). Caso a camada ainda não exista, comece pelo próprio spec file;
require 'rails_helper'

feature 'Awesome feature' do
  scenario 'User can do something awesome that will bring some valuable for him' do
View commit-srp.md

Rondy Sousa (@plataforma.rondy): @brunno.santos, puxando o gancho no papo das descrições de MR, uma coisa que a gente costuma fazer é manter a descrição do MR no commit principal (title+descripton do MR batendo com o do commit).

A vantagem é que a motivação/propósito do MR ("pois o bundle da product já tem esse link salvo no banco") fica documentada no histórico do controle de versão (e agnóstico da plataforma de code review).

Brunno dos Santos (@brunno.santos): @plataforma.rondy interessante esse esquema que vcs usam de colocar a descrição no commit, mas o problema é definir qual é o commit principal, as vezes nem temos um. Como vocês lidam com isso?

Rondy Sousa (@plataforma.rondy): @brunno.santos, A gente faz squash dos commits antes de fazer merge no master, com o commit resultante recebendo o título + descrição do MR.

Na grande maioria das vezes, commits separados representam (ou deveriam representar) apenas "snapshots" de work-in-progress do MR. No momento do merge, eles acabam não acre

View request_vs_controller.md

Requests specs x controller specs

Despite of they feel to be almost the same, there is a subtle difference between them: In request specs, you can exercise the full stack of a HTTP request (from routing to the view layer, so to speak).

Request specs also allows you to access more than one endpoint at a time, so you are able to test a whole scenario’s flow, whereas in controller specs you can exercise only one endpoint per test case (i.e., a single controller’s action).

# request spec
specify do
  get '/my-first/enpoint'
You can’t perform that action at this time.