Antes de qualquer coisa, vamos nos abstrair pelo menos nos próximos paragráfos, dos limites existentes entre os papéis de engenheiro de testes e CM ou líder técnico, e vamos focar onde quero chegar, previnir ou achar erros mais cedo.

Como quem acompanha o blog deve ter notado, tenho realizado alguns PoC´s para um novo projeto que se inicia aqui no trabalho, semana passada fiz várias avaliações de ferramentas para testes unitários e avaliei dentre outras coisas a sua integração com a IDE de desenvolvimento utilizada, Visual Studio 2008, pois bem, vamos ao que interessa.

A avaliação que fiz desta vez, foi sobre o MSbuild, uma ferramenta da Microsoft para geração de builds, o uso do MSBuild é bastante amplo, e não vou abordar todas as aplicações desta ferramenta, minha intenção é apenas mostrar o quão simples é (muito mais do que se imagina) rodar seus testes com o MSBuild, de forma que se 01 (um) teste sequer falhar o processo de geração de build é interrompido.

Bem, se você usa o Visual Studio Professional 2008 o msbuild já vem junto com a instalação, mas ele geramlente fica na pasta “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727″ o que faz com que ao digitar “MSBuild.exe” na pasta de seu projeto, o Windows não reconheça, pra resolver isto é simples apenas adicione o caminho da pasta acima, nas váriaveis de ambiente em “System Properties” >> “Advanced” >> “Environment Variables” em “System Variables” procure pela entrada PATH, e adicione o caminho acima.

Proseguindo…usarei o mesmo código que venho utilizando nos exemplos passados em “Testes Unitários com csUnit“, “Testes Unitários com componente do .NET” e “Testes Unitários: NUnit & C#“.

Agora vamos editar o arquivo do projeto, .cproj, e incluir ativdades postbuild, ou seja, quando o MSBuild finalizar o processo de geralção de build ele irá executar a atividade especificada.

1º Forma

Desative o projeto

Edite o .cproj

No arquivo .cproj que o VS abrirá, acresente a linha a seguir no final do arquivo
[sourcecode language='xml']

mstest /testcontainer:.NETTests.dll

[/sourcecode]
2º Forma

Selecione as propriedades do projeto.

Em build events inclua a linha “mstest /testcontainer:.NETTests.dll” como mostrado abaixo

Salve tudo e reative o projeto.

Abra o commmand prompt, e vá até onde está o projeto que você quer gerar a build e digite a palavrinha mágica msbuild. Ele irá iniciar o processo de geração de build, e deverá exibir algo como a imagem abaixo:

Caminhando agora a parte que interessa, olhem para os logs do MSBuild abaixo que chamarei de CASO01 e CASO02

CASO01

Loading .NETTests.dll…
Starting execution…

Results Top Level Tests
——- —————
Failed NETTests.TestesCodigo001.Looping
Failed NETTests.TestesCodigo001.NegativeTest
Failed NETTests.TestesCodigo001.SendingStringToCotacao
Failed NETTests.TestesCodigo001.SendingStringToReal
Passed NETTests.TestesCodigo001.SuccessTest
1/5 test(s) Passed, 4 Failed

Summary
——-
Test Run Failed.
Failed 4
Passed 1
———
Total 5

Results file: D:\Visual Studio Proejcts 2008\Testes\.NETTests\bin\Debug\
TestResults\ejoc_ROMANA 2008-06-03 14_47_48.trx
Run Configuration: Default Run Configuration
Done Building Project “D:\Visual Studio Proejcts 2008 Testes\Testes.sln” (default targets) –FAILED.

Build FAILED.

CASO02

Loading .NETTests.dll…
Starting execution…

Results Top Level Tests
——- —————
Passed NETTests.TestesCodigo001.SuccessTest
1/1 test(s) Passed

Summary
——-
Test Run Completed.
Passed 1
———
Total 1

Results file:D:\Visual Studio Proejcts 2008 Testes\.NETTests\bin\Debug\
TestResults\ejoc_ROMANA 2008-06-03 14_51_39.trx
Run Configuration: Default Run Configuration
Done Building Project “D:\Visual Studio Proejcts 2008\Testes\.NETTests\.NETTests.csproj” (default targets).

Done Building Project “D:\Visual Studio Proejcts 2008\Testes\Testes.sln” (default targets).

Build succeeded.

Notaram a diferença? no CASO01 a build nem foi gerada pois 4 testes falharam, já no CASO02 a build foi gerada pois os testes passaram.

Notem como o procedimento é simples e os resultados são fantásticos, o retorno disso é evidente:

1. A correção da CR é bem mais produtiva, hava vista que o bug está “fresquinho” na cabeça de quem codificou;

2. Overhead de testes reduzido pois isso irá diminuir consideravelmente o esforço de testes funcionais, realizados mais a frente.

e tem muito mais…

Bem é isso, vejam como pode ser mais simples do que as vezes imaginamos, previnir que erros aconteçam

comentários

leia mais...

• Tasks do MSBuild com o msbuildtasks
• Testlink: Exportação de Casos de Teste
• Eficiência da Equipe de Testes
• Template de Relatório de Testes do VS
• Automação e Códigos Não Testáveis