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