Como você chama os desenvolvedores do conjunto de testes executados antes do check-in? [fechadas]

Estou trabalhando em um projeto no qual estamos adicionando testes automatizados a um projeto existente. Começamos com um componente central e configuramos os testes de unidade no nível do módulo de código e os testes que são executados em todo o componente, embora no ambiente do desenvolvedor. A intenção é que esse conjunto de testes seja aprovado antes do check-in de código e será executado por um sistema de integração contínua em cada filial de desenvolvimento.

Como devemos chamar isso? No momento, estamos chamando de "testes unitários de desenvolvimento", mas meu lado pedante diz que isso não está certo, porque contém mais do que testes unitários. E nossa visão é que esse conjunto cresça ao longo do tempo para incluir testes de aceitação de produtos completos.

Alguma entrada aqui? Ou devemos parar de discutir sobre nomes e escrever testes?

Atualizar

Todo mundo, obrigado pela boa discussão! Acho que a conclusão a que chego é que não há realmente uma definição "comum" - cada projeto / equipe cria nomes que fazem mais sentido para esse projeto, dependendo das tecnologias (Java, C #, ruby, etc.) e metodologias (cascata de skool antigo, Scrum, XP, etc.) em uso.

Eles são conhecidos como "check-ins fechados" no MSFT TFS. http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx

Ligue para o que quiser, não importa. O que importa é a qualidade dos testes e a execução deles.

Nossos testes são testes de aceitação automatizados, mas apenas os chamamos de "testes" aqui no meu trabalho. Como em:

• conserte seus "testes"
• você quebrou os "testes"
• você escreveu um "teste"
• esse "teste" é péssimo, então eu o reescrevi

Eu os chamo de "testes" com a implicação de que estou falando sobre os "testes de unidade automatizados" e com a implicação corolária de que eles são rápidos (alguns segundos a alguns minutos sendo o que experimentei com mais frequência).

Às vezes, existem outros testes que são executados automaticamente no check-in ou uma vez à noite, por exemplo. Estes tendem a demorar mais tempo. Algo entre 30 minutos e algumas horas. Normalmente, chamamos de "testes funcionais" ou "testes de regressão" ou mesmo "testes lentos".

Das minhas experiências:

Um teste de unidade é um teste ou conjunto de testes que abrange um módulo específico. Na programação OO, um módulo geralmente é uma função ou classe. Os testes de unidade são agrupados em conjuntos de testes. Os testes de unidade são os blocos de construção dos testes de regressão e fumaça e, em alguns casos, podem servir como documentação para o comportamento pretendido de um sistema ou partes de um sistema.

Teste de regressão é o ato de executar a maioria ou todos os testes de unidade em um módulo alterado. Isso garante que o módulo alterado continue funcionando conforme o esperado após as alterações.

O teste de fumaça é o ato de executar um número (pequeno - você deseja que o teste de fumaça seja bastante rápido) de testes de unidade em módulos inalterados para garantir que uma alteração em um módulo não tenha efeitos colaterais indesejados em outros módulos. O foco geralmente está nas classes que têm associações com a classe alterada, bem como nos módulos que fornecem as principais funcionalidades do aplicativo.

Dependendo do seu ambiente de construção, qualquer um destes pode ser automatizado ou executado pelo desenvolvedor. Um conjunto de alterações confirmado deve ser pequeno o suficiente para que os testes de regressão não demorem muito tempo e o teste de fumaça foi projetado para ser bastante rápido. Normalmente, eu executo pelo menos testes de regressão e fumaça no código antes mesmo de fazer o check-in para não quebrar a compilação. Normalmente, vi o sistema de compilação ser projetado para executar e relatar o status de todos os casos de teste regularmente, variando de diária a semanal, dependendo da taxa de desenvolvimento e do tempo para compilar e executar os testes.

Se você executá-lo na base de código antes do check-in, é um teste de regressão.

se você apenas testar o bit que mudou, é um teste de unidade.

Quando você adiciona um teste para um bug no nível do sistema e o corrige, é um teste de regressão.

Ele testa se você está regredindo: voltando atrás.

Vale a pena fazer testes de regressão porque os bugs tendem a se agrupar em determinados lugares, e alguns erros se repetem.

Se você pode suportar a disciplina de ter testes no nível do sistema, a adição de testes de regressão vale a pena. Qualquer subsistema quebradiço acaba envolvido em testes de regressão.

História real.

Testes de unidade automatizados é o que eu sempre os chamei.

Não tenho certeza se existe um termo oficial ou não, mas eu os chamaria de testes automatizados. Concordo com você: a palavra unidade que está lá não é precisa.

O termo "testes automatizados" abrange o espectro de testes de unidade, testes de regressão, testes de integração, testes de aceitação, etc.

Costumamos chamá-los de testes de fumaça, sanidade ou prioridade 1. Os testes de prioridade 2 acontecem após um check-in e, em seguida, os testes de prioridade 3 são executados nas compilações agendadas. Nosso conjunto final de testes, prioridade 4, acontece quando temos uma compilação especial que ocorre durante um fim de semana - pois eles levam tanto tempo para serem executados.