Usando TDD e Unit Tests com C# e Visual Studio 2010 - Artigo Revista . Net Magazine 87

  Imagine uma situação como esta: você desenvolveu um software. Pode ser uma aplicação completa, uma class library, etc., e faz a entrega para o seu usuário. No momento que ele vai fazer uso da mesma, um erro de cálculo é detectado, ou ainda, a ferramenta não faz o que o usuário esperava que fizesse.

Problemas assim são comuns. Geralmente os testes não dão conta de cobrir todas as possibilidades de execução do código e dificilmente podem dizer se o que foi pedido pelo usuário nos requisitos do sistema foi realmente implementado.

  Acrescente a estes problemas a necessidade de agilidade cada vez maior na entrega acarretando a falta de documentação completa da parte dos desenvolvedores quer por falta de afinidade com a tarefa de escrever qualquer coisa que não seja código e, além disto, a velha desculpa de que se o “código compilou tá certo”.

Bem, talvez seja um cenário um pouco exagerado, mas, em algum momento algum desenvolvedor já passou por algo parecido. 

Entretanto há pouco tempo, cerca de uma década, novas práticas relacionadas com agilidade no desenvolvimento de software vêm ganhando terreno entre os programadores. Uma delas é conhecida como TDD e como foi dito consiste em escrever o código do software partindo-se dos testes que podem ser feitos com este código.

Test Driven Development e testes unitários

TDD ou Test Driven Development é uma evolução da maneira como os softwares são escritos. Consiste basicamente em se escrever o teste antes mesmo de ter um código a ser testado. Isto força que as especificações dos requisitos sejam bem feitas porque os testes serão escritos a partir destes.

Não foi criado por nenhuma companhia específica, mas, pela necessidade de várias ao perceber que a maneira que era adotada não trazia resultados esperados.

Está ligado também com as metodologias ágeis de desenvolvimento de software e traz benefícios já que todo o código que for desenvolvido precisará passar pelos testes para ser considerado pronto.

Um dos principais objetivos do TDD é melhorar as especificações mais do que validar o que será escrito. Não se persegue a perfeição, mas, se testa o que é realmente importante no sistema. Por outro lado, com TDD há uma forma de garantir que cada linha do código funcional é testada, o que não acontece na maioria dos testes tradicionais - embora seja altamente recomendado.

Com a sua adoção o desenvolvedor direciona o processo de desenvolvimento do software forçando o desacoplamento das dependências.

Nota do Devman

Por desacoplamento de dependências deve ser entendido o quanto as partes (classes, métodos, estruturas de dados) estão vinculadas umas com as outras. Um sistema fortemente acoplado impede que estes componentes sejam reaproveitados em outros projetos visto que estão interligados de uma forma que sua separação se torna impossível. Por contrapartida, um sistema desacoplado permite este reaproveitamento já que a interface e a maneira como o código foi escrito dos componentes permite isto.

A partir do ponto em que está madura a adoção do TDD, os desenvolvedores recusam-se a escrever código antes de haver um teste pronto para este. O motivo é que a presença do teste indica uma boa definição dos requisitos.

Testes unitários, por sua vez, consistem em escrever os testes levando apenas em conta uma funcionalidade do código. Na prática, consiste em escrever o teste para um método – que deverá ser obrigatoriamente conciso e pequeno o bastante para ser testado.

Princípios e práticas 

Alguns dos princípios e práticas do desenvolvimento orientado a testes são:

• A comunicação entre os elementos envolvidos no projeto é um dos pontos mais importantes. Desenvolvedores, usuários e técnicos de testes são encorajados a estarem constantemente em comunicação;

• Há uma maior clareza nos objetivos do projeto. Uma vez que os testes serão escritos antes mesmo do código, é necessário que cada requisito seja muito bem definido;

• Os membros da equipe de desenvolvimento são corresponsáveis. Não há sucesso ou falha individual, cada um é responsável pela qualidade;