Elemar DEV

Tecnologia e desenvolvimento

TDD é uma escolha pessoal!

Olá pessoal. Tudo certo!?

Sempre fiquei cismado com a frase de despedida de uma certa companhia aérea. Diz assim:

“Sabemos que a escolha da companhia aérea é uma decisão do cliente, Obrigado por escolher a XYZ”

Achava essa frase estranha porque raramente sou eu quem escolhe a companhia que vou voar. Geralmente, vôo pela empresa e quem acaba escolhendo a companhia não sou eu (custos diretos x horários).

Quando falo com alguém sobre TDD, ouço uma argumentação oposta:

“Quero utilizar TDD mas não consigo convencer o pessoal da empresa…”

Hoje, acho essa frase, também, muito estranha. Acho que, essa sim, é uma decisão pessoal.

Recapitulando…

De fato, TDD pode ser explicado, com simplicidade, assim:

image

 

Ou seja:

  • Se preciso fazer uma alteração em qualquer código, devo (ter condições de) escrever testes que falhem até que a alteração esteja completa;
  • Meu teste deve “delimitar” claramente a SUT – isolando ao máximo a alteração que eu desejo promover;
  • Escrevo meu código para atender este teste teste;
  • Melhoro o meu código.

Por que, mesmo, preciso convencer alguém a me autorizar a escrever testes?!

E se eu pegar um código sem testes?!

Códigos sem testes são mais difíceis de alterar. Afinal, não há como verificar, com agilidade, se todas as características importantes estão sendo preservadas.

Se eu preciso alterar um método que não tem testes, começo escrevendo um que indique que eu entendo o que esse método faz. O fundamento para essa posição é mesmo que utilizei outro dia para escrita de “Learning Tests”. Se o teste falhar, vejo cedo que não entendi corretamente o que o método deveria estar fazendo e evito enganos.

No mais, processo normal.

E se meus colegas não escreverem testes?!

Problema é deles! Cabe a nós inspirar com o exemplo.

Com o tempo, sua base de testes ganhará corpo e será de grande ajuda para seu trabalho. Se ninguém mais atualizar seus testes, eles podem começar a falhar (até mesmo, não compilar [o que é um tipo de falha]). Entretanto, essa será uma ótima forma de você se atualizar sobre o que mudou. Não acha?

Se só eu escrever testes, precisarei de mais tempo que os outros?!

Não! Você terminará o seu trabalho em menos tempo. Obviamente, depois de ganhar alguma proficiência.

Escrevendo testes você será “compelido” a usar boas práticas. Além disso, escreverá apenas o que for necessário. Você não precisará “carregar” sua aplicação inteira para saber que aquilo que está fazendo está certo.

Naturalmente, se você não está habituado, precisará se esforçar um pouco mais até “pegar a idéia”. Entretanto, em pouco tempo, verá que consegue fazer mais em menos tempo.

Enfim…

Se prepare, estude e trabalhe. Você poderá fazer o seu trabalho com mais qualidade usando TDD. Escrever testes é tão parte de seu estilo quanto a forma como escreve condicionais e repetições.

No fim, a decisão é sua. Aliás, estou inclinado a dizer que a decisão é SEMPRE sua.

Era isso.

