Profissionais TI - Pra quem respira informação

O Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes é uma das práticas mais conhecidas e admiradas da metodologia ágil de desenvolvimento de software chamada Extreme Programming (XP).

Trata-se de uma técnica utilizada para garantir qualidade e minimizar o risco de embutir defeitos ou bugs no produto.

 Essa técnica consiste de cinco passos:

1. Escrever o teste antes de escrever o código: Analisar, identificar e documentar os testes que deverão ser executados;
2. Submeter o teste, que deve falhar: Uma vez que o código não foi desenvolvido, o teste irá falhar e o desenvolvedor terá a garantia de que nenhum outro código faz seu teste passar. Se o teste passar, significa que já existe código desenvolvido que contemple a situação a ser testada;
3. Escrever o código: Escrever o código necessário para fazer o teste passar;
4. Submeter o teste novamente, que deve passar: Se o teste passar após o novo código, você terá a garantia de que o teste passou devido ao seu código. Se o teste não passar, você deve voltar para a etapa anterior e corrigir o código;
5. Refatorar o código: Tornar o código mais elegante, eliminando redundâncias e tornando-o de fácil manutenção.

Estes passos são conhecidos também como Red (teste falhando), Green (teste passando) e Clean (refatoração do código).

“Mas Vitor, quais são as vantagens de utilização desta técnica? Como desenvolvedor terei mais trabalho! Para que escrever e executar um teste antes, se eu já sei que irá falhar?”.

Vamos aos benefícios:

• Evitar testes “viciados”;
• Garante que o evento que houve entre a falha e o sucesso do teste, o desenvolvimento do código, realmente foi o responsável pelo sucesso do teste;
• Garante que o código será testado e refatorado conforme vai sendo desenvolvido;
• Se o teste já funcionava antes do código, isto significa que a funcionalidade já existia e não será escrito código desnecessário e duplicado;
• Evita fluxo “vai-e-volta” entre equipe de desenvolvimento e cliente ou entre equipe de desenvolvimento e equipe de testes/garantia de qualidade, devido a erros no código.

Já participei de uma experiência onde uma Equipe de Desenvolvimento era tão madura na utilização do desenvolvimento orientado a testes, que não houve mais necessidade da existência da área de testes no decorrer do projeto, pois toda a entrega feita pela Equipe de Desenvolvimento simplesmente não tinha defeitos.

Abaixo um exemplo para utilização do desenvolvimento orientado a testes:

FUNCTION VALIDA_REGRAS_NEGOCIO RETURN BOOLEAN IS
BEGIN
   RETURN(FALSE);
END;

A teste do método acima falhará, uma vez que o retorno é falso. A próxima etapa é escrever o código desejado.

FUNCTION VALIDA_REGRAS_NEGOCIO RETURN BOOLEAN IS
BEGIN
  …. Regra de Negócio 1
  ….
  RETURN(TRUE);
EXCEPTION – Em caso de erro retorna falha
  WHEN OTHERS THEN
    RETURN(FALSE);
END;

Ao executar um novo teste, se o teste passar (retorno verdadeiro) ficou evidenciado que o código desenvolvido foi o responsável pelo sucesso do teste. Se o teste falhar, será necessário revisar o código até o teste passar.

Agora vamos incluir uma segunda regra de negócio no código.

FUNCTION VALIDA_REGRAS_NEGOCIO RETURN BOOLEAN IS
BEGIN
  …. Regra de Negócio 1
  ….
  …. Regra de Negócio 2
  ….
  RETURN(TRUE);
EXCEPTION – Em caso de erro retorna falha
  WHEN OTHERS THEN
   RETURN(FALSE);
END;

Se o teste começar a falhar (retorno falso) ficou evidenciado que o código referente à segunda regra de negócio mudou o comportamento do teste que havia sido bem-sucedido na etapa anterior.

Caso queira se aprofundar no uso do desenvolvimento orientado a testes, recomento a leitura do livro TDD – Desenvolvimento Orientado a Testes de Kent Beck, criador da técnica.

Esta é mais uma técnica para que você evite utilizar a outra prática TDD normalmente utilizada no mundo do software e que eu chamo de Thor-Driven Development.

“Mas Vitor, o que seria Thor? É alguma técnica nova?”

Não, vem de Thor, o Deus do Trovão dos quadrinhos da Marvel mesmo! É o desenvolvimento orientado a “marteladas”, remendos, códigos ruins, códigos mal testados, códigos que “estão prontos, mas só falta testar”, bugs.

Abaixo o débito técnico, rumo ao desenvolvimento de software de qualidade!

Abraços e até o próximo artigo!