sábado, 12 de
julho de
2008.
|
Testes Unitários Dicas Iniciais 
(Comente)
Tenho publicado uma série de posts sobre testes unitários nas últimas semanas, quem acompanha o blog certamente notou…pois bem, os testes estão indo de vento em poupa.
Neste post pretendo encorajar aqueles que precisam ouvir boas experiências com este tipo de abordagem bem como tentar deixar bem claro alguns limites nestes testes.
Se você começou a escrever testes unitário agora, você deve estar se fazendo uma série de perguntas, seus testes podem parecer um pouco sem sentido, repetitivos e em algum momento você vai ter que ir no ‘pai google’ procurar respostas, boas práticas e dicas.
Pois bem, comigo não foi diferente, visitei inúmeros sites, li e escutei várias opiniões…e foram delas que alinhei minhas expectativas, aprumei o rumo e segui em frente…para o alto e avante!
Perguntas do tipo:
i. Qual a vantagem desta abordagem?;
ii. Posso testar todo o sistema usando esta abordagem?;
iii. Meus testes são confiáveis?;
iv. Quais os meus limites? Onde começo? Onde paro?
Você fará quando começar a por a mão na massa, tentarei expor minas opiniões sobre elas, a seguir…
i. Qual a vantagem desta abordagem?
Bug custa caro!
Todos nós engenheiros de teste sabemos…se não sabem, deveriam saber!…quanto mais tarde no ciclo de vida de um software um bug é encontrado, mais caro ele se torna. Um bug achado durante a especificação pode custar $1 para corrigir…$10 se achado no design…$100 se achado na implementação…$1000 na entrega do produto.
A idéia por trás dos testes de unitários é achar bugs mais cedo, quando um bug é achado nos testes unitários, corrigi-lo é trivial, pois o desenvolvedor está com lógica de seu código ainda fresca em sua mente, mas também não adianta nada achar bugs saídos do forno, se sua equipe não corrige o bug antes de produzir novos códigos, dêem uma lida no trecho retirado do blog Joel on Software.
[...]The very first version of Microsoft Word for Windows was considered a “death march” project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.
What they realized was that the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”[...]
Ou seja, se sua equipe, gerentes e/ou líderes técnicos, não dedicarem o tempo de sua equipe para a correção de bugs achados durante esta fase, nada vai dar certo, portanto, antes de começar a escrever testes unitários converse com eles, mostre-os a vantagem de adotar esta abordagem, na maioria das vezes os gerentes de projeto gostam desta idéia.
ii. Posso testar todo o sistema usando esta abordagem?
Não!
Nem comece a implementar se você acha que 100% de seus testes vão ser unitários, uma aplicação precisa de uma atenção bem especial na sua interface, não é lá que estão a maioria dos bugs mas ali tem muito bug sim!
No caso do MVC com .NET (padrão muito comum em aplicações WEB com .NET) desenvolvedores costumam usar muito o codebehind para fazer validações, que muitas vezes deveriam ser feitas no controlador, pois é lá que deve conter o ‘core’ de sua regra de negócio, mas mesmo assim existem validações pequenas que devem ser feitas na view, e isso deve ser testado na interface.
Existem ferramentas com o propósito de automatizar testes no codebehind, NUnitAsp é um exemplo, mas isso eu pessoalmente não recomendo, pois você pode cair no vício de nunca na sua vida olhar pra a cara de seu produto, enfim, acho que o que está no codebehind, deve ser testando na própria interface.
iii. Meus testes são confiáveis?
Sim…e Não!
Cometemos muitos erros logo no início, não sabemos o que testar e por várias vezes ficamos bem confusos quanto ao escopo dos testes, quando falo ‘Sim, são confiáveis’ digo porque acredito que você sabe fazer seu teste funcionar, quando digo ‘Não, não são confiáveis’ digo porque inicialmente você pode estar testando o que não deve.
Teste o comportamento, não o método.
O que devemos estar preocupado é o com o comportamento do método no contexto da aplicação, certo? então tenha a certeza que o método que você está testando se comporta da forma esperada, apenas isso.
Teste métodos públicos, esqueça os privados.
Métodos privados geralmente compõem um objeto e não devem ser diretamente testados.
Estes dois exemplos foram o que me veio a mente, posteriormente publicarei minhas lições aprendidas na implementação de testes unitários.
iv. Quais os meus limites? Onde começo? Onde paro?
Não escreva testes pra todos os métodos existentes no código, existe um limite muito bem definido neste caso, se limite aos cenários que serão amplamente utilizados pela aplicação e se o custo de implementar um teste for alto, não implemente.
Testes devem ser simples, secos e ásperos, nada de códigos mirabolantes no seu teste, se ele estiver assim está errado.
Bem, por enquanto é só, espero ter ajudado com este post, posteriormente estarei postando sobre minhas experiências na implementação dos testes, boas práticas e dicas, qualquer coisa é só comentar!
13 Opinioes
Testes Unitários Dicas Iniciais | ...zezologs... Dicas iniciais para quem tem interesse em realizar teste unitários ...
Opine!
Resumo do post:
Dicas iniciais para quem tem interesse em realizar teste unitários
Categoria(s):
Testes Unitários
Link Permanente: http://www.zezologs.org/blog/testes-unitrios-dicas-iniciais/
Tag(s): Testes Unitários
Este post tem 851 vizualizações
Translate this post to english
|
Avalie este post: |
 Testes Unitários com csUnit Testes Unitários com componente do .NET Estimando Esforço de Automação Template de Relatório de Testes do VS Executando Testes com o MSBuild |
 |
 |
 |
 |
 |
 |