15 comentários em “TDD é uma escolha pessoal!

  1. Cássio Almeron
    11/04/2012

    De fato.
    Tenho aos poucos amadurecido e me habituado a escrever testes. Porém ainda sobre funcionalidades isoladas e simples, mas mesmo assim, percebi imediatamente os benefícios.
    O fato de não precisar rodar a aplicação para verificar se esta correto, assim como manter um histórico de situações, e a influência positiva dessa abordagem no design da codificação são grandes vantagens.
    Pretendo me aprofundar mais nesse assunto, e entender bem mocks e stubs.
    Trata se de uma questão de habito. E depois que pega o jeito não se larga mais

  2. Leonardo Aguiar
    11/04/2012

    Olá Elemar, não sei se escrever testes por conta própria quando toda sua equipe não escreve será realmente útil.

    Em um projeto que tentei fazer isso, usar TDD, e os meus colegas não usaram, o que aconteceu foi que em determinado momento eles apagaram o projeto de testes da solution.

    Motivo: não estava compilando. Eles acharam que arrumar seria uma perda de tempo e apagaram o projeto da solution.

    Acho que enquanto a equipe não entender a ideia do TDD e comprar essa ideia para eles, não adianta um ou outro desenvolvedor usar. O risco de alguém olhar torto para aquilo e dizer que é perda de tempo é só complica mais o projeto é muito grande.

    Outra coisa que acontece muito é que quando o projeto esta atrasado sempre jogam a culpa na nova técnica/metodologia/tecnologia que foi empregado no projeto. E se não abandonam já nesse projeto, nunca mais voltam a usar.

    Hoje o que ouço na empresa sobre TDD e qualquer outra técnica/metodologia/tecnologia é algo mais ou menos assim: Ah… vai começar um projeto novo, vamos fazer com TDD, mas se enroscar muito a gente para e tira.

    Bom… nem preciso dizer que sempre tiram o TDD no primeiro empecilho que aparece né?

    • elemarjr
      11/04/2012

      Entendo sua posição. Recomendo o seguinte, faça o projeto de testes em outra solução, se for o caso. Mas, faça.

      Melhore a sua performance e inspire pelo exemplo. Sem condenar, mas demonstrando as vantagens. Entregando, lembre-se que tal conhecimento pode ser novo para você também. Faça sua parte, estude em casa.

      • Marcos Antonio
        03/05/2012

        Triste isso, mas é a mais pura realidade. A maioria não entende o que é realmente TDD e acha que é perda de tempo, prefere o conhecido “sair fazendo” e deixar que o cliente faça o teste, aí já não preciso dizer o que acontece né… Sou estusiasta de metodologias ágeis, estou sempre lendo algo a respeito e tentando aprender, algo que não acontece aqui com os demais. Muitas vezes, a tentativa de inserir novas formas de trabalho e novas tecnologias tornam-se até motivos de piada de outros membros do time. Nestes casos concordo plenamente como o Elemar, façamos nossa parte, em outro ambiente: em casa, já que os demais preferem continuar com suas metodologias infalíveis de décadas atrás!

  3. TDD na minha opinião é disciplina, deveria estar no código de conduta de todo bom desenvolvedor.

    Excelente Post Elemar!

  4. Cleyton Ferrari
    11/04/2012

    Cara você não dorme?!

    • Flavio Alencar
      16/04/2012

      Ou passa muito tempo no banheiro! kkkkkkkkkk

  5. Cicero Oliveira
    11/04/2012

    Oi Elemar, mais uma vez, com ótimos assuntos, eu estou começando a praticar o TDD, o engraçado é que quando você tenta conversar sobre o assunto com algumas pessoas, elas não estão inclinadas a ouvir , geralmente falam para mim o seguinte.. faz o básico que esta bom, Testes e bobagem .

    Parabéns e Obrigado

  6. fernandolopes11
    11/04/2012

    Ótimo post gostei muito! vi a minha história nesse post. Tipo na minha empresa realmente quando vou falar de TDD me sinto como um evangélico que vai falar, todo mundo vira a cara ou muda de assunto… vou tentar seguir esse conselho de fazer sozinho e depois mostrar o resultado.

  7. rafaelromao
    12/04/2012

    O maior problema que vejo em tentar usar TDD sem o apoio da equipe (que é pra mim o verdadeiro problema) é que para ser testado, o código tem que ser escrito já com os testes em mente. As boas práticas tem que ser seguidas, para tornar o código testável. Se a equipe não enxerga as vantagens dessas boas práticas e já considera perda de tempo o simples uso de interfaces, ao invés do acesso direto às classes, querer modificar o código para que fique testável só lhe faz ser visto como o nerd chato que quer dar mais trabalho a eles e complicar tudo.

    • elemarjr
      12/04/2012

      Clean Code na veia!

      Seu código, mais testável, PRECISA ser mais fácil de ler e manter.

      • rafaelromao
        12/04/2012

        Com certeza. Dureza é aplicar isso a um código onde todos da equipe põem a mão, sendo que boa parte dessa equipe não vê a aplicação de boas práticas com bons olhos.

    • egomesbrandao
      13/04/2012

      Concordo com você! O grande empecilho de usar TDD sozinho na equipe é que provavelmente o código que esta sendo gerado não vai atender, então o dev ficará fazendo refactoring do código dos outros, o que acarretará problemas com a equipe, ou como o Leonardo Aguiar disse acima. Eu tive o mesmo problema e estava gerando apenas testes de integração, quando eles quebraram o código foi comentado e não reescrito, e era só mudar o nome da classe!!!

      • rafaelromao
        13/04/2012

        Exatamente!

  8. Pingback: SNIPPET: Sobre a falta de apoio para Testes de Unidade na empresa | Elemar DEV

Deixe uma resposta

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

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

Foto do Google+

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

Conectando a %s

Informação

Publicado às 11/04/2012 por em Post e marcado , .

Estatísticas

  • 585,845 hits
%d blogueiros gostam disto: