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:
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.
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
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é?
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.
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!
TDD na minha opinião é disciplina, deveria estar no código de conduta de todo bom desenvolvedor.
Excelente Post Elemar!
Cara você não dorme?!
Ou passa muito tempo no banheiro! kkkkkkkkkk
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
Ó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.
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.
Clean Code na veia!
Seu código, mais testável, PRECISA ser mais fácil de ler e manter.
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.
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!!!
Exatamente!
Pingback: SNIPPET: Sobre a falta de apoio para Testes de Unidade na empresa | Elemar DEV