Os testes de unidade devem ser armazenados no repositório?

Você definitivamente deve colocar seus testes no repositório. Os testes são, em minha opinião, parte do código e podem ajudar os outros imensamente a compreendê-lo (se bem escritos). Além disso, eles podem ajudar os outros quando mudarem ou contribuírem para a sua base de código. Bons testes podem dar a você a confiança de que suas alterações não quebram inadvertidamente nada.

O código de teste deve estar bem separado do código de produção. O Maven, por exemplo, consegue isso colocando a produção e o código de teste em pastas diferentes. A questão "é este arquivo parte da produção ou do código de teste" nunca deve surgir.

Pessoalmente, não escrevo testes de unidade para bibliotecas usadas no meu próprio código. Eu espero que eles estejam trabalhando (pelo menos quando eu uso uma versão de lançamento, apesar dos bugs obviamente poderem aparecer). Obtém alguma cobertura de teste em testes de integração, mas isso não é suficiente.

Se você não incluir os testes de unidade no código-fonte que fez check-in, então:

• como alguém que faz o download e cria sua própria cópia desse código vai verificar se está funcionando da maneira pretendida? Compiladores e bugs de biblioteca são raros, e erros de dados (particularmente aqueles que não tornam o código-fonte impossível de compilar) são ainda mais raros, mas eles definitivamente podem aparecer, particularmente quando você não pode ditar o código. construir ambiente na medida em que um empregador pode ditar quais ferramentas são usadas.
• como você recuperará os testes se algo acontecer com sua cópia local do código-fonte?
• como um novo desenvolvedor vai verificar se suas alterações não quebram nada na base de código existente?

Resumindo, eu consideraria não incluindo qualquer teste de unidade escrito no repositório oficial de código-fonte uma coisa muito ruim.

Claro que você deve colocar testes unitários no repositório, por várias razões:

• é fácil reverter para a versão anterior
• outras pessoas que trabalham no projeto também ganham acesso a testes de unidade
• algumas pessoas consideram os testes de unidade como parte da documentação (TDD e BDD)

Se houver alguma chance de executá-los em outro computador, inclua-os definitivamente. Eles devem ser criados separadamente, para que os usuários não precisem, e eles podem ter dependências extras, mas eles devem ser incluídos definitivamente.

Eu suspeito strongmente que a maioria dos projetos que não incluem testes no repositório simplesmente não possuem nenhum.

Pode haver um motivo para ter os testes como módulo separado, para que você possa executar facilmente novos testes em relação a códigos mais antigos. Seria útil para testes de biblioteca estável ou caixa preta com API via linha de comando; utilidade para linguagens compiladas onde os novos testes provavelmente não serão compilados com código antigo é limitado.

Absolutamente. Os pontos de bônus extras estão na capacidade de rastrear a versão X de um arquivo de origem com a versão Y de um teste. Em outras palavras, você precisa voltar a uma versão anterior e extrair os testes apropriados criados para essa versão (no caso de uma alteração na API ou algo assim).

Acabei de ler o "Desenvolvimento de aplicativos Brownfield no .Net" , e isso fornece alguns conselhos excelentes da estrutura de um aplicativo, incluindo controle de origem e onde / como / por que incluir testes de unidade (particularmente na área de Integração Contínua). Se você é um desenvolvedor de .Net, eu recomendo.