Onde devo armazenar os dados de teste?

Eu tenho testes de unidade menores que usam pequenos trechos de conjuntos de dados reais. Eu também gostaria de testar meu programa em relação a conjuntos de dados completos por várias razões. O único problema é que um único conjunto de dados real é de aproximadamente 5 GB. Não encontrei números concretos para o que os repositórios Git podem armazenar, mas isso parece demais.

De acordo com este post dos programadores, devo manter todos os dados necessários para testar o projeto no repositório.

A solução que minha equipe adotou é que o projeto tenha um arquivo que contém um caminho para um sistema de arquivos conectado à rede que contém nossos dados de teste. O arquivo é Git ignorado.

Eu sinto que esta é uma solução imperfeita por duas razões. Quando o NAS não está funcionando, é lento ou está inoperante, não podemos executar um teste completo. A segunda razão é que, quando alguém clona um repositório pela primeira vez, os testes de unidade falham, então eles precisam descobrir como montar coisas com um determinado nome e a sintaxe usada para criar o arquivo do caminho de teste.

Então, minha pergunta é dupla. Quantos dados há demais para armazenar no controle de revisão?

Qual é a melhor maneira de lidar com grandes quantidades de dados de teste?

Como lidar com arquivos grandes em uma cadeia de construção

Eu gosto de usar uma ferramenta de construção que faz gerenciamento de dependências - como maven ou gradle. Os arquivos são armazenados em um repositório da Web e a ferramenta cuida do download e do cache automaticamente quando encontra a dependência. Também elimina a configuração extra (configuração do NAS) para pessoas que desejam executar o teste. E isso faz com que a atualização dos dados seja bastante simples (com versão).

O que é grande demais para colocar no controle de revisão

Há uma grande área cinza. E se você decidir que algo não pertence a um RCS, quais são suas alternativas? É uma decisão mais fácil se você limitar suas escolhas entre o RCS e um repositório binário (estilo maven).

Idealmente, você desejaria apenas as coisas do RCS que sejam humanamente editáveis, diferentes ou onde você deseja acompanhar o histórico. Qualquer coisa que seja o produto de uma compilação ou algum outro tipo de automação definitivamente não pertence a ela. Tamanho é uma restrição, mas não a principal - um arquivo de origem gigante (má prática) definitivamente pertence ao controle de origem. Um pequeno binário compilado não.

Esteja pronto para comprometer a conveniência do desenvolvedor.

Quando o NAS não está funcionando, é lento ou está inoperante, não podemos executar um teste completo.

Obviamente, isso só pode ser resolvido copiando os 5 GB do NAS para a unidade local. Mas não há necessidade de fazer isso manualmente.

A segunda razão é que, quando alguém clona um repositório pela primeira vez, os testes de unidade falham, então eles precisam descobrir como montar coisas com um determinado nome e a sintaxe usada para criar o arquivo do caminho de teste.

Você pode fornecer um script de shell simples que faça exatamente isso - monte o NAS com um determinado nome e copie os dados para sua unidade local quando ainda não estiver lá, ou quando o conjunto de dados no NAS for mais recente que o conjunto de dados local. Verifique se o script será executado automaticamente durante o estágio de inicialização dos seus testes de unidade.

Obviamente, quando não houver apenas um desses conjuntos de dados, mas várias dependências de arquivos externos fora do seu repositório de código-fonte, uma ferramenta como as mencionadas por @ptyx pode ser a melhor solução.

... quando alguém clona um repositório pela primeira vez, os testes de unidade falham, então eles precisam descobrir como montar coisas com um determinado nome e a sintaxe usada para criar o arquivo do caminho de teste.

Primeiro, apenas para ter uma terminologia consistente: esse tipo de teste (grandes dependências externas, dados reais) geralmente não é considerado um teste de unidade, mas um teste de integração ou sistema .

Em uma nota prática: acho uma boa prática manter os testes de unidade e integração separados , porque eles têm diferentes pontos fortes e fracos.

• separar os dois tipos de testes no código (convenção de nomenclatura, projeto separado, ...)
• fornecer uma maneira de executar apenas um dos dois conjuntos de testes
• execute apenas os testes de unidade durante compilações normais
• execute os testes de integração sob demanda e em um servidor de CI (integração contínua)

Dessa forma, as compilações locais são rápidas e confiáveis ​​(pouca / nenhuma dependência externa) e os testes de integração são tratados pelo robusto servidor de CI. Isso evita o problema que você descreve.

Sobre como manter os dados:

Uma boa opção é algum tipo de gerenciamento de artefato, como a resposta do ptyx 'descreve. Outra seria colocar os dados de teste em um repositório separado . Os dados não são liberados junto com a compilação principal, e ter um repositório separado evita forçar todos a buscar os dados de teste junto com o código-fonte. Em outras palavras, use um segundo repositório como seu gerenciamento de artefato :-).