Conceito: Testes de Desenvolvedor |  |
Os desenvolvedores executam teste de regressão em seus códigos de forma contínua para assegurarem-se de que o código funciona como o esperado.
Relacionamentos
Elementos Relacionados | Desenvolvimento Evoluir o Design Executar os Testes de Desenvolvedor Implementar os Testes de Desenvolvedor Integração Contínua Testes de Desenvolvedor
Descrição Principal
O Teste de Desenvolvedor é o ato dos desenvolvedores executarem testes de regressão em seu código fonte. Isto é chamado às vezes de "teste de regressão unitário", mas muitos testes de desenvolvedor vão além dos testes unitários, abrangendo testes de integração. ### Filosofias de Teste Aqui estão algumas filosofias importantes a respeito do teste de desenvolvedor: O objetivo é encontrar defeitos. Os testes bem sucedidos encontram erros, mas a correção dos erros pertence a outras áreas. Teste o mais cedo possível e com a maior freqüência. O custo da mudança cresce exponencialmente na razão do tempo necessário para encontrar e remover o defeito. A implicação é o desejo de executar o teste o mais cedo possível (o mais cedo que você puder testar, veja Guideline: Design Teste-primeiro). Teste a confiança das configurações. Muitas pessoas temem fazer uma mudança no seu código porque ficam receosas de estragá-lo, mas com uma ferramenta de teste completa, se você estragar algo você sabe que poderá detectar e reparar o erro. Um teste vale mais que mil opiniões. Você pode dizer que a sua aplicação funciona, mas até que você mostre os resultados do teste você não terá credibilidade. Teste para o risco. Quão mais arriscada uma coisa for mais necessário será revê-la e testá-la. Em outras palavras você deve investir esforço de teste necessário no algoritmo para estimar doses de radiação, mas nada muito perto do esforço para testar a função de "troca de tamanho de fonte" da mesma aplicação. Você pode validar todos os artefatos. Você pode testar todos os seus artefatos, não apenas seu código de fonte, embora o foco desta orientação seja o teste de código. ### Características de um Bom Teste de desenvolvedor Estas são as qualidades de um bom teste de desenvolvedor: Executa rápido. Tem instanciação, tempo de execução e rotina de limpeza rápidos. Executa isoladamente. Você deve ser capaz de reordenar seus testes. É compreensível. Os bons testes têm nomes consistentes e informativos e usam dados que os tornam fáceis de ler e compreender. Usa dados reais. Por exemplo, use cópias de dados da produção quando apropriado, mas lembre-se que você também terá que criar alguns dados de teste "artificiais". É minimamente coesivo. O teste representa um passo na direção do seu objetivo maior. O teste deve tratar um e somente um problema. ### Abordagens para a Instanciação do Teste Para executar um teste com sucesso, o sistema deve estar em um estado conhecido. Para fazer isto você necessitará de objetos ou componentes na memória, registros na base de dados, etc. nos quais você executará os testes. A abordagem mais fácil é a codificação manual dos dados necessários e do código de instanciação dentro do próprio teste. A principal vantagem é que todas as informações necessárias para o teste estão em um único lugar, tornando o teste potencialmente auto-suficiente. Uma outra abordagem é definir um conjunto de dados externos que seja carregado na memória ou na base de dados no início da execução do teste. Há diversas vantagens nesta abordagem: Isto desacopla os dados do teste. Mais de um teste pode usar o mesmo conjunto de dados. É fácil modificar e/ou multiplicar os dados de teste. Existem algumas desvantagens nesta abordagem: Aumento na complexidade para manter os dados externos Potencial acoplamento entre os casos de teste. Quando os testes compartilham um mesmo conjunto de dados torna-se muito fácil escreve-los de forma que dependam que outros testes sejam executados primeiramente, acoplando-os desse modo. ### Codificando para a Testabilidade Adicione instrumentação de código para testar e depurar. Preste especial atenção à implementação dos pontos de observação/controle, tais como funções ou objetos críticos, visto que estes aspectos podem necessitar de suporte especial que deve ser implementado no componente sob teste. ### Revisando testes Se um teste for de longa-vida, peça a uma pessoa com menos conhecimento do interior do componente para executá-lo e verificar se existe bastante informação de suporte. Revise-o com outras pessoas da equipe de desenvolvimento e outras partes interessadas se for necessário.
Este programa e o material que o acompanha são disponibilizados sob a Eclipse Public License v1.0 que acompanha esta distribuição. Direitos Autorais do OpenUP.