terça-feira, 3 de
junho de
2008.
| Post Atualizado. |
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
<PropertyGroup> <PostBuildEvent>mstest /testcontainer:.NETTests.dll</PostBuildEvent> </PropertyGroup>
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
1 Opiniao
[...] implementação destas tasks, é feita como falei em Executando Testes com o MSbuild, utilizando o arquivo do [...]
Opine!
(Comente)
(Vote!) 





