TDD: Mais uma tarefa ou um estilo de vida?

TDD

Test Driven Design não é mais uma tarefa que uma equipe de desenvolvimento é obrigado a fazer. Tudo que é forçado ou imposto no campo do comportamento humano acaba sendo mal feito. Ou seja, não funciona. TDD é um estilo de vida, é uma forma de viver a profissão, nesse caso, um estilo de trabalhar. O profissional precisa entender o que é isso e quais são os seus valores. É justamente o que eu tentarei passar neste post.

Responda a minha pergunta abaixo:

O que é mais importante para você: 1 ou 2? 

  1. Construir o código do teste do software?
  2. Construir o código do software propriamente dito?

Quando me deparei a primeira vez com esse dilema, a minha resposta foi imediatamente a 2. Mas depois de um tempo estudando foi então que um dia eu descobri uma coisa chamada “Dissonância Cognitiva” que mudou meus paradigmas. Você já ouvir falar?

Dissonância Cognitiva

Em 1971, em um livro chamado “The Psychology of Computer Programming de Gerald Weinberg” mostrou que o olho humano tem uma incrível capacidade de só enxergar aquilo que deseja e, naturalmente, ignorar aquilo que não quer ver. Ele diz o seguinte: “programadores, se deixados por conta própria, ignoram os erros mais gritantes, os quais qualquer pessoa seria capaz de detectar instantaneamente”. Isso se deve a um princípio bastante estudado na psicologia chamado dissonância cognitiva. Temos a tendência natural, como programadores, de acreditar que aquilo que escrevemos está certo. Inclusive, somos capazes de reler uma linha de código, que contém um erro de digitação e não enxergá-lo, mesmo depois de ler a mesma linha inúmeras vezes. Trata-se de uma fenômeno, uma pequena e desagradável peça que o cérebro nos prega. A dissonância cognitiva é potencializada ainda mais na profissão de desenvolvimento de software, uma vez que requer atividades mentais abstratas, lógicas, usando outros idiomas como inglês e automação de processos complexos.

Você já teve alguma experiência assim?

  • Ficou horas programando aquele código pensando consigo mesmo “Estou fazendo isso com extremo cuidado, tenho certeza que nem vai precisar testar, pois esta ficando 100%”. Só quando entra em produção é que você percebe os bugs.
  • Ficou programando com um amigo e viu que ele digitou algo errado que compila mas não funciona e ficou esperando ele corrigir. Depois de um tempo, você percebe que ele não se deu conta do bug?

O que isso quer dizer?

Quer dizer que você sendo “um ser humano” é naturalmente incapaz de programar sem acidentalmente introduzir bugs. Isso é inerente a natureza humana e principalmente a essa profissão. Ou sera que temos não seres humanos entre nós? Eu já ouvir falar de um cara ai chamado de Clark Kent, mas ele é repórter e não programador. Diante desse fato, quero te falar sobre uma premissa do desenvolvimento ágil de software: TODO CÓDIGO É CULPADO ATÉ QUE PROVE INOCENTE!

Teste de software é justamente a prova…

Se a ficha ainda não caiu, eu posso mastigar um pouquinho mais então: O teste é o que prova que aquilo que você programou realmente faz o que você se propôs a automatizar. O teste é o artefato de software que garante o termino e o sucesso da atividade de programação. Se um programador ficou horas programando mas não automatizou os testes de unidades, do ponto vista natural e sistêmico, esse pedaço de código esta com possíveis bugs. Se não existe provas reais e físicas que esse pedaço de sistema funciona, não temos como confiar. Ou seja, (complete com sua própria linha de raciocino)….

Responda a minha pergunta novamente:

O que é mais importante para você: 1 ou 2? 

  1. Construir o código do teste do software?
  2. Construir o código do software propriamente dito?

Depois de passar 8 duros anos da minha vida entregando software sem testes automatizados, vendo os bugs pular para todos lados, vendo meus companheiros de equipe sempre dizendo “eu programei certinho e testei tudo, pode enviar para produção!!!” e receber muitos os bugs mesmo assim…a ficha caiu para mim. Foi a última gota!

Foi então que eu dei um basta na minha vida de amador de desenvolvimento de software e passei a considerar o teste o mais importante de tudo, por que ele é quem prova o que eu faço, do começo, do fim e da qualidade do trabalho que eu presto.

Para os interessados em subir esse nível na sua profissão de desenvolvedor de software, a FOR-J oferece o treinamento de TDD com Java. Até a próxima!

“Bendito o Deus e Pai de nosso Senhor Jesus Cristo, que, segundo a sua muita misericórdia, nos regenerou para uma viva esperança, mediante a ressurreição de Jesus Cristo dentre os mortos.” 1 Pedro 1:3