Test infection: por onde começar?

Fala GC!

Cara, o que voce faria se entrasse em um projeto para implementar umas melhorias, mas esse projeto não tivesse nenhum tipo de teste, o código não fosse testável e você soubesse que daqui a 3 meses ia sair do projeto? Você perderia tempo fazendo refactoring, implementando testes, configurando CruiseControl e tal, ou ia simplesmente ligar o foda-se???

Isso acontece pelo menos 32409 vezes todos os dias em algum lugar do planeta.

Os desenvolvedores acostumados a programar com testes têm uma dificuldade enorme de trabalhar em aplicações que não tem testes. A primeira coisa que os desenvolvedores mais experientes fazem quando pegam uma aplicação nova é olhar a base de testes. Por alí já é possível descobrir uma série de comportamentos e detalhes da implementação do sistema, bem como as intenções de quem o programou. Mas o que você faz quando cai de pára-quedas num projeto que não tem um mísero teste sequer? Você não pode deixar esse problema para outra pessoa? É você o infeliz que tem que resolver o problema e fazer a faxina?

Minha resposta para essa pergunta é bem simples: SIM, você é o infeliz que tem que resolver o problema.

<história>
Uma vez eu trabalhava numa empresa e meu chefe me pediu para fazer um protótipo de um sistema que integrava um website com um PABX para fazer determinadas tarefas. Como era um protótipo e eu só tinha duas semanas, eu fiz ZERO testes (e a aplicação funcionava por milagre divino). Só que para o meu azar, esse protótipo era para fazer uma demonstração para um cliente, que adorou a idéia e comprou na mesma hora! Como meu chefe achava que já estava parcialmente pronto e funcionando, meu prazo para terminar era de mais quatro semanas. Duas semanas depois eu estava desesperado por não conseguir avançar na aplicação e não conseguir fazer o negócio funcionar. Aconteciam bugs estranhos, daqueles que te fazem pensar que você está na profissão errada. Todos os dias eu me arrependia profundamente de ter deixado os testes para trás. Meu chefe ficou desesperado e colocou mais um desenvolvedor para me ajudar. No primeiro dia ele me perguntou: “GC, onde estão os testes para eu dar uma olhada?”. Er.. bom… não tinham testes… E eu fiquei totalmente desmoralizado, fui humilhado, massacrado e apanhei quase até a morte.
</história>

Hoje em dia não abro mão dos testes. Se você entregar uma aplicação que não funciona, a culpa é sua! Então, faça tudo que é possível para garantir que tudo esteja funcionando.

Finalmente, respondendo o e-mail do meu amigo acima (que não posso dizer o nome porque não tenho permissão), eis algumas dicas para você não ficar em maus lençóis:

Dica número 1: faça sempre o melhor que puder! Mesmo que você ache que vai ficar 2 semanas ou 3 meses em um projeto, seu gerente pode mudar de idéia e você pode acabar ficando bem mais tempo do que isso. Então, tire essa idéia da cabeça já e comece a se preocupar com os testes. E mesmo que você com certeza absoluta só fique 3 meses, como que você vai sair de cabeça erguida e com a certeza de que o que você fez está funcionando se você não tem os testes para comprovar?

Dica número 2: conserte as janelas quebradas. Se alguém chega na sua casa e metade das janelas estão quebradas, então não tem muito problema se quebrar mais uma. Porém, se todas as janelas estiverem impecáveis, quebrar uma janela é péssimo! Siga este mesmo princípio para o seu código, não tenha janelas quebradas. Se você tiver 90% de cobertura de testes, todos eles forem impecáveis e nenhum falhar no CruiseControl, o próximo desenvolvedor que chegar se sentirá na obrigação de manter tudo funcionando da mesma forma, porque esta é a cultura do projeto. Já se todos os testes estiverem quebrados ou não houverem testes, não faz a menor diferença.

Dica número 3: não abraçe o mundo com as pernas! Não precisa refatorar a aplicação inteira de uma vez, até porque você corre um grande risco de tudo parar de funcionar e você ser demitido, além de que não vai conseguir implementar as features. Neste caso, minha estratégia seria refatorar o código na medida que precisasse implementar as features. Faria o ciclo normal de TDD: implementaria os testes fazendo refactor na implementação para torná-la testável, implementaria a feature, garantiria seu funcionamento e depois um novo refactor para deixar tudo bonito.