| veja mais em market zezo | ||
Juliano Oliveira
21-09-2008
Sobre a passagem:
“No caso do MVC com .NET (padrão muito comum em aplicações WEB com .NET)”
Acho que você se confundiu ao dizer que o ASP.NET MVC é um padrão comum! Afinal, o ASP.NET MVC está em fase de desenvilvimento, no momento está na quinta Preview do framework! Ou você está se referindo a outra coisa?
Fora isso, bem legal o post!
[]´s
eudescosta
21-09-2008
Opa Juliano,
Então, adotamos este padrão em nosso projeto.
Dá uma olhada no post http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx
Abraço!
Juliano Oliveira
22-09-2008
Então,
Eu conheço bem o ASP.NET MVC, tenho estudado ele desde o fim do ano passado, eles vêm aplicando muitas idéias legais. Acho que é bem melhor que Web Forms.
Pretendemos adota-lo aqui na empresa também mas ele ainda está em fase Alpha!
É perigoso adota-lo no momento. Já pensou você implementa uma aplicação inteira com as caracteristicas de uma Preview 5 (a mais atual no momento) e ao sair a Release ela vem com diversas implementações diferentes!
Mas é muito bom esse framework! Estou aguardando ansioso as implementações de Ajax nativas do framework! Vai brigar com Ruby on Rails em produtividade!
[]´s
Ju
13-01-2009
Boa tarde,
Confesso que seu flog foi muito construtivo para mim pois estou começando na área de qualidade e testes de softwares para web da empresa e ainda sou muito crua no assunto, tenho muitas duvidas primárias de como é implantado o teste unitário, se puder me ajudar ficaria muito agradecida.
primeiro criei o ambiente com Visual Studio 2008, Nunit e o Test Driven.Net mas gostaria de entender melhor como funciona esta integração.
1- eu preciso ter em todas as máquinas dos desenvolvedores este ambiente instalado?
2- no projeto que vou testar tem que possuir os testes ou é possível colocar todos os testes criados em uma base de dados unica e separada e quando for rodar no nunit ele de alguma forma pegar os testes desta base de dados e textar o código carregado nele?
3- e se eu quiser encrementar uma unica base de dados de teste para q os desenvolvedores joguem seus testes em um a unico lugar por exemplo um servidor para todos terem acesso a mesma base de dados isso é possível?
Ai depois é só jogar o código no servidor e botar p rodar os testes q estão na base de dados?
4- como isso é feito?
5- cada metodo tem q ter um conjunto de códigos especificos? mas é possível esta criação do banco de dados…ai qd for rodar um codigo pegar só os testes especificos?
Se estou falando um monte de asneiras por favor gostaria q me esclarecesse se fosse possível!
desde já agradesço pela ajuda!
eudescosta
14-01-2009
Olá Juliana,
Vou tentar responder suas perguntas
1. Se os desenvolvedores vão rodar os testes, sim, mas se apenas você vai rodar os testes não precisa, o NUnit precisa apenas dos .dll da sua aplicação para rodar os testes, desta forma não há a necessidade de ter o NUnit e o Test Driven.Net.
2. Se entendi bem, queres escrever testes genéricos…mas não seus testes dificilmente irão funcionar, testes unitários/initegração são para uma classe em específico.
3. Você usa alguma ferramenta de gerência de configuração? Utilizar uma ferramenta destas, como CVS, SVN, Tortoise, etc… é recomendado neste caso.
4. Tem que instalar alguma a ferramenta que falei acima.
5. Sim, cada método tem que ter um conjunto de testes específicos.
Ju
14-01-2009
Obrigada pela ajuda,
mas então deixa eu ver se entendi…a melhor forma de se implantar um teste unitário é:
1- baixar o Nunit em cada máquina dos desenvolvedores
2- Orientar os desenvolvedores a fazerem os testes unitários
3- Os proprios desenvolvedores rodarem os testes
4- Enviar para a fase de homologação apenas quando todos os testes unitários e de integração estiverem ok e a área de qualidade fazer apenas testes de caixa preta
Seria assim o processo?
1- mas como posso garantir que os desenvolvedores fizeram e aplicaram os testes unitários?
2- na hora de colocar o método no programa completo eles retiram do projeto os testes e fazem o que com eles? já que não é viável criar um BD estes testes são descartados?
Mais uma vez obrigada,
eudescosta
14-01-2009
Por processo, quem escreve os testes unitários são os desenvolvedores, mas, infelizmente eu não confio nos testes que a maioria deles irá escrever, pois não é de interesse deles achar bugs, certo?
por isso eu acho que eng. de testes devem escrever.
ou seja dependendo da forma como vc vai trabalhar (ou você escreve ou eles escrevem) os passos acima irão mudar.
pela literatura da eng. de software o processo é como vc falou acima, sim.
1. Os desenv. escrevem os testes unitários
2. Os desenv. rodam
3. Os desenv. so liberam quando os testes passarem
mas lembre-se o ‘passar’ dos desenvolvedores pode ser diferente do seu ‘passar’, haja vista que vc eng. de testes será bem mais criteriosa que eles
Ju
14-01-2009
Gostaria de entender também como funciona o teste de integração com ferramentes como Hudson ou CruiseControl.NET (CCNet), eles ficam num servidor separado porque? como é feito este teste?
obrigada,
Ju
14-01-2009
Em algumas pesquisas ví que o teste unitario é possivel ser feito automaticos também usando está ferramente…como funciona?
eudescosta
14-01-2009
@ Juliana
http://www.zezologs.org/blog/testes-unitrios-com-csunit/
http://www.zezologs.org/blog/testes-unitrios-com-componente-do-net/
http://www.zezologs.org/blog/testes-unitrios-nunit-c/
Juliano Oliveira
14-01-2009
Ju,
Se você estiver desendo sobre uma plataforma Team Fondation Server, você pode adicionar politicas de checkins que só permitem checkins quando os códigos passarem nos testes.
Você deve definir a filosofia de checkins da empresa. Depende muito do modo que vocês trabalham.
[]´s
Ju
14-01-2009
Muito obrigada pelos esclarecimentos!!!!
bjs