Os desenvolvedores podem testar seu próprio código?

Por esses dias, estive relendo os posts sobre como são conduzidas as atividades de testes no google, entre outras coisas eles falam sobre os papéis, funções e de que maneira a qualidade de software é conduzida dentro da empresa.

No terceiro post da série, diversas afirmações chamaram a minha atenção e valem a nossa reflexão:

“Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place?”

A partir dessa afirmação podemos ver que estamos passando por uma grande transição na engenharia de software. Onde há vários anos as empresas dão uma ênfase cada vez maior aos aspectos relacionados à qualidade de software e diversas estratégias surgiram e vêm sendo utilizadas para a organização das equipes e divisão das tarefas.

Porém, o que mais me chama atenção nessa primeira afirmação é como a idéia a que estava acostumado, de que precisamos de pessoas com dois perfis diferentes para testar e desenvolver um software está ficando ultrapassada.

Make it or Break it

Cada vez mais precisamos unir as duas disciplinas que se completam para assim entregar produtos de maior qualidade.

Claro, que para que isso aconteça é necessária uma mudança cultural e comportamental. Abandonarmos os antigos conceitos de que desenvolvedores não conseguem enxergar as falhas em seu próprio código, não gostam e não querem testar e tornar tudo em uma única tarefa.

Diversos benefícios podem emergir dessa tendência, como: detecção de defeitos cada vez mais cedo, maior liberdade para o engenheiro de teste focar em aspectos não funcionais, fluxos de integração e outros pontos que fogem a unidade do desenvolvedor, etc.

  “quality is more an act of prevention than it is detection”

Desse modo, técnicas como o TDD podem ser excelentes caminhos para eliminar essa separação entre testes e desenvolvimento. Ajudando a tornar a qualidade cada vez mais um ato de prevenção do que detecção.

” Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved”

É óbvio, que existem diferenças entre os diversos tipos de projetos e na realidade de cada uma das empresas, onde cada um possui necessidades diferentes as quais precisam ser avaliadas e planejadas.

Está cada vez mais claro o caminho para produzirmos softwares de maior qualidade, testes e desenvolvimento como uma só tarefa, apresentando um grau de automação cada vez maior. Para seguirmos esse caminho várias mudanças são necessárias tanto nas pessoas, como nos processos e ferramentas.

E vocês o que acham? É esse o caminho a ser seguido?

Think First, Code Later!

Quem nunca fez uma burrada no código simplesmente porque não pensou no que ia fazer antes de começar a fazer?

Temos uma tendência enorme a simplesmente começar a fazer a coisa sem pensar exatamente em como que aquilo vai ser feito. Não é incomum você sentar na frente do computador e sair digitando código e ir tentando, e descobrindo o que fazer (descobrir detalhes on-the-fly é normal, o anormal é não ter nem direção certa).

Sabemos que isso é verdade, mas como evitar? No meu ponto de vista, individualmente, a única solução é primeiro pensar e depois codificar, não tem para onde correr! Porém, acredito que algumas técnicas que trazem outros benefícios, também ajudam a resolver esse problema específico de cuspir código sem pensar. Queria falar especificamente de duas técnicas, que sairam do eXtreme Programming. A primeira delas é Pair Programming, e a segunda delas é o TDD. Irei em breve escrever um post mais detalhado sobre as duas técnicas, mas por hora gostaria somente de apontar o que são, e como ajudam nessa questão de primeiro raciocinar pra depois codificar.

Pair programming é a prática de programar a 4 mãos… ou melhor, a 2 cabeças pensantes, mas somente 2 mãos. A idéia é sentar em pares em um único computador, e os dois codificarem juntos. Obviamente os benefícios disso são muitos: a atenção sobre o que está sendo feito é dobrada, um precisa estar dizendo ao outro o que está fazendo, ou pensando em fazer (e com isso já pensamos antes de fazer), funciona como uma revisão de código instantânea (pois ainda não está nem terminado e o seu par já identifica pontos que podem ser diferentes ou melhores), etc, etc….

TDD ( test driven development) por sua vez, trata de sempre testar o que você quer fazer antes mesmo de ter feito. A idéia mais uma vez é pensar no que vai fazer, antes de fazer. Nesse caso é necessário pensar em como você vai testar o código que ainda vai ser construído (por você) e nesse processo de pensar em como vai testar, você provavelmente vai descrobrir como vai codificar. É claro que além desse benefício, você tem outros ainda mais importantes que é a questão de todo o seu código desenvolvido ter teste (automatizado/unitário) que testa aquele código, garantindo ainda mais sua qualidade. E, tendo essa suíte de testes que garantem que meu código está realmente fazendo o que tem que ser feito, eu posso mudar meu código mais tranquilamente meu código pois sei que meus testes unitários (criados utilizando a técnica do TDD) vão atestar minha mudança. Isso dá subsídio para outras práticas (MUITO)importantes como Design Evolutivo e Refactoring.