É uma boa prática ter um banco de dados pré-preenchido para desenvolvimento?

5

Atualmente, estou trabalhando em um projeto que usa apenas seu banco de dados para armazenamento de dados. Isso significa que não há gatilhos ou procedimentos armazenados, apenas tabelas e dados para colocar nele. Neste cenário, estou construindo o aplicativo usando o Spring 4. O contêiner Spring permite que você tenha perfis, que basicamente decidem quais beans serão carregados em seu projeto. Você pode garantir que um banco de dados embutido na memória ou um banco de dados oracle completo seja usado para armazenamento de dados, sem ter que alterar uma única coisa em seu código.

Isso obviamente está sendo usado para testes de unidade e integração. Não ter que confiar em um banco de dados é ótimo para seus testes. Eu queria saber se o mesmo não conta durante o desenvolvimento. Neste projeto específico, não tenho certeza de como será meu modelo de dados final e, como não sinto vontade de escrever SQL repetidamente para mover colunas, prefiro usar algum tipo de banco de dados na memória. Claro que um com dados de desenvolvimento pré-preenchidos, então eu posso imitar um sistema que foi preenchido com todos os tipos de dados, e eu posso facilmente adicionar mais para pequenos testes durante o desenvolvimento.

Esta é uma prática recomendada ou inerentemente ruim de alguma forma?

    
por Kristof 03.12.2015 / 13:11
fonte

3 respostas

3

Por que não?

Pessoalmente, prefiro ter scripts que preencham um banco de dados vazio com novos dados para que eu possa saber exatamente o que está acontecendo eb) alterá-los facilmente.

Eu faço isso mesmo para os nossos grandes bancos de dados de produção, mantendo um script com os 'dados usuais' que eu teria de inserir manualmente - coisas como um ID de usuário predefinido para mim e configuração padronizada.

Isso é provavelmente mais útil no desenvolvimento do que na integração ou especialmente no controle de qualidade, que deve criar seu próprio banco de dados usando as ferramentas fornecidas para testar se as ferramentas ainda funcionam com novas versões.

    
por 03.12.2015 / 16:04
fonte
2

Esta é realmente uma boa ideia, e você deve fazer isso. Eu iria acima e além, com bancos de dados pré-configurados para escolher, assim como a capacidade de apontar para bancos de dados compartilhados para a equipe.

  • Você deseja redefinir seu banco de dados. Você pode precisar que ele esteja em algum estado conhecido, difícil de reproduzir, para acionar um bug em particular. Ser capaz de testar e corrigir esses tipos de bugs é uma grande ajuda.

  • Poder começar a trabalhar rapidamente é crucial. Esse é um tempo improdutivo no início de um projeto ou durante uma iteração se você precisar redefinir algo.

  • Ser capaz de alternar entre bancos de dados pode ser uma grande ajuda. E se o controle de qualidade relatar um bug, mas você não conseguir reproduzi-lo? Claro, você pode vê-lo no sistema de controle de qualidade, mas isso não ajuda você a percorrer o código. Ser capaz de reconfigurar seu ambiente de desenvolvimento para usar um banco de dados diferente com rapidez e facilidade pode ajudar a reduzir o ciclo de feedback.

  • Eu teria um conjunto de scripts para adicionar rapidamente dados específicos a um novo banco de dados para testar cenários específicos. Estes podem ser scripts SQL ou scripts de teste automatizados, como Selenium .

Ser capaz de configurar e usar um banco de dados de maneira rápida e arbitrária é uma ajuda tremenda para o desenvolvimento com muitas vantagens e apenas uma desvantagem que eu posso imaginar:

  • Torna fácil ter várias pessoas usando o mesmo banco de dados. Se vários desenvolvedores e testadores estão modificando os mesmos dados, eles podem realmente invalidar seus testes à medida que eles pisam nos dedos uns dos outros. Embora isso possa não ser um grande problema na produção, pode ser frustrante no desenvolvimento e no teste em que os dados podem precisar estar em um estado específico durante o teste e a depuração.
por 03.12.2015 / 17:04
fonte
1

Sim, esta é uma ótima ideia.

Para facilitar o desenvolvimento, é muito útil minimizar os passos entre "check out sources" e "system is running". Fornecer um banco de dados pré-preenchido ajuda com isso. Eu usei isso no passado e achei muito útil.

Existem diferentes maneiras de realizar isso:

  • um script SQL que é executado automaticamente (ou manualmente) - geralmente a solução mais simples
  • você pode escrever algum código que preencha o banco de dados usando as mesmas classes / estruturas que você usa na produção - permite reutilizar código e significa que as alterações de esquema se aplicam automaticamente ao banco de dados de teste
  • tem algum tipo de despejo de banco de dados que você carrega - menos flexível para alterar, mas útil se você quiser usar dados reais (é claro, tenha o cuidado de anonimizar / higienizar primeiro!)

Idealmente, a geração de dados de teste deve ser executada automaticamente durante a criação ou a inicialização do sistema.

Obviamente, crie salvaguardas para que tudo isso nunca seja executado em produção!

    
por 03.12.2015 / 16:45
fonte