Technè

Essa dica vale para qualquer versão do Visual Studio

Porque testar com NUnit?

Estou trabalhando em um projeto que roda tanto no Windows quanto no Linux (usando Mono), se eu usar o teste de unidade que já vem no Visual Studio estarei limitado a IDE, e lá no Linux estou usando o MonoDevelop para desenvolvimento.

Quais as minhas alternativas?

Para integrar o NUnit ao Visual Studio você tem, basicamente, duas opções: ou você compra uma ferramenta que faz isso pra você, ou você usa a interface que já vem com o NUnit e integra ela ao Visual Studio. Se alguém conhecer outra forma, eu gostaria de saber.

1) Se você optar pela primeira alternativa, você vai ter que comprar uma ferramenta como TestDriven.Net, ReSharper ou alguma outra. O problema dessas ferramentas é que elas são pagas, e eu mesmo que não quero pagar pra rodar testes de unidade. Se você já usa uma dessas ferramentas, só continue a ler se você quiser aprender como integrar o NUnit sem o auxílio delas.

2) Na segunda alternativa temos duas outras opções para integração. (a) criar o projeto de testes como um projeto executável e chamar a GUI dentro dele passando a DLL de testes como parâmetro (particularmente acho essa opção uma gambiarra e não recomendo isso pra ninguém); (b) a segunda, e mais elegante, é configurar o Visual Studio para chamar essa interface do NUnit já passando o projeto selecionado como parâmetro.

Como configurar o Visual Studio?

Você só vai precisar executar dois passos para configurar o Visual Studio. (passo 1) Ir no menu Tools > External Tools. (passo 2) Entrar com os dados segundo a imagem abaixo. Após esses dois passos, vai aparecer um novo item no menu Tools chamado “NUnit”. Você pode clicar nele para executar a GUI do próprio NUnit aplicado ao projeto corrente.

Como depurar meus testes?

Uma vez que você esteja com a GUI do NUnit aberta e rodando (rodando a interface e não o teste), você pode informar ao Visual Studio que você deseja testar aquele programa que está rodando fora. E como eu faço isso? Você vai no menu “Debug > Attach to process” e seleciona o programa do NUnit que está executando, da mesma forma que ilustrado na figura abaixo.

Agora você pode rodar seus testes de unidade usando NUnit sem ter que usar uma ferramenta de terceiros.

Com a necessidade de testar de forma diferente os sistemas, produtos, hardwares, os testes também evoluem.

Quando preciso testar uma função específica em um sistema, realizo testes funcionais. Quando preciso testar se meu sistema suporta vários acessos simultâneos faço teste de carga. E quando eu preciso testar se meu sistema funciona para qualquer implementação que é compatível com o que foi especificado na API (Application Programming Interface – http://pt.wikipedia.org/wiki/API) ? Isso é teste de quê?

Bem, a literatura chama de teste de conformidade os testes que realizamos para validar (por exemplo) uma API, pois nesse caso não se testa um produto específico e nem uma implementação específica. A finalidade é testar se as implementações que foram desenvolvidas e baseadas no que foi especificado na API funcionam.

Os testes de conformidade não se preocupam com robustez, desempenho ou até facilidade de uso. Esses testes estão preocupados somente em verificar se a implementação da tecnologia está conforme a especificação.

Caramba, mas eu testo o que com isso? Aqui no CESAR temos experiência na aplicaçã0 desse tipo de teste em vários projetos que envolvem o desenvolvimento de componentes ou softwares baseados em especificações públicas (também conhecidas como API’s).

Pra especificar os testes, criamos um processo: a partir da norma, extraímos toda afirmação que é testável,por exemplo, um método que retorna um booleano ou um método que lança uma exceção e chamamos isso de Assertiva.

Depois precisamos classificar cada assertiva, pois nem sempre quando identificamos que algo é testável sabemos como testar. Quando sabemos o que testar e como testar, classificamos a assertiva como testável. Quando identificamos algo na norma que não conseguimos testar, classificamos a assertiva como não testável (registrando o porquê de não ser testável) e quando a afirmação é ambígua ou não está completa, classificamos a assertiva como ambígua (registrando o porquê de ser ambígua).

Depois de classificar todas as assertivas que listamos, fazemos uma análise para garantir que nenhuma assertiva se repete ou se podemos agrupar alguma das assertivas já descritas.

Por fim, criamos os testes baseados na especificação de cada assertiva e não necessariamente somente um teste é criado para cada assertiva. Considerando o mesmo exemplo de testar um método que retorna um valor boleano devemos verificar o comportamento quando true e false forem retornados.

Usando essa metodologia, além de conseguirmos testar uma API, temos em mãos o percentual de cobertura da norma. Nosso relatório de rastreabilidade consegue informar quantas assertivas criamos, quantas são testáveis, quantos testes foram criados para cada assertiva testável e quanto da norma foi coberta.  E o que não foi coberto, conseguimos dizer a razão pra isso.

Então se você pretende saber se sua implementação foi desenvolvida conforme a especificação, podemos criar testes de conformidade pra você.

Referência: Java Technology Test Suite Development Guide 1.2; http://java.sun.com/javame/meframework/docs/testsuite_devguide.pdf