Concrete Logo
Hamburger button

Falando de TDD

  • Blog
  • 17 de Outubro de 2011
Share

[fblike]

 

Pois é… sobre a importância de testar e dos testes unitários acho que todos concordamos.

Mas e sobre TDD? A gente sabe que é bom. Só que muita gente fala disto mas na prática nem todos adotam. É difícil fazer TDD? Será que estão errados os que não fazem? E quem faz, deve fazer sempre?

Hoje pela manhã tuitei sobre as dificuldades que tenho com TDD:
https://twitter.com/#!/lucabastos/status/125903882953043969

Aí vão respostas de alguns amigos aos quais agradeço (passem o mouse para ler):
@diegorv, @blackbnu, @VitorioRamon, @blackbnu, @rodrigoospinto, @rodrigoospinto, @mauricioaniche, @rodrigoospinto, @diegorv, @marcelotozzi, @blackbnu, @leandro_storoli, @leandro_storoli, @fnmunhoz, @VitorioRamon, @VitorioRamon, @VitorioRamon, @VitorioRamon, @adrianoalmeida7, @VitorioRamon@adrianoalmeida7, @rgalba, @wbotelhos, @srsaude, @alberto_souza

Ficou claro que não sou só eu com dificuldades. O @leandro_storoli listou exatamente o que penso. Pela segunda resposta do @rodrigoospinto, desconfio que gente como eu, deveria praticar mais dojos de códigos para aumentar a fluência.

Ainda sob a impressão do tech talk do Fábio Miranda sobre TDD e o livro GOOS, resolvi discutir mais este assunto até mesmo para realinhar idéias.

O Peter Sergeant blogou recentemente dizendo que não é sempre que se deve fazer os testes antes e isto causou um reboliço nos comentários: Test-Driven Development? Give me a break…. Vale a pena ler tudo inclusive os comentários (o @mauricioaniche comentou lá).

Vamos começar pelo princípio:

Test Driven Design ou projeto guiado por testes significa escrever o teste antes. A gente cria um teste que falha e completa o código só para fazer o teste passar. Então refatora e volta ao início.

Baby steps, passinhos curtos, TDD exige isto. Parece chato e improdutivo para muitos programadores experientes. Aliás é mesmo principalmente para quem não está acostumado.

Esta coisa de passinhos curtos depende da experiência do programador. Alguém que já conheça o domínio pode avançar mais rápido. Há ótimos programadores não fazem TDD de jeito algum apesar adeptos de testes e refatoração.

https://vinkamat.com/2011/tdd-unit-testing-and-benefits

 

A importância de começar pelos testes foi reconhecida muito antes do que muita gente imagina. Em 1968 o comitê de ciências da NATO (ou OTAN), promoveu uma conferência na Alemanha chamada de Working Conference on Software Engineering (juro que não sabia que naquela época já se usava este termo engenharia de software). O relatório da conferência foi publicado em 2001 e o PDF pode ser baixado.

Lá na página 32, o americano Alan Perlis, um dos pioneiros das linguagens de programação e primeiro ganhador do Turing Award,  escreve:

I’d like to read three sentences to close this issue.

  1. 1. A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.

  2. 2. A simulation which matches the requirements contains the control which organizes the design of the system.

  3. 3. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact with simulation models, but that in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulation model controlling, as it were, the place and order in which these things are done.

 

Isto fiquei sabendo no blog do Steve Freeman. Como bem disse o co-autor do livro Growing Object Oriented Software, Guided by Tests, está tudo na nossa história, só precisamos ser capazes de encontrar.

Os que costumam testar mas não fazem TDD, poderiam se beneficiar se o adotassem?

Com certeza no início perderiam produtividade. Pelo menos é o que acontece comigo. Fora que às vezes me sinto fazendo testes bobos descartáveis só para começar pelos testes. Quanto mais a gente conhece bem o domínio, menos paciência tem com os tais baby steps.

Pode parecer fácil e muita gente diz que é. Eu acredito que depende inclusive da personalidade do desenvolvedor. Em princípio, acho que vale a pena tentar. Principalmente quando a gente se depara com um sistema em um domínio novo em que para entender precisamos de baby steps. O duro como bem disse o @leandro_storoli, é saber exatamente o que testar e perceber quais testes são relevantes de forma isolada.

Nesta busca de encontrar um meio de mais rapidamente voltar a se sentir produtivo enquanto tenta fazer TDD, vale a pena buscar socorro com quem já passou desta fase.

Junto abaixo alguns links interessantes:

Steve Freeman e Nat Pryce, autores do livro acima conhecido como GOOS, são dois pioneiros do desenvolvimento ágil na Inglaterra. Participaram também da criação do conceito de objetos mocks e desenvolveram a conhecida bibloteca JMock. Isso ainda nos primórdios do Java e do Ruby. Este livro foi revisto e comentado por muita gente:

Então…

Falar de TDD nunca é demais. Há muito o que discutir. Principalmente para gente do tipo macaco velho como eu que tem mais dificuldades para se adaptar.

Daí a importância do tech talk de TDD do Fábio Miranda que abordou o livro GOOS apresentado no blog passado em https://blog.concretesolutions.com.br/2011/10/tech-talk-sobre-tdd-e-o-livro-goos/.

 

E você, faz testes e sempre começa pelos testes como recomendam as práticas de TDD?

Sempre mas sempre mesmo começa pelos testes?

É como eu, que apesar de favorável ao TDD, quando precisa implementar um algoritmo, acha mais fácil se concentrar no fluxo lógico ao invés de iniciar pelos testes?

Ou concorda com o Maurício Aniche, evangelista de TDD mas admite que é uma ferramenta que o desenvolvedor deve identificar os momentos adequados para usar e quando pode dispensar?

 

Comentem!