TDD depois do mainstream. E agora?

TDD depois domainstream.

E agora?

Mauricio [email protected]

www.aniche.com.br

Saturday, August 31, 13

mailto:[email protected]





Nós amamos métodos ágeis

(e TDD mais ainda)!


Na academia...


Mas tudo faz sentido...Será que vale a pena

estudar melhor?


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.


Nossa intuiçãopode estar errada!


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


1: O que é TDD?


O que é TDD?

• Qual a melhor definição sobre TDD?

• “Prática onde o desenvolvedor escreve testes antes da implementação”

• “Prática onde o desenvolvedor escreve testes antes da implementação, e os usa para guiar seu projeto e implementação”


Test-driven development (TDD) is the craft of producing automated tests for production code, and using that

process to drive design and programming. For every tiny bit of functionality in the production code, you first

develop a test that specifies and validates what the code will do. You then produce exactly as much code as will

enable that test to pass. Then you refactor (simplify and clarify) both the production code and the test code.

www.agilealliance.org/programs/roadmaps/Roadmap/tdd/tdd_index.htm


http://www.agilealliance.org/programs/

http://www.agilealliance.org/programs/

E aí? Depende...


2. TDD como prática de testes


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.


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.


Como prática de teste



• Tem vantagem?



• Tem vantagem?

• Código “nasce testado”



• Tem vantagem?


• Menos viés na hora de testar



• Tem vantagem?


• Menos viés na hora de testar

• Você cobre mais caminhos


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

estudo.


3. TDD como prática de design


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.


A academia estudou isso também...



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.


Outras pessoasjá perceberam queos 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


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?


Um Estudo Qualitativo

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



• ~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).





• 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)



a prática de TDD não guia o desenvolvedor para um bom

projeto de classes de forma automática!



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.



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.


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)





• classes não podem ser complicadas, senão fica difícil testar)

• Maneira barata de validar seu projeto de classes


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.


[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); } }


[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?


Bloated constructor [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.. } }


dependencies,notifications,adjustments

Freeman, Pryce. Growing Object-Oriented Software, Guided by Tests. 2009.


" [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); }

If ’s e switchesVocê tem testes muito parecidos que geram resultados diferentes? Quando olha a implementação, ela tem um if ou switch?


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


Métodos privados?

• Devo testá-los?

• O que isso significa?


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.


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.


Padrões de Feedback



4. Erros comuns


Erros comuns

Aniche, Gerosa. Most Common Mistakes in TDD Practice:Results from an Online Survey with Developers. 2010, ICST.


Erros comuns

• 45% dos desenvolvedores disseram que esquecem de refatorar constantemente.



Erros comuns


• 40% afirmam que fazem uma refatoração em outro trecho de código durante uma sessão de TDD.



Erros comuns



• 20% não começam pelo teste mais simples possível.



Erros comuns



• 20% não começam pelo teste mais simples possível.

• 35% não fazem baby steps.



Baby Steps


Baby Steps

• Na minha opinião, uma das partes mais mal entendidas pela comunidade.


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).


Baby Steps


Baby Steps

• Não faço baby steps o tempo inteiro; mas fico feliz de saber que posso fazer, se precisar.


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!


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.


Qual a diferença de escrever o teste antes?• Fazendo ou não TDD, eu faço ciclos

pequenos.



5. Produtividade


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?


6. Outras maluquices


ATDD


ATDD

• A ideia é boa, mas...


ATDD


• Nunca vi ninguém fazendo.


ATDD


• Nunca vi ninguém fazendo.

• Os desafios são grandes.


E esse tal de BDD?


E esse tal de BDD?

• O pensamento BDD me agrada.


E esse tal de BDD?

• O pensamento BDD me agrada.

• As ferramentas que “implementam” não. Não me agrada esses “testes em linguagem natural”.


7. Ensino de TDD


Como aprendo TDD?


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.




• 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.


“Muito melhorque Crepúsculo!”

NY Times

http://www.tddnomundoreal.com.br

“De tirar o fôlego!”Washington Post

“Um thriller fascinante!”

Miami Herald




Alura!


http://www.codesheriff.com




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

• CodeSheriff: www.codesheriff.com




http://www.aniche.com.br

http://www.aniche.com.br

http://www.alura.com.br

http://www.alura.com.br

http://www.casadocodigo.com.br

http://www.casadocodigo.com.br

http://www.caelum.com.br

http://www.caelum.com.br



Technology

TDD depois do mainstream. E agora?