Você encontra nesse artigo:
- A razão por que você precisa fazer testes funcionais e estruturais (NUnit)
- Como melhorar a qualidade da comunicação dos documentos de especificação fazendo com que os consumidores testem o código com FIT
- WinFITRunnerLite, um programa que permite que os arquivos do Excel sejam executados como testes funcionais de seu software
- Um episódio de desenvolvimento de exemplo que mostra como testar o software usando o FIT e WinFITRunnerLite
A maioria dos documentos de especificação não fornece a história completa dos produtos que eles definem. Geralmente, ninguém percebe isso até perder um tempo de desenvolvimento significativo no projeto. Para que as especificações sejam verdadeiramente úteis, elas precisam dar uma visão precisa de todos os requisitos de um projeto.
Neste artigo, demonstrarei como a qualidade de comunicação dos documentos de especificação pode ser melhorada ao se permitir que os usuários testem o código em construção usando o FIT (Framework for Integrated Test), uma ferramenta de código aberto. Explicarei como você pode criar um aplicativo Windows® Forms em C# (WinFITRunnerLite) que converte testes funcionais (conforme criados por seus clientes no Excel) em um form que permite eles sejam executados junto com o FIT no código que você está desenvolvendo. Apresentarei também um exemplo de desenvolvimento prático para explicar como você pode configurar e executar esse tipo de teste de cliente usando o FIT e o WinFITRunnerLite.
Testes de Cliente
O teste de unidade automatizado usando o NUnit é destinado aos desenvolvedores. Ele valida a operação do código no nível das classes e seus métodos. No entanto, o teste estrutural por si só não é suficiente para garantir que você possa liberar o software para produção confiante de que ele vá compensar o preço (custo) do negócio.
Considere um método que calcule porcentagens precisas de até duas casas decimais. Um teste de programador atesta seu comportamento, então você envia o software ao cliente certo de que ele calculará corretamente as taxas de vendas das faturas. No entanto, no dia seguinte ele está ao telefone reclamando porque a taxa de vendas total das faturas não coincide com a soma das taxas de vendas de cada item individual. Essa é uma situação onde você pode executar um teste funcional simples para provar que a taxa foi calculada corretamente. Vamos ver agora como você pode executar esse tipo de teste de função em dois tipos diferentes de projetos.
No caso de um projeto de Extreme Programming (XP), você se senta com o cliente para discutir sobre o que o software precisa fazer; nesse caso, calcular a taxa de vendas em uma fatura. Juntos, vocês elaboram os detalhes das necessidades do cliente, ou seja, a "história" dele. O cliente detalha seus requisitos para cada história em termos de testes funcionais, conhecido no XP como testes de aceitação ou de cliente. Os desenvolvedores começam a trabalhar na implementação das histórias sabendo quais testes são relevantes ao cliente. A história propriamente dita só é considerada concluída quando passa pelos testes de unidade e do cliente. Nos projetos de desenvolvimento rápido que utilizam técnicas como XP, esses testes de clientes são avaliados durante o ciclo de desenvolvimento e são importantes porque ajudam os clientes a comunicar seus requisitos aos desenvolvedores para que estes definam os critérios de aceitação para o software acabado.
Os testes funcionais são chamados de testes de black-box (caixa preta) porque são escritos sem qualquer conhecimento de como o software funciona. Eles simplesmente definem a ação que o software precisa fazer (em termos de respostas mensuráveis) no caso de determinadas entradas externas em um ambiente específico. Essa abordagem de teste é a base do teste de cliente, bem como o fundamento de muitos outros tipos de testes executados em um produto de software durante o seu desenvolvimento.
Embora a sua tarefa como desenvolvedor seja decidir como o software vai funcionar, é responsabilidade do cliente saber o que o software precisa, por isso ele precisa opinar na criação dos testes funcionais. Nos projetos tradicionais, esse envolvimento é indireto, sendo feito por meio do analista de negócios e de um tester. No entanto, acredito que a abordagem rápida de envolver os clientes diretamente na criação de testes funcionais leve ao desenvolvimento de softwares mais úteis, que fazem o que se espera deles.
O Que é o FIT e como ele funciona?
O Framework for Integrated Test permite que os clientes escrevam seus testes no formato de tabelas HTML que podem então ser executadas diretamente com o código sob teste. Por exemplo, um cliente pode usar o Microsoft® Word para criar um documento de especificação que contenha vários testes (inseridos em tabelas), bem como os valores de entrada e os resultados esperados, conforme mostrado na Figura 1.
Esse documento HTML pode então ser usado como um arquivo de entrada para o FIT, que analisa o HTML e corresponde cada tabela a um método de teste correspondente no código de teste do software, conforme descoberto por reflection. O FIT invoca o método test, passando os parâmetros de leitura da tabela HTML, e executa o teste. Os resultados são capturados em um documento de saída HTML do mesmo formulário como o arquivo de entrada, mas com todos os erros adicionados nas células de cada tabela. O cliente pode ver os resultados dos vários testes abrindo o arquivo de saída em seu navegador. A Figura 2 mostra que determinado teste falhou porque o cliente calculou incorretamente o resultado do teste. Mais adiante neste artigo, explicarei o processo de teste do FIT e como ele se relaciona com o Excel, mas por enquanto quero me concentrar no formulário dos testes, tanto no documento HTML como no test fixture do software.
Um test fixture é um fragmento de código que suporta um teste. Tal código é geralmente mantido em bibliotecas de teste (DLLs) separadas das bibliotecas de código de seu domínio, por isso eles não são liberados para o ambiente de produção. Você mantém todos os componentes do software sob teste nas bibliotecas de código do domínio. No ambiente de teste, o FIT é informado de onde pode encontrar tais bibliotecas de teste e descobre as classes e métodos usando reflection. Em seguida, ele executa um teste específico, instanciando o objeto de teste apropriado e invocando o método necessário para executar o test fixture, passando e recuperando os parâmetros conforme especificado no documento de especificação de teste em HTML. Por sua vez, o código que forma o test fixture cria os objetos a partir das bibliotecas de código do domínio e chama seus métodos, passando e recebendo os dados e, desta maneira, exercitando o software sob teste.
...
