O artigo trata de como aplicar a prática TDD (Test Driven Development) e testes unitários (Unit Tests) com o Visual Studio 2010 e a linguagem C#.
Para que serve
O desenvolvimento de software orientado a testes é uma das práticas adotadas quando se deseja agilidade na entrega do produto de software aliado com uma maior qualidade. Deve ser usado principalmente para prevenir falhas e facilitar o processo de testes dos requisitos implementados.
Em que situação o tema é útil
Quando se deseja obter maior qualidade no produto de software. Quando se tem a necessidade de fazer testes que sejam rápidos, objetivos e demonstrem de maneira mais ágil e simples onde estão os problemas. Ao adotar TDD e testes unitários, o desenvolvedor também irá passar a desenvolver usando um código mais limpo e livre de bugs.
Testes Unitários com Visual Studio
No setor de desenvolvimento de software comercial duas são as palavras de ordem: agilidade e qualidade, não necessariamente nesta ordem, se é que pode se dar mais importância a um aspecto em detrimento a outro.
Muitas são as maneiras como se busca obter esta qualidade e várias práticas surgiram para assegurá-la. Uma das mais interessantes é o desenvolvimento do produto tendo como base os testes. Esta é conhecida como TDD que é abreviatura para o termo em inglês Test Driven Development.
Por este termo compreende-se o desenvolvimento do software tendo como principal foco os testes que serão executados sobre este. Um aliado forte nos testes são os testes unitários. Estes são uma categoria bem específica onde procura se testar apenas e tão somente um requisito do software que pode estar representado por um método ou uma classe.
O Visual Studio 2010 oferece recursos para o desenvolvedor usar testes unitários sem a necessidade de ferramentas de terceiros. Neste artigo serão demonstrados os conceitos envolvendo TDD e testes unitários e serão feitas demonstrações de como os testes unitários podem ser usados com esta ferramenta.
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.
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;
...
