FWIW: I didn't produce the content presented here (the outline from Edmond Lau's book). I've just copy-pasted it from somewhere over the Internet, but I cannot remember what exactly the original source is. I was also not able to find the author's name, so I cannot give him/her the proper credits.
“Computer Science is the first engineering discipline in which the complexity
of the objects created is limited solely by the skill of the creator, and not
by the strength of raw materials.”
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.
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:
