Recomendação sobre TDD

O Bruno Pereira comentou em post passado sobre a dificuldade que ele teve em adotar TDD:

“Já tentei algumas vezes escrever os testes unitários no começo, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de negócio.”

Notei em diversas consultorias que isso é muito comum por diversos motivos, o principal a meu ver é justamente entender como começa o código do teste, em dois extremos: se depois que definiu o fluxo de processo de negócio de alguma forma [como UML, CRC ou mesmo apenas com UC] ou se já começa algum esboço em código sem ter discutido bem como funciona totalmente o negócio.

A primeira abordagem, definir todo o processo primeiro, deixa a grande maioria dos desenvolvedores confortáveis já que é algo tradicional que vinhamos fazendo, mas o problema é que invariavelmente descamba para BDUF.

A segunda abordagem, que está ligada ao desenvolvimento iterativo e incremental, já deixa um sentimento de que “algo está faltando” em grande parte dos times que tenho trabalhado. A resistência maior é deixar um sentimento de que não preparamos a arquitetura adequadamente e essa pode sofrer um revés num futuro próximo, claro que isso é uma bobagem para quem conhece como TDD funciona, mas é algo comum que tenho notado e precisa ser desmistificado.

Note que não estou falando aqui do sistema inteiro, apenas uma funcionalidade, mesmo assim a mudança cultural de quebrar uma funcionalidade em tarefas e ir desenvolvendo com “passos de bebê” é algo que dificulta a adoção.

Como sanar essas deficiências?

Precisamos de uma forma que conversassemos sobre a funcionalidade inteira mas que me permita ir avançando e atualizando conforme eu vá entendendo melhor como funciona.

Tenho trabalhado essas deficiências nos últimos times que peguei com BDD [Behaviour Driven Development] , iniciando a escrita das histórias [descrição daquela funcionalidade na visão de uma pessoa] seguindo o modelo de template que o Dan North sugeriu. O resultado é que os times avançaram porque eles notaram como iniciar satisfatoriamente com testes sem comprometer a velocidade do desenvolvimento.

O BDD nos trouxe os testes para o inicio de qualquer código, praticamente sem distinguir que se está testando antes e associado com outras práticas como “Programação em Par” facilitou a linguagem ubíqua do time.

Independente se é ágil ou tradicional eu tenho notado uma deficiência na coleta de informações, seja como User Stories ou Use Cases, onde os analistas de negócio, ou seja lá como são chamados nos times, não sabem pensar em negócio. Uma das coisas mais ridículas que vejo é o sujeito explicar para seu time uma funcionalidade com base em um DER ou outra estrutura técnica, dizendo coisas como: “a tabela tal, associada a entidade x”.

Tenho tentado corrigir isso nos times que enfrento como princípio básico, antes de qualquer coisa eu tento disciplinar a pensarem em negócio. Faço exercícios simples como questioná-los com “esqueçam de qualquer termo técnico” e “como essa funcionalidade é no papel?” ou “se não tivesse computador, como fariam isso?”, perguntas simples para instigar o raciocínio sobre a funcionalidade. Após esse exercício, escrevemos essa história em um arquivo e partimos para sua implementação.

Em março desse ano eu palestrei no primeiro encontro da XPCE sobre BDD, vejam os slides. Em termos de ferramentas você pode conferir como temos trabalhado em um projeto recente seguindo os posts do Jefferson Girão:

Parte 1 http://jefferson.eti.br/?p=96
Parte 2 http://jefferson.eti.br/?p=105
Parte 3 http://jefferson.eti.br/?p=139

Enfim, acredito que BDD seja um caminho natural para adoção de TDD por seu time já que eles terão código de teste, antes de qualquer coisa, na forma de negócio e o TDD já florescerá quando forem testar o modelo criado ou sugerido pelo código BDD. Ainda tem uma vantagem adicional, terão a documentação do sistema executável e comprovável.

Typically chemist’s shop can sale to you with discreet treatments for various heartiness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a highly complicated question. Matters, like “coupons for viagra“, are connected numerous types of health problems. If you need to take formula medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

7 thoughts on “Recomendação sobre TDD

  1. Rodrigo Galba

    Olá Milfont,

    Esse momento de ver o BDD na teoria e adota-lo na pratica não é tão simples quanto parece, acho que pelo menos culturalmente, e essa adoção deve ser feita de maneira cuidadosa, para que não exista assimiliação dos conceitos de forma errada.

    Ainda, a medida que venho conhecendo sobre BDD e TDD vejo que sua dica é importante:
    “…que BDD seja um caminho natural para adoção de TDD…”

    Vou continuar seguindo suas dicas 🙂
    Ótimo post.

  2. Jeveaux

    Ótimo post, Milfont.

    O que temos visto muito por aqui é o costume – pasme! – com BDUF nos times. As pessoas querem saber tudo, definir tudo, ter todos os detalhes e informações antes de escrever uma linha. Mudar isso tem sido um grande desafio para levar TDD para muitos clientes.

  3. cmilfont Post author

    @Jeveaux
    Aqui também tem sido um grande desafio, acredito que no Brasil inteiro o BDUF ainda é o padrão, com pouquíssimas exceções.
    Por isso a grande dificuldade com TDD.
    Estou trabalhando mais essa questão de BDD justamente para diluir a adoção do TDD independente se o time é ágil ou não.

  4. Luiz Henrique Correa

    Olá!
    bom post. Tenho pesquisado bastante sobre BDD mais para tentar viabilizar o TDD do que qualquer outra coisa…
    Só não concordei com a sua colocação:

    “Uma das coisas mais ridículas que vejo é o sujeito explicar para seu time uma funcionalidade com base em um DER ou outra estrutura técnica, dizendo coisas como: “a tabela tal, associada a entidade x””

    Muitas vezes tive que recorrer a tais explicações principalmente para membros da equipe que possuem mais facilidade com Diagramas DER, afinal de contas, sempre trabalharam focados nos dados e para eles funcionava sempre muito bem.
    A verdade é que temos a nossa disposição diversas técnicas e ferramentas para resolvermos um problema, e se o DER funcionar melhor para vc explicar uma determinada regra para algum membro da equipe, não vejo problema em agir assim.
    Penso que devemos sempre ter em mente que OO, UC, User Stories, TDD, DER etc, etc são MEIOS de chegarmos ao objetivo final que é o Produto que resolva o problema do Nosso Cliente, e não o FIM por sí só.
    Abraço!

  5. cmilfont Post author

    @Luiz Henrique
    Explicar funcionalidade de negócio com base na abordagem técnica corre um risco de direcionar o modelo para estruturas diferentes do que se propôe, a idéia, que é criar uma linguagem ubíqua do projeto deve ser a forma preferencial de espalhar esse conhecimento.
    Explicação com base em DER, MER ou qualquer estrutura técnica deve ser para modelagem de estruturas técnicas depois que o negocio foi entendido.

  6. Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting

Comments are closed.