Por que eu devo ler este artigo:Este artigo é útil porque apresentará para o leitor a metodologia Test-Driven Development (TDD) e como aplicá-la em projetos .NET.

O TDD preza pela realização de testes no código antes mesmo de implementar as funcionalidades propriamente ditas, reduzindo a quantidade de erros, aumentando a qualidade do código e permitindo ao desenvolvedor conhecer melhor as regras de negócio que estão sendo implementadas.

Veremos também como utilizar a técnica de mock no apoio ao TDD, prática bastante útil em cenários onde é necessário realizar testes com dados fictícios, pois facilita a geração de objetos para testes a partir de modelos do domínio da aplicação.

Durante o ciclo de vida de um software, os requisitos inicialmente estabelecidos geralmente mudam, novos são adicionados e outros removidos.

Claro que isso não vem de hoje, mas tornou-se muito mais constante devido às novas possibilidades de produzirmos softwares para diversas plataformas, por exemplo.

Sempre estamos evoluindo e os estilos tradicionais de desenvolvermos novos produtos enfrentam desafios significativos, como a necessidade constante de facilitar a manutenção.

Realizar alterações em uma aplicação desenvolvida e prestes a entrar para o mercado, tradicionalmente, pode causar indisposição junto aos seus clientes de formas difíceis de serem previstas.

Como resultado, as organizações hesitam em fazer mudanças que são necessárias para o software, impedindo assim o seu melhor desempenho e consequentemente seu sucesso perante as organizações que dele dependam.

Neste quesito, no que diz respeito à mudança, é que entramos no tema deste artigo, cujo foco é trabalhar em testes com base na metodologiaTest-Driven Development (TDD).

O intuito deste artigo é apresentar de forma prática e simples como podemos trabalhar numa aplicação baseando-se em testes para as funcionalidades que desejamos implementar, de forma a reduzir falhas no sistema.

Com TDD podemos aumentar a nossa produtividade, pois iremos reduzir a quantidade de depurações necessárias para detecção de erros, teremos uma melhor visualização do nosso código, tornando mais simples a leitura dele, dentre outras vantagens que refletem de forma direta na construção de um software de qualidade.

Para praticar os conceitos que serão apresentados aqui, criaremos uma aplicação simples de carrinho de compras, no qual estaremos vendo a utilização de um “simulador de banco de dados” conhecido por Moq, que auxilia na geração de dados fictícios para testes.

Uma prévia sobre TDD

Nos últimos anos, houve uma série de novidades em torno da metodologia de TDD e sua real eficácia com relação ao desenvolvimento das mais diversas aplicações. Mesmo com a desenvoltura que podemos encontrar nas técnicas do TDD, ainda existe muita relutância na sua utilização, principalmente relacionada aos prazos para desenvolvimento e entrega de projetos.

Ao trabalharmos com desenvolvimento baseado em testes, temos primeiramente a mudança do nosso foco, que neste momento passa a se voltar para tecnologias ágeis e práticas baseadas em testes como sendo as operações primárias para o desenvolvimento de sistemas complexos e de alto desempenho.

O Test Driven Development é uma metodologia de desenvolvimento avançado com foco na qualidade do software orientado a objetos, amplamente utilizado dentro da comunidade Agile. O que torna o TDD único é o seu foco na especificação do projeto, ao invés de ser na sua validação.

A abordagem TDD leva a uma melhor arquitetura de software de qualidade, melhorando a qualidade, simplicidade e capacidade de teste, enquanto aumenta a confiança no código e a produtividade da equipe.

Ao implementarmos essa metodologia, os testes utilizados são compostos de afirmações verdadeiras e falsas que indicam o comportamento correto com relação ao teste que está sendo usado no momento.

Nesta abordagem criamos testes automatizados de unidades antes mesmo de escrevermos o código específico. Ao escrevermos inicialmente os testes, estes não só nos ajudam na medição dos testes propriamente ditos, mas também forçam o desenvolvedor a se concentrar no conceito do design avançado desde o início.

Através do desenvolvimento de um conjunto de casos de teste funcional inicialmente, os desenvolvedores podemos ter a certeza de que terão sempre um software com o mínimo de falha possível, além de que as características recém-aplicadas serão aplicadas conforme o esperado.

Para o TDD, temos que uma unidade é definida basicamente como sendo uma classe ou um grupo de funções relacionadas, muitas vezes chamado de módulo. Com a disposição de unidades relativamente pequenas, podemos oferecer benefícios críticos à nossa aplicação, como é o caso da redução dos esforços no momento da depuração, além de que testes pequenos melhoram a legibilidade e compreensão mais rápida e eficiente do que é preciso fazer.

O ciclo do TDD: Red-Green-Refactor

O TDD é conduzido por uma filosofia básica, conhecida como "Red-Green-Refactor" (Figura 1), que é um microciclo de desenvolvimento iterativo no qual os testes e comportamentos são implementados.

Neste processo, o que ocorre primeiramente é que os casos de teste recém-escritos testam o código ainda não escrito e, devido a isso, falham. Esta é a primeira etapa, definida como Red.

A partir deste momento o desenvolvedor implementa o recurso da maneira mais simples, fazendo com que os testes correspondentes sejam bem-sucedidos, o que representa o segundo passo do ciclo, o Green.

E por fim, antes de começarmos com um novo teste, podemos realizar o processo de refatoração do código de forma a deixá-lo o mais claro e eficiente possível, de forma a proporcionar confiança pela capacidade de executar o teste novamente que foi implementado.

Este é o terceiro item do ciclo, a Refatoração (ou Refactor). Ao adotarmos o ciclo Red-Green-Refactor, temos que o nosso código pode evoluir para um nível superior de comunicação simplificada, confiança e produtividade global.

Figura 1. Ciclo RGR (Red-Green-Refactor).

Ao trabalharmos com base no ciclo TDD, somos levados a desenvolver de forma mais rápida, de forma que, ao termos uma alteração no código concluído, este será testado automaticamente. Iss ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo