TDD – Desafios de iniciar na prática

Todos já lemos sobre como o TDD (Test Driven Devlopment) agrega valores ao desenvolvimento de software. Acontece que existe uma gigante distância entre: saber o que é bom e praticar o que é bom.

Em todos os aspectos da vida, normalmente o que é bom, demanda algum tipo de esforço. Esforço esse, que pode nos desviar do caminho correto. Assim nascem os corruptos, assim nascem os códigos corrompidos.

Um exemplo clássico, que vejo acontecer no estado do Rio de Janeiro, é a cervejinha que libera o motorista da multa de trânsito.

Uma coisa é você estar com dinheiro no bolso, carteira de motorista sem pontos acumulados e em um dia sem pressa. Fica fácil dizer: “Pode levar meu carro. Eu estou errado.”

Muito diferente, é estar em um situação onde você está duro, com o limite de pontos estourando e atrasado para uma reunião importante.
Ouvir o policial dizer que aceita qualquer trocado, é tentador.

Não é novidade para ninguém que muitos escolhem a opção mais fácil e menos correta. Na hora de colocar o TDD em prática, acontece o mesmo.

Por isso, nós programadores, muitas vezes conhecemos o padrão correto mas não o aplicamos.

Percebam que eu estou presumindo que você já conhece a parte teórica do TDD. Caso isso não seja uma verdade, recomendo que procure algum livro sobre XP. “Extreme Programming”, do Vinícius Telles, pode ser um bom começo.

Minha primeira dica, é tratar o teste como um jogo. No começo, diminuímos a dificuldade… só pra curtir e entender as regras. Portanto, diminua o nível de dificuldade, inicie com um projeto de exemplo. Foque em manter a prática de baby steps. Esse é um dos principais pontos para que a coisa dê certo.

Depois de ter treinado no mundo ideal, é hora de aceitar o desafio e praticar no primeiro projeto real que cair nas suas mãos!
Agora sim, o bicho pega e tudo fica muito mais emocionante. No mundo real, temos os seguintes desafios a serem considerados:

  • Prazo;
  • Pensamento focado na resolução do problema proposto;
  • Desenvolvimento em equipe;
  • Imprevisibilidade de algumas tarefas;

“If it’s hard, do it frequently and it will get easy.” Mary Poppendieck

Ao se deparar com um destes desafios, provavelmente você vai querer simplesmente esquecer que TDD existe. Alguns automaticamente vão para o caminho mais fácil, outros, aceitam o desafio e evoluem.

Prazo

Se você estudou direitinho a teoria do TDD, sabe que prazo não é um grande problema assim. Acalme-se e confie em milhares de desenvolvedores  felizes 😀
Evite ficar ansioso para provar que o TDD não altera o prazo final. Se ficar, você vai acabar confirmando o que os Testers dizem: “Programador testa para funcionar”.
De início, evite tentar fechar todas as falhas possíveis. Quanto mais experiência tiver, mais coisas vai conseguir testar sem alterar o prazo da tarefa. Isso só o tempo traz, não adianta forçar a barra.

Entenda que o teste no TDD é utilizado como ferramenta de design. A idéia é através dos testes, criar sua arquitetura de forma correta. Então não tenha a pretensão de cobrir todas as possibilidades do mundo. Crie teste para desenvolver, e deixe outros tipos de testes para o final.

Pensamento focado na resolução do problema proposto

No mundo ideal, você não se preocupa com a resolução do problema. Você escolhe um projeto simples e fácil, para que seja possível se focar apenas na aplicação do TDD. Assim que você entra no projeto real, a coisa muda.
É normal, inclusive, achar que a linguagem com que trabalha há anos ficou mais difícil. A sua cabeça está tentando resolver o problema proposto e aplicar uma coisa nova na prática.

A dica aqui é: NÃO FOQUE INICIALMENTE NO PROBLEMA.

Tarefas complexas, podem ter fácil entendimento, porém o seu desenvolvimento é nebuloso. Sabemos entradas e saídas, mas não como processar e gerar. Se concentre na teoria, lembra? Confie nela! O TDD propõe que você teste um resultado esperado e isso é fácil! Passo a passo.

