Growing Object
Oriented
Software Guided
By Tests.
Introdução Uma leve introdução de como testes
podem criar aplicações confiáveis e ainda sim com
design fácil de ser alterado e expandido e o porque
da necessidade de ser escrever o teste antes.
TDD - Presentation
Testes feitos antes do código em si.
Confiabilidade e flexibilidade.
Usado especialmente em agile software,
práticas XP e Scrum projects.
Desenvolvimento de software como aprendizado.
“Antecipar as alterações não antecipáveis
(To antecipate unantecipated changes)”
TDD - Learning
TDD - Benefits
Ideia clara do próximo passo.
Escrever componentes pouco
acoplados.
Detectar erros quando “frescos” na
mente.
TDD - Benefits
Fazer apenas o necessário.
Deploy contínuo.
Lógica separada do design do código
“Never write new functionality without a failing test”.
TDD - Refactoring
Pensar apenas no local da alteração e agir
somente nesse local.
Confusão entre conceitos com refactoring
com redesign.
Qualidade interna e
externa
Níves de testes
Acceptance: O sistema está em completo
funcionamento?
Integration: O código funciona contra um
código que não se pode alterar?
Unit: Nossos objetos fazem a coisa certa?
Eles estão funcionando?
Ciclo de feedback interno e
externo
Write a failing
acceptance test
Write a failing unit test
Refactor
Make the test pass
unit integration end-to-end
Internal quality
Am
ount
of fe
edback
Extenal quality
TDD com objetos
Diferenciar os papéis, as responsabilidades e
os colaboradores.
Algumas técnicas como CRC cards podem
ser usadas para reprensentar os papéis.
Coupling and cohesion
Acomplamento
Alto acoplamento: Quando altera-se um
objetos e há necessidade de alterar outros.
Baixo acoplamento: Quando altera-se
objetos e consequentemente, com pouca ou
sem necessidades de alterar outros.
Coupling and cohesion
Coesão
Em OO é quando uma classe tem um
propósito bem claro e definido.
TDD – web of objects
Em geral, um objeto deve ter apenas uma
ligação com o seu “vizinho”.
Siga as “mensagens”: em Java por
exemplo, para identificar-se os papéis do
sistema usa-se o conceito de interfaces.
Pode-se usar CRC cards para tentar definir
as funcionalidades de um sistema.
CRC card Game Engine
Displays game state Renderer
Updates game state Animator
Resolves collisions Collision Detector
TDD with objects
Tell, don’t ask.
Métodos que ao invés de “perguntarem”
para a classe, simplesmente “dizem” o que
a classe deve fazer.
Ao invés de usar isso
((EditaSaveCustomizer) master.getModelisable()
.getDockablePanel()
.getCustomizer())
.getSaveItem().setEnabled(Boolean.FALSE));
Use isso
master.allowSavingOfCustomisations();
TDD with objects
But sometimes ask.
Algumas vezes é necessário perguntar a
classe o que fazer.
Ao invés de usar isso
public void reserveSeats(ReservationRequest request) {
for(Carriage carriage : carriages) {
if (carriage.getSeats().getPercenReserved() <
this.percentReservedBarrier) {
....
}
}
Use isso
public void reserveSeats(ReservationRequest request) {
for(Carriage carriage : carriages) {
if (carriage.hasSeatsAvailableWithin(
this.percentReservedBarrier)) {
....
}
}
Unit-test and collaborators
TDD - TOOLS
Junit4
Jmock 2
Hamcrest Matchers
O livro Growing Object-Oriented Software, Guided
by tests inicialmente mostra uma pequena
introdução sobre como crescer de forma
“incremental” usando testes e as principais
ferramentas do mercado.
Conclusão
Livro Growing Object-Oriented Software, Guide By Tests by
Steve Freeman and Nat Pryce. October 2009.
All of ilustrations inside this presentation had taken from the
book above mentioned.
CRC model from
http://www.agilemodeling.com/artifacts/crcModel.htm.
Law of Demeter from
http://en.wikipedia.org/wiki/Law_of_Demeter.
Referências
Top Related