Dica número 4: get them Test Infected! Faça um workshop com os outros desenvolvedores do time e mostre para eles a importância de escrever testes. Ensine-os a usar o CruiseControl, JUnit, JMock, injeção de dependência e tudo mais que for necessário para que os testes aconteçam. Mesmo que você “perca” dois ou três dias de trabalho, com certeza ganhará muito mais desse dia em diante.

<piada>
Dica número 5: só por via das dúvidas, para ajudar nos momentos de fraqueza, coloque alguém para te vigiar em tempo integral. O “Dijkstra is watching” é ótimo para isso, tenha ele sempre por perto.
</piada>

Tags: , , , , ,

8 Responses to “Test infection: por onde começar?”

  1. Muito bom o post. Para essa questão de como abordar a qualidade, a dica das janelas quebradas é uma das melhores do “Pragmatic Programmer”. Este livro é realmente muito bom. Eu considero que ele dá pílulas de maturidade e senioridade a quem absorve o conteúdo :)

    Outro “mantra” muito legal que não lembro onde vi pela primeira vez é: “Programe como se o próximo cara a manter código seja um maníaco homicida que sabe onde você mora”. Ou seja preocupar-se sempre com a clareza e qualidade do que você está fazendo é fundamental. O próximo cara a manter o código pode ser você mesmo, e quem gosta de manter código ruim? :)

    Que bom que vc está postando com freqüência de novo Guilherme, muita coisa boa por aqui. Grande abraço!

  2. Vinicius Assef says:

    Muito importante é lembrar o que acontece conosco quando vemos um código mal feito. Instintivamente perguntamos “quem foi o relaxado que fez isso?!”

    Se eu fui o último a mexer, certamente levarei a má fama.

    E como quero ser bem pago pelo meu trabalho, preciso fazer barba, cabelo e bigode. ;-)

    []s.
    Vinicius Assef.

  3. Ronan Lucio says:

    Guilherme,

    Legal o seu post. Você levantou alguns pontos realmente bem interessantes, entretanto eu o achei muito generalista, ou seja, não aplicável em todos os projetos.

    Dependendo da complexidade do projeto, refatorar e escrever testes de tudo pode tomar tranquilamente os três meses, que é o prazo total do projeto citado.

    No livro “Extreme Programming Explained” do Kent Beck há um capítulo que fala sobre a adoção de TDD em sistemas existentes.
    Acho a proposta do livro bem interessante para este caso:
    Escreva os testes a medida que você ser codificando:
    - Vai desenvolver a funcionalidade X, escreva testes;
    - Vai alterar a funcionalidade Y, escreva testes;
    - Vai corrigir um bug, escreva testes.

    Existe a regra 20-80, que diz que 80% da utilização de um sistema corresponde a 20% dele.
    Isso quer dizer que em pouco tempo você terá 20% cobertura de testes, porém esses 20% corresponderão a 80% da utilização do sistema.

    []s
    Ronan Lucio

  4. Oi Ronan Lucio,

    Acho que você não leu direito meu post. Leia a dica número 3 novamente, é exatamente o que você está dizendo:

    Dica número 3: não abraçe o mundo com as pernas! Não precisa refatorar a aplicação inteira de uma vez, até porque você corre um grande risco de tudo parar de funcionar e você ser demitido [...]

  5. Ronan Lucio says:

    Guilherme,

    Tá certo, relendo o item 3 fica claro que eu não o li… :-/
    Retiro o que disse.

    []s
    Ronan

  6. [...] atual do projeto, mas como bem disse uma vez o Guilherme Chapiewski num excelente post sobre inclusão de testes num projeto, no momento em que comecei a modificar o código desse projeto foi o momento em que comecei a [...]

  7. [...] – trabalhando com mock objets em java Easy AdSenser by UnrealLendo sobre testes unitarios, imagine o caso onde o seu teste é complexo: um objeto que chama outro e, então, realiza as suas [...]

  8. [...] sobre testes unitarios, imagine o caso onde o seu teste é complexo: um objeto que chama outro e, então, realiza as suas [...]

Leave a Reply