Profissionais TI - Pra quem respira informação

Olá PTIs!

Vinicius Quaiato e eu já demos uma mencionada em TDD aqui no ProfissionaisTI. Mas para relembrar, utilizando a prática “baby steps” temos os seguintes procedimentos:

• Escreva um teste que falhe;
• Escreva um código (rudimentar) para o teste;
• Faça o teste passar;
• Deixe o código “cheirando bem” (refactoring);
• Volte para o primeiro procedimento.

O TDD é focado em testes unitários, onde você isola um modelo (por exemplo) e monta-o de acordo com os testes que você escrever. Quando você tiver um determinado número de modelos, aí você testa a integração entre eles, e assim por diante.

Fazendo uma analogia, isso é mais ou menos como construir o software “de dentro para fora”, onde partimos escrevendo testes específicos (unitários) e depois vamos abrangendo outras regiões do sistema (integração, funcional, aceitação, etc). Já em BDD (Behavior-Driven Development) podemos dizer que o software é desenvolvido “de fora para dentro”, onde os testes são construídos baseados nos requisitos do cliente ou em um roteiro de aceitação (também conhecidos por estórias).

Esta prática é semelhante ao TDD: testes são escritos primeiro, funções depois; O diferencial está que BDD aborda o comportamento e o resultado como um todo, não preocupando-se necessariamente com as classes, métodos e atributos de forma isolada.

Mas então qual usar? TDD ou BDD?

Essa era a minha dúvida. E demorou até cair a ficha 😀

Depois de uma boa conversa com o @andrewsmedina, captei que pode-se utilizar os dois! Claro! Garanta que a aplicação está indo de acordo com o teste de aceitação escrito, e garanta que a escrita de determinada classe esteja de acordo com os testes unitários criados.

Onde trabalho utilizo da seguinte maneira:

• Escrevo estórias para determinada tarefa;
• Escrevo estas estórias em forma de testes. Estes testes podem ser classificados como funcionais (no meu caso testo as views do Django, mas isso pode variar de acordo com a aplicação);
• E através de “baby step” e unit, crio testes isolados para os modelos, formulários, views, etc.

Testes de comportamento tendem a levar mais tempo para serem executados, esta é outra razão para termos sempre em mãos os testes unitários.

Até hoje não ví uma maneira “silver bullet” de trabalhar com testes automatizados. Encaro da seguinte maneira:

• Está cobrindo o teu sistema?
• Está guiando de forma correta o seu desenvolvimento?
• Está sendo escrito da forma correta (não deixando bugs passarem despercebidos, por exemplo)?

Se todas as respostas forem sim, acredito que esteja sendo feito da maneira adequada.

Referências

• Superfície Reflexiva – Algumas considerações sobre TDD e BDD;
• Portal do Arquiteto – Automação de testes funcionais e de aceitação;
• Aprendendo Django no Planeta Terra – Programando com Testes Automatizados;
• Maré de Agilidade: BDD e TDD;
• Danilo Sato – Introduzindo Desenvolvimento Orientado por Comportamento.

E você? Como utiliza testes automatizados no desenvolvimento dos seus softwares?

Até a próxima…