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

50

Sou um programador em crescimento que finalmente está colocando em prática o teste de unidade para uma biblioteca que estou armazenando no GitHub.

Ocorreu-me que eu poderia incluir os conjuntos de testes no repositório, mas, ao olhar para outros projetos, a inclusão de testes parece um sucesso ou um fracasso.

Isso é considerado má forma? A ideia é que os usuários estejam interessados apenas no código de trabalho e que, de qualquer maneira, testem em sua própria estrutura?

version-control unit-testing

— parisminton
fonte

13

Por que não? Os testes devem vir junto com o projeto ou são quase inúteis.

61

O fato de alguns projetos não incluírem testes de unidade em seu repositório é mais provável devido à inexistência desses testes em primeiro lugar.

— Prasopes

4

Eles são construídos separadamente, mas, caso contrário, os testes u são fortemente acoplados ao código. Para garantir consistência, deve haver algum tipo de gerenciamento de dependência. Seja colocando-os no mesmo "link" controlado por repositório, sub-repositório ou versão principal para testar o repositório, etc.

— MaR

2

A @stoupa está definitivamente certa: seria ótimo assumir o melhor, que há um maravilhoso cache de testes escondido em algum lugar, mas no mundo real, os programadores são preguiçosos.

— Cascabel

2

Observe que eu consideraria uma boa idéia desabilitar a compilação da classe de teste em seu script de construção.

— user606723

119

Você definitivamente deve colocar seus testes no repositório. Na minha opinião, os testes fazem parte do código e podem ajudar imensamente outras pessoas a entendê-lo (se bem escrito). Além disso, eles podem ajudar outras pessoas ao alterar ou contribuir com 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 o código de produção e teste em pastas diferentes. A pergunta "este arquivo faz parte da produção ou do código de teste" nunca deve surgir.

Pessoalmente, não escrevo testes de unidade para bibliotecas usadas em meu próprio código. Eu espero que eles estejam funcionando (pelo menos quando eu uso uma versão de lançamento, embora os bugs obviamente possam aparecer). Ele obtém alguma cobertura de teste nos testes de integração, mas isso não é suficiente.

— ftr
fonte

11

Como outro exemplo, dê uma olhada na pasta de teste do ipython . Se alguém faz check-out, não importa onde eles o colocam, os links relativos para os testes ainda são verdadeiros. Torna-se trivial testá-lo, o que é importante para determinar se sua nova máquina de desenvolvimento está configurada corretamente.

— Spencer Rathbun

Os testes não são apenas parte do código, mas também parte da documentação e, geralmente, parte da especificação. Os testes (que são executados e aprovados) são "documentação viva".

— Michael Easter

54

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

como alguém que baixa e constrói sua própria cópia desse código vai verificar se está funcionando da maneira que foi planejado? Os erros do compilador e da biblioteca são raros, e os erros de dados (principalmente aqueles que não impossibilitam a compilação do código-fonte) são ainda mais raros, mas eles definitivamente podem surgir, principalmente quando você não pode ditar o ambiente de construção na medida em que um o empregador pode ditar quais ferramentas são usadas.
como você fará os testes de volta se algo acontecer com sua cópia local do código-fonte?
como um novo desenvolvedor verificará se suas alterações não quebram nada na base de código existente?

Resumindo, eu consideraria não incluir nenhum teste de unidade escrito no repositório de código fonte oficial.

— um CVn
fonte

7

Obviamente, você deve colocar testes de unidade no repositório, por vários motivos:

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

— BЈовић
fonte

6

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

Eu suspeitaria fortemente que a maioria dos projetos que não incluem testes no repositório simplesmente não possui nenhum.

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

— Jan Hudec
fonte

5

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

— anon
fonte

3

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

— seanfitzg
fonte