Minha palestra sobre TDD no Serra StarTec 3014, em Lages, SC.

1. Test-Driven Development
serve pra mim?
Maurício Aniche
mauricio.aniche@caelum.com.br
www.aniche.com.br
@mauricioaniche

2. Nós amamos
métodos ágeis
(e TDD mais ainda)!

3. Na academia...

4. Mas tudo faz sentido...
Será que vale a pena
estudar melhor?

5. Homens de nível educacional mais alto apresentaram
maior quantidade de sintomas pseudoneuróticos do
que aqueles que haviam recebido menos instrução;
!
Homens do meio rural mantiveram-se mais bem-humorados
durante a guerra do que os soldados
recrutados nas cidades;
!
A capacidade dos homens do Sul (dos EUA) para
suportar o calor era maior do que as dos soldados do
Norte.
!
Lazarsfeld, P. "The American Soldier - An Expository Review", 1949.

6. Mas nós conhecemos
bem de software, não
tem como errarmos!

7. O mito do
programador 10x
Bossavit, L. The Leprechauns of Software Engineering, 2012.

8. O que é TDD?
• Qual a melhor definição sobre TDD?
• É uma prática de testes?
• É uma prática de design?
Test-Driven Design

9. E aí? Depende...

10. TDD como
prática de testes
• Quando o desenvolvedor pratica TDD com
o mero objetivo de aumentar a cobertura
de testes e garantir qualidade externa.

11. A academia gosta disso...
Aniche. Como a prática de TDD influencia projetos de classes em sistemas
orientados a objetos. Dissertação de mestrado, 2012.

12. Como prática de teste
• Tem vantagem?
• Código “nasce testado”
• Menos viés na hora de testar
• Você cobre mais caminhos

13. Mas esse, com certeza,
não foi meu foco de
estudo.

14. Como prática de design
• É dito que com a prática de TDD, seu
projeto de classes torna-se melhor.
• Muitos autores (Kent Beck, Martin Fowler,
Robert Martin, Michael Feathers, Steve
Freeman, ...) falam sobre isso.

15. A academia estudou
isso também...
Aniche. Como a prática de TDD influencia projetos de classes em sistemas
orientados a objetos. Dissertação de mestrado, 2012.

16. Mas é tão mágico
assim?
• Em 2010, durante um evento ágil,
participantes não souberam bem se
expressar quando o assunto era “como
TDD influencia no projeto de classes”.
Aniche, Ferreira, Gerosa. What Concerns Beginner Test-Driven Development
Practitioners: A Qualitative Analysis of Opinions in an Agile Conference. 2011
Brazilian Workshop on Agile Methods, WBMA 2011.

17. Outras pessoas
já perceberam que
os efeitos de TDD
não são tão naturais
assim!
M. Siniaalto and P. Abrahamsson, “Does test-driven development improve the program
code? Alarming results from a comparative case study,” Balancing Agility and
Formalism in Software Engineering, vol. 5082, pp. 143–156, 2008. #
[Online]. Available: http://dx.doi.org/10. 1007/978- 3- 540- 85279- 7_12

18. A última revisão
sistemática sobre
o assunto então…
Munir, Moayyed, Petersen. Considering rigor and relevance when
evaluating test driven development: A systematic review, 2014.#

19. Mas como descobrir?
• Uma das partes mais desafiadores (e
legais!) da ciência é justamente essa: como
bolar um experimento controlado que
simule corretamente uma situação real?

20. Um Estudo Qualitativo
• ~30 desenvolvedores da indústria
• Grande experiência com desenvolvimento
de software (só 20% tinham menos de 2
anos de experiência, 30% entre 6 e 10
anos).
• Praticam TDD há algum tempo (50%
pratica entre 1 a 3 anos)
Aniche, Gerosa. How the Practice of TDD Influences Class Design in
Object-Oriented Systems: Patterns of Unit Tests Feedback. SBES 2012.

21. a prática de TDD não guia o
desenvolvedor para um bom
projeto de classes de forma
automática!
Aniche, Gerosa. How the Practice of TDD Influences Class Design in
Object-Oriented Systems: Patterns of Unit Tests Feedback. SBES 2012.

22. TDD dá retorno constante
sobre os possíveis problemas
existentes no atual projeto de
classes. É tarefa do
desenvolvedor perceber esses
problemas e melhorar o
projeto de acordo.
Aniche, Gerosa. How the Practice of TDD Influences Class Design in
Object-Oriented Systems: Patterns of Unit Tests Feedback. SBES 2012.

23. Regra para a vida!
• “Se está difícil testar, é porque, provavelmente,
há um problema de projeto ou implementação
em seu código”.
• O segredo é perceber, o mais rápido
possível, o momento em que escrever o
teste passou a ser uma tarefa difícil.

24. Isso quer dizer que...
• A busca pela testabilidade faz com que você
busque projetos de classe mais simples
• instanciar uma classe, e fazer uso de
comportamentos deve ser fácil
• classes não podem ser complicadas,
senão fica difícil testar)
• Maneira barata de validar seu projeto de
classes

25. Quer ver um exemplo?
• Um teste sempre tem 3 partes: um cenário,
uma ação, e uma validação.
• Se escrever o cenário para o teste está
complicado, provavelmente tem algo
errado.

26. [TestFixture]
public class GeradorDeNotaFiscalTest
{
[Test]
public void DeveGerarUmaNotaFiscal {
var gerador = new GeradorDeNotaFiscal();
var nf = gerador.gera(fatura);
Assert.AreEqual(fatura.Valor * 0.2,
nf.ValorImposto);
}
}
- hmm... ele depende de algo?
- deve receber uma fatura?
- o nome do método está claro?
- o que ele deve retornar?

27. Classes acopladas
[TestFixture]
public class MessageProcessorTest
{
// atributos com as dependencias que serao mockadas
!
[SetUp]
public void SetUp() {
// criando mocks
}
[Test]
public void ShouldDoSomething()
{
var processor = new MessageProcessor(unpacker, auditer,
locationFinder, counterPartyFinder, domesticNotifier,
importedNotifier);
!
processor.OnMessage(BuildSomeSpecificRawMessage());
// algumas assercoes aqui..
}
}

28. dependencies,
notifications,
adjustments
Freeman, Pryce. Growing Object-Oriented Software, Guided by Tests. 2009.

29. # [Test]#
# public void CalculaISS() { #
# # var valor = new CalculaImposto().ParaValor(1500);#
# # Assert.AreEqual(1500*1.2, valor);#
}#
!
# [Test]#
# public void CalculaICMS() { #
# # var valor = new CalculaImposto().ParaValor(6000);#
# # Assert.AreEqual(6000*1.3, valor);#
}#
Muitos testes?
Você tem testes muito parecidos que geram resultados
diferentes? Quando olha a implementação, ela tem um if ou
switch?

30. Padrões de projeto podem
ajudar (de novo)!

31. Métodos privados?
• Devo testá-los?
• O que isso significa?

32. Olhando pros asserts
• A quantidade de asserts também pode
indicar problemas de qualidade no código
de produção.
Aniche, Oliva, Gerosa. What do the Asserts in a Unit Test Tell Us About
Code Quality? A Study on Open Source and Industrial Projects. CSMR 2013.

33. Mas como?
• Quanto maior a quantidade de “diferentes
instâncias que recebem um assert”, maior a
chance do código de produção ter
problemas, em termos de complexidade,
linhas de código, número de métodos
invocados.
assertEquals(a.Propriedade, “bla”);
assertEquals(b.Propriedade, “ble”);
Aniche, Oliva, Gerosa. What do the Asserts in a Unit Test Tell Us About
Code Quality? A Study on Open Source and Industrial Projects. CSMR 2013.

34. Padrões de Feedback
Aniche, Gerosa. How the Practice of TDD Influences Class Design in
Object-Oriented Systems: Patterns of Unit Tests Feedback. SBES 2012.

35. Erros comuns
• 45% dos desenvolvedores disseram que
esquecem de refatorar constantemente.
• 40% afirmam que fazem uma refatoração
em outro trecho de código durante uma
sessão de TDD.
• 20% não começam pelo teste mais simples
possível.
• 35% não fazem baby steps.
Aniche, Gerosa. Most Common Mistakes in TDD Practice:
Results from an Online Survey with Developers. 2010, ICST.

36. Baby Steps
• Na minha opinião, uma das partes mais mal
entendidas pela comunidade.
• Ser simples, não é ser simplório (e nem
estúpido).

37. Baby Steps
• Não faço baby steps o tempo inteiro; mas
fico feliz de saber que posso fazer, se
precisar.
• Use sua experiência para decidir em que
momento o passo deve ser menor; ou
maior!

38. TDD 100% do tempo?
• Eu não pratico TDD quando:
• Meu projeto de classes já está bem
definido.
• A implementação já está clara na minha
cabeça.
• Testes de integração.

39. Qual a diferença de
escrever o teste antes?
• Fazendo ou não TDD, eu faço ciclos
pequenos.
Aniche. Como a prática de TDD influencia projetos de classes em sistemas
orientados a objetos. Dissertação de mestrado, 2012.

40. Sou menos produtivo?
• Se eu escrevo 100 linhas de produção,
amanhã escreverei 50 de teste e 50 de
produção. Sou menos produtivo?
• Qual a sua noção de produtividade?

41. ATDD
• A ideia é boa, mas...
• Difícil.
• Uma equipe nossa faz.
• Os desafios são grandes.

42. Como aprendo TDD?
• Pratique.
• Geralmente são 2 os problemas: aprender a
testar, e aprender boas práticas de
programação (OO, etc).
• Na hora de aprender a testar, a dificuldade
é sempre pensar em cenários. Comece
rascunhando uma lista.
• TDD é estranho, no começo. Mas depois
acostuma.

43. Boas práticas?
• Padrões para prática de TDD
• Padrões para testes de aceitação
Aniche, Guerra. *, PLoP e SugarLoaf PLoP.

44. TDD
Você é o desenvolvedor que usa TDD escondido?
I will look for you, I will find you, and I will kill you.

45. “Muito melhor
que Crepúsculo!”
NY Times
“De tirar o fôlego!”
Washington Post
“Um thriller
fascinante!”
Miami Herald
http://www.tddnomundoreal.com.br

46. tdd.caelum.com.br

47. aniche.com.br/
publications

48. Alura!

49. LAPESSC / IME-USP

50. Obrigado!
• Meu livro: www.tddnomundoreal.com.br
• Meu blog: http://www.aniche.com.br
• Cursos online do Alura: www.alura.com.br
• Casa do Código: www.casadocodigo.com.br
• Caelum: www.caelum.com.br
!