Pourquoi ne puis-je pas créer ma propre base de test pour mon projet django?

Question

Je suis en train de décider quels paquets de tests utiliser avec mon projet django, en particulier comment remplir les données avant d'exécuter les tests. Je l'ai regardé dans:

1. Fixtures: Beaucoup de gens semblent être contre cela car JSON modifie peut être difficile et difficile à maintenir.

2. Factory boy: Mon projet a beaucoup de hiérarchie, donc j'ai l'impression que créer un objet à partir d'un modèle vraiment bas dans la hiérarchie est vraiment lent.

L'idée que j'ai en tête est de créer une base de données avec laquelle je vais toujours faire des tests. Puisque je sais quelles sont les données, ne devrait-il pas fonctionner de la même manière avec les appareils sans les tracas de JSON? Puisque je n'ai pas vu cette idée à travers mes recherches, je suppose que c'est une mauvaise idée. Pourquoi est-ce une mauvaise idée cependant?

Answer 1

Avez-vous réellement testé avec un garçon d'usine? Avec une base de données sqlite en mémoire, il est très rapide, d'après mon expérience, et très pratique avec les hiérarchies. Votre idée de base de données est plus ou moins la même que fixtures - vous pouvez utiliser la base de données pour créer des fixations JSON en exécutant la commande dumpdata et conserver vos données de test dans la base de données plutôt que dans les fichiers JSON.

Quelques raisons de préférer garçon d'usine sur une base de données de test:

• Les données sont générées là dans le test, il est donc immédiatement évident ce qui se passe et quels champs sont pertinents pour le test.

• Les données sont fournies avec le code de test, sans fichiers supplémentaires ou vidages de base de données à gérer.

• boy Factory est très bon avec les hiérarchies (« Je veux une instance de cette instance avec tous les champs de la valeur par défaut, sauf celui-ci champ six étapes dans la hiérarchie » - instance = InstanceFactory.build(series__study__patient__archive__project__algorithm_type='foo'))

• Parfois, une l'objet n'a pas du tout besoin d'être sauvegardé dans la base de données pour faire tester ses méthodes, dans ce cas le .build() de l'usine est très rapide. Au lieu de choisir des cas de bordure intéressants pour le test en cours, vous serez tenté de réutiliser simplement ce que vous avez déjà dans la base de données et de ne pas trouver de bogues. Peut-être que les différentes valeurs dont vous avez besoin de tester ne peuvent pas exister dans la base de données en même temps en raison de contraintes d'unicité.

Il y en a probablement plus, mais j'ai besoin de dormir.