Assim que você começa, aquele grande problema, é esquecido e você foca em resolver o primeiro passo.  Um pequeno passo após o outro, chega um momento que você roda o teste e diz: caramba, acabei!

Ai sim, adicione mais alguns testes que julgar necessário, pois agora estes testes já não necessitam de alteração da sua arquitetura… Caso encontre algum bug, basta resolver usando TDD.

Desenvolvimento em equipe

Ao meu ver, este pode ser o maior impeditivo.  Sua equipe também precisa aderir ao TDD. A todo momento pegamos códigos para refatorar ou precisamos alterar alguns comportamentos para desenvolver nossas tarefas.

Imagine a insegurança de refatorar sem testes? Você vai demorar o dobro do tempo se preocupando em criar os testes para o código a ser refatorado.

Mesmo se a equipe faz testes normais, mas não seguindo a prática TDD, você também corre o risco de ser prejudicado. Pois sem TDD a tendência é que as pessoas façam métodos sobrecarregados e testem apenas a entrada e saída. Deixando seu meio nebuloso.

Para que isso não aconteça, antes do projeto iniciar,  coloque sua equipe no mesmo barco que você.
SIM, É DIFÍCIL! Mas quem gosta de desafios fáceis? Promova apresentações, incentive a participação em dojos e etc!

Imprevisibilidade de algumas tarefas

Esse é tenso! Sabe aquele momento que você sente um arrepio na espinha e sabe que está encrencado com um determinado pedaço de código? Pois é, aqui é o momento de ser forte. Porque você vai perder tempo, vai ver o prazo saindo das mãos e vai tentar fazer o restante um pouco mais rápido. Sím, a primeira escolha do iniciante vai ser parar com o TDD.
Tenha em mente que gambiarras não salvam o prazo. Códigos sem teste, também não. Converse com o seu líder sobre o problema. Mantenha a calma, se mantenha no curso.

É como dizem por ai,  “Usando TDD, quando acabamos, realmente acabamos.”

Compartilhe seus desafios em praticar TDD comigo!
Aloha e bom TDD!

Publicidade

6 comentários em “TDD – Desafios de iniciar na prática

  1. Eu sempre fui um daqueles que desacreditava em TDD, achava interessante mas era um risco, podendo ser sinônimo de prazo estourado.
    Mas te vi implementando e fiquei surpreendido.

    Pelo pouquíssimo que eu sei de TDD, eu percebo que talvez os benefícios possam não ser instantâneos, mas quando você tiver a necessidade de fazer a manutenção naquele código, ai sim que você nota o ganho de tempo e a facilidade que o TDD te traz.
    Primeiro por que você não vai ter medo de meter a mão no código, com receio de sua manutenção desencadear outros bugs, outra é que tempo que você vai gastar com manutenção será bastante reduzido, já que o objetivo do TDD são os bugs sumirem do seu cotidiano.

    Está ai um tabu que foi quebrado ! TDD X Prazo
    Em breve irei desfrutar desses benefício também !
    =D
    Aloha !

    Curtir

  2. O problema atual é que os desenvolvedores se focam somente em entregar o sistema e pronto. Ninguém costuma pensar que SEMPRE haverá modificações e implementações a serem feitas. Todo estudo feito voltado para a qualidade de software diz que a manutenção é a parte mais importante do desenvolvimento.

    Então se você “perde” algum tempo fazendo os testes você ganhará, e muito, tempo lá na frente quando tiver que alterar o código. E acredite, mesmo que não seja você, mas o código será alterado. hehe

    Ótima iniciativa do blog, Mattoso.

    Aloha!

    Curtir

  3. Mesmo se a equipe faz testes normais, mas não seguindo a prática TDD, você também corre o risco de ser prejudicado. Pois sem TDD a tendência é que as pessoas façam métodos sobrecarregados e testem apenas a entrada e saída. Deixando seu meio nebuloso.

    Curtir

  4. Parabéns pelo texto muito rico e motivador. Eu só acrescentaria o significado da sigla na primeira aparição dela. Custava nada.

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s