Chargement automatique de la graine de données de db/graines.rb avec le râteau

Je suis en utilisant rails-rspec gem et j'ai plusieurs spécifications (modèles, contrôleurs, etc). Quand je lance:

bundle exec rake

tout est testé. Cependant, je voudrais améliorer mes specs par semis de certaines données (db/graines.rb) juste après la base de données est créée (dans l'environnement de test).

Mon spec/spec_helper.rb.rb fichier ressemble à ceci:

ENV["RAILS_ENV"] ||= 'test'

require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'capybara/rspec'
require 'ruby-debug'

# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/and its subdirectories.
Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

RSpec.configure do |config|
  config.mock_with :rspec

  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = false

  config.include SpecHelper

  config.before(:suite) do
    DatabaseCleaner.strategy = :truncation
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.start
    stub_xmpp_rest_client!  
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

  config.include Devise::TestHelpers, :type => :controller
  config.include Delorean
  config.after(:each) { back_to_the_present }
  config.include Factory::Syntax::Methods
  config.extend ControllerMacros, :type => :controller
end

Ce que pourrait faire le meilleur moyen de le faire? Merci.

InformationsquelleAutor Zag zag.. | 2011-12-05

29

Selon la façon dont votre graine de fichier est configuré, vous pourriez être en mesure de charger/exécuter à partir d'une before(:each) ou before(:all) bloc:
```
load Rails.root + "db/seeds.rb" 
```
InformationsquelleAutor Taryn East
44

Mauvaise idée! Jamais, jamais, graines de votre base de données de test. Utiliser des usines à créer, au sein de chaque test, seulement les documents nécessaires pour que le test à passer. L'amorçage de la base de données de test permettra de faire vos tests de moins en moins fiable, car vous aurez à faire beaucoup d'hypothèses qui ne sont pas explicitement mentionné dans vos tests.
- Je suis d'accord avec vous, @marnen-laibow-koser. Cependant, comme vous le savez, les semences but est d'être le moins de données qui sont indispensables pour l'application. C'est pourquoi je pense qu'il est utile pour les scénarios de test.
- Non, non, non. Vos tests ne devraient pas avoir besoin de tous vos semences enregistrements. Il suffit de créer les enregistrements de chaque test doit. Par exemple, si vous êtes semis pays, aucun test n'aura plus besoin que d'un ou deux pays. Si votre test seulement les besoins de la France et de l'Espagne, n'est pas de la graine de l'Italie. Encore une fois, il y a jamais une bonne raison de semences de l'essai DB. Ne jamais le faire.
- En d'autres termes, graines de données pour la production réelle de l'application, et non pas pour vos tests.
- Vous êtes la plupart de bienvenue! Si vous pensez que je suis de droite, soins de upvote? 🙂
- Je pense que vous avez déclenché la "fabrique vs luminaire" débat ici. Sachez que @MarnenLaibow-Koser est exprimer l'un des deux actuellement pris en charge Opinions sur ce sujet 🙂
- Ce n'est pas exactement ce débat. Même les inconditionnels de luminaire fans de ne pas charger tous les accessoires pour chaque test.
- Je ne comprends pas l'attitude de ne pas inclure les graines de données. C'est une partie de l'application, tout autant que le code, c'est juste qu'il arrive à être stockées dans la base de données. Il faut simplement être présent pour tous les tests.
- Vous êtes tout à fait tort. Graines de données ne fait pas partie de la demande, pas plus que les autres données. La Production de semences de données devrait être présent pour aucun tests, notamment parce que ce serait aller bien au-delà de la configuration minimale nécessaire pour les tests à exécuter. Ce doit être présent est minime conçu de données (généralement pas plus de 10 dossiers) -- juste assez pour que le test à passer. Si vous renseignez la base de données pour les tests, vous vous retrouvez avec fragile, incertaine, étroitement associée des tests, tout ce que les tests ne sont pas censés l'être. Ce n'est pas une "attitude", c'est un fait démontrable.
- Aussi, votre demande de semences de données est "la partie de la demande" n'est pas pertinent ici. Surtout quand nous sommes tests unitaires, nous n'avons pas besoin ou souhaitez inclure l'ensemble de l'application afin de tester une partie de lui -- c'est pourquoi nous concevons des systèmes faiblement couplés.
- Certains d'entre nous sont des systèmes de construction couplé avec... la réalité, où le couplage doit être assez forte. Surtout, je ne voudrais pas, ou utiliser des semences de données dans mes tests, mais parfois vous faites, et dans ces cas, il est agréable de trouver un moyen élégant de le faire. Mon application, par exemple, a une constante valeurs stockées dans la base de données plutôt que Ruby CONSTANTES, et ils doivent être impliqués dans les tests.
- Assez étonnamment, la plupart d'entre nous face à la réalité. Vous n'avez pas le monopole. 🙂 L'Application des constantes sont probablement mieux stockées dans des fichiers de configuration que dans la DB (donc je vois votre scénario comme un peu d'un problème de conception), mais même si vous devez les stocker dans la base de données, je voudrais encore vous conseillons de ne pas l'ensemencement pour vos tests. La seule exception serait si vous faites des tests que les constantes sont définies correctement par votre production script d'installation ou de quoi que ce soit.
- Aussi, j'ai le sentiment que vous ne pouvez pas savoir le génie logiciel sens du mot "couplage" et pourquoi c'est généralement une mauvaise chose.
- Ma raison pour la baisse de vote est simple: il n'est pas une réponse. Il s'agit d'un commentaire. Il devrait peut-être ont été ajoutées à la question d'Opinion.
- Lorsque l'OP demande comment faire quelque chose d'inopportun, je pense en disant: "vous ne voulez pas le faire, et voici pourquoi; en outre, voici une meilleure façon d'accomplir la même chose" est une réponse valable, n'est-ce pas?
- Je suis d'accord avec votre argument sur le principe, mais ne jamais dire jamais. Il y a des situations où le fait d'avoir le nécessaire de graines de données en place est encore la meilleure façon de le faire. Une autre solution pourrait être d'utiliser des luminaires, mais il n'y a pas de sens de rechargement pour chaque cas de test si ils sont vraiment statique de la graine de données.
- C'est un "plus jamais". Il n'est pas possible de tests de situation où les données semences de sens. Si vous êtes en désaccord, veuillez fournir un exemple concret. À mon humble avis c'est toujours mieux pour générer vos graines enregistrements dans chaque cas de test afin que vos hypothèses sont explicites.
- Nous avons une db qui était en effet mal conçus. Il y a beaucoup de contraintes de clé étrangère sur des données qui est supposé être dans la db (ne peut pas créer un Widget avant WidgetType est peuplé, avec de l'Utilisateur et UserType et UserRole et UserRoleType et...) de L'application est immense avec un beaucoup de intrlocking, données nécessaires même juste de se lever sur le sol. Il y a aussi zéro tests pour le couvrir. Je ne suis pas sur de revoir l'application pour modifier la conception jusqu'à ce que j'ai des tests à la place... donc j'ai besoin d'un moyen de semences seulement le minimum requis de données pour chaque test. C'est la "réalité" dont on parle.
- J'ai besoin d'un moyen de semences seulement le minimum requis de données pour chaque test."—Exactement! Bien sûr, vous le faites! Et la meilleure façon de le faire est généralement avec les usines. Ils sont faits sur mesure pour exactement le genre de profondément associée objets que vous parlez de. Juste avoir votre Widget factory appelez votre WidgetType usine (association :widget_type). Alors vous n'avez pas besoin de semences de données: il vous suffit de faire Factory :widget dans le test lui-même, et qu'il invoquera Factory :widget_type et ainsi de suite derrière les coulisses. Simple. Pas de graines nécessaire. Je le fais tout le temps.
- des centaines d'usines... ou un seul db/graines de fichier c'est une question de savourer de loin un énorme blob de code qui n'est pas nécessaire sauf pour l'installation de la base de données. Nous avons ensuite seulement ont des usines pour les données en haut de la base et ont beaucoup moins d'usines à parcourir. Étant donné que nous ne fait pas de utilisation db/graines pour les semences de nos bases de données... je pense que c'est une solution simple à mettre tous les trucs nécessaires en un seul endroit. - hors de la voie. Simple, pas d'usines nécessaire 😉
- Alors je pense que vous le faites mal, probablement parce que vous ne comprenez pas vraiment les inconvénients de votre approche. Avec un db/graines de fichier, vous balayez les graines sous le tapis, et donc de faire des hypothèses implicites. Dans les tests, c'est mauvais. Chaque essai doit faire ses hypothèses explicites—et la façon de le faire est de commencer à partir de zéro dans tous les tests, et la création de que les enregistrements que vous avez besoin de test. L'usine définitions seront généralement pas plus complexe que les graines de fichier, et peut-être moins complexe. (De plus, à vous de vous faire remarquer que vous êtes abuser db/graines.)
- L'idée que vous avez usines de données "sur le dessus de la base des" points à ce qui est erroné avec votre approche. Vous êtes en train de penser de la base et les données d'usine comme deux choses différentes, ce qui conduit à une mauvaise tests (je travaille avec un système comme ça, maintenant,—il est difficile d'écrire des tests fiables). Cela signifie également que vos tests ne sont pas minimes. Au lieu de cela, reconnaissons que c'est juste toutes les données, et que vous devez faire de votre hypothèses explicites dans chaque essai, de sorte que vous savez exactement quelles sont les données que vous effectuez le test.
- Je n'ai en effet de vouloir cacher ce genre de choses sous les couvertures pour le moment. Je suis en train de faire sur le but n'est pas par hasard. Le but étant que j'ai mis toutes ces hypothèses dans un seul endroit, donc je sais hypothèses qui sous-tendent l'architecture existante. Dans le test, je vais mettre le réel comportement préférée. Quand je taquine les sous-tendent le comportement que j'ai voulez vraiment de se faire - je vais le sortir de la semence de base dans les tests, graduellement réduire à rien l'ensemble des hypothèses sous-jacentes que ne devrait pas être là en premier lieu, mais sont dus à une mauvaise conception de l'architecture. ok?
- le faire sur le but n'est pas par hasard." Alors je pense que vous faites une erreur colossale. "Le but que j'ai mis toutes ces hypothèses dans un seul endroit, donc je sais hypothèses qui sous-tendent l'architecture existante." Noble idée, mais il ne semble jamais à travailler de cette façon dans la pratique. Plutôt, en déplaçant les hypothèses plus loin, le code de test, tu fais ça difficile, pas le plus facile, de savoir quelles sont les hypothèses sous-tendent ce. "Dans le test, je vais mettre le réel comportement préférée." Oui, le faire—et de mettre toutes les hypothèses juste là avec elle.
- Je taquine les sous-tendent le comportement que je veux vraiment arriver - je vais le sortir de la semence de base dans les tests" vous ne savez pas quel test dépend de l'hypothèse, et vous ne serez pas en mesure de se débarrasser des hypothèses sous-jacentes facilement. La raison de ce que vous faites est mauvaise, c'est qu'elle occulte le lien entre les tests et les hypothèses particulières. À moins que votre cas est extrêmement inhabituel, pas chaque test dépend de chaque hypothèse. Par conséquent, tous les test les besoins de l'ensemble des données semences. Il suffit de charger les quelques dossiers que d'un test en particulier des besoins. Beaucoup plus claire.
- Jusqu'à présent presque tous les test t s'appuyer sur tous les "graines" de données qui je parle. À l'exception de quelques extrêmement rares modèles qui ne reposent pas sur d'avoir une partie de mettre en place dans la base de données (par exemple une partie de la "<X>_type" modèles qui devrait vraiment être une table de hachage de données en constante quelque part plutôt que d'une table dans la db). Tous les autres modèle exige d'une partie... et chaque partie exige au moins 15 tables rempli avec des données initiales (oui vraiment, aucune hyperbole ici), juste pour lancer le test. Vous n'êtes pas vraiment arriver "c'est un affreux tas de code qui a besoin de reconcevoir" très bien encore 😉
- ici, presque tous les test ne s'appuient sur l'ensemble de la "graine" de données qui je parle.'—Alors que les est un cas différent. Mais je me demande, parce que plus tard vous dire: "pour Tout autre modèle exige d'une partie... et chaque partie exige au moins 15 tables rempli avec des données initiales". Cette situation n'est pas rare. J'ai une situation similaire. Définir des usines associées, et ne Factory :party tant que de besoin. C'est plus de l'intention de révéler et explicite que vos graines. 'Vous n'êtes pas vraiment arriver "c'est un affreux tas de code qui a besoin de reconcevoir" très bien encore'—je l'obtenir. Ce n'est pas la question. 🙂
- Vous savez, Factory :party { group }, Factory :group { group_type; country }, Factory :country { continent; iso_code 'XX' } et ainsi de suite.
- Si c'était aussi simple que cela, ce serait ok... mais il ne l'est pas. Votre exemple est presque linéaire - 1 modèle se rapporte à 1 autre modèle et ainsi de suite... notre situation est complexe et le digraphe. Une partie s'appuie sur une quinzaine de tables de base de données (pas quinze instances d'objets). et non seulement les modèles qui sont des associations de cette partie spécifique de l'objet de la logique est circulaire - mettre en place un parti qui peut se connecter, vous avez besoin de créer une société, un rôle et une "role_user" - de mettre en place une entreprise, vous avez besoin de l'autre partie et d'un rôle et d'un "role_company", role_types party_types pays de l'état de genre...
- et tous ont de clé étrangère refs et "not null" colonnes dans le db qui signifie que vous simplement ne pouvez pas configurer de quelques-uns d'entre eux comme des objets réels et certains se moque de...
- exemple est presque linéaire - 1 modèle se rapporte à 1 autre modèle et ainsi de suite... notre situation est complexe et le digraphe." Le mien, vraiment. J'essayais de rester concis. "Une partie s'appuie sur une quinzaine de tables de base de données...pour configurer une partie qui peut se connecter, vous avez besoin de créer une société, un rôle et une "role_user"'—rien de cela n'est aucun problème pour le complexe de l'usine de la configuration que j'ai utilisé avec succès dans les cas de ce genre. De circularité, il suffit d'utiliser FactoryGirl rappels. " et tous ont de clé étrangère refs et "not null" colonnes dans la base de données'—ainsi qu'ils le devraient. Encore une fois, pas un obstacle pour les usines.
- simplement ne pouvez pas configurer de quelques-uns d'entre eux comme des objets réels et certains se moque"—En théorie, bien sûr, vous pourriez—vous pouvez toujours vous moquer. Mais, normalement, vous ne devriez pas. Je commence à penser que vous simplement ne savent pas comment obtenir les la plupart hors des usines (indice: ils sont beaucoup à la création de graphiques complexes), et donc, vous avez fait un très mauvais test de décision en conséquence.
- Bien sûr, c'est possible pour écrire des usines de cette façon, et même se moque. J'ai essayé d'expliquer mon raisonnement pour expliquer pourquoi j'ai choisi de ne pas le faire. Clairement je n'ai pas réussi à l'expliquer de façon convaincante. Cependant - je maintiens mon choix comme étant le plus approprié pour moi, et je ne suis pas heureux avec la façon dont vous avez choisi pour exprimer votre désaccord. En tant que tel j'ai eu assez de cette discussion, merci.
- laissez-nous continuer cette discussion dans le chat
- Peut-être que moi aussi, j'ai pas réussi à être aussi convaincant que j'aimerais être. Le truc, c'est que, même s'il est très tentant d'amorcer le test de DB, je crois fermement que c'est généralement pas la bonne chose à faire et de la manière que vous avez expliqué votre cas, je pense que votre cas est probablement l'un des nombreux cas dans lesquels c'est la mauvaise chose. Si le semis est séduisante par son apparente simplicité, il signifie qu'il est impossible de dire ce test dépend de données, ce qui n'est pas une bonne chose. C'est pourquoi Rails luminaires sont mauvais, et c'est aussi pourquoi, à mon humble avis test DB semis est mauvais.
- L'enjeu ici est que les gens ont des idées différentes sur ce que la "graine" de données est. Certaines personnes pensent que des graines comme une sorte de fixations permanentes, et je suis avec MLK sur l'utilisation, pour les raisons indiquées. Mais certaines données peuvent relèvent du système de la base de données est une partie, et doit être présent pour l'ensemble du système fonctionne correctement. Un exemple pourrait être une table de rôles dans un rôle de système d'authentification basé sur. "Graines" pourrait un bon endroit pour se charger de telles données.
- Peut-être que je suis terriblement dense, mais je ne pense pas que c'est la racine du problème. Je pense que tu viens de décrire le même type de données semences de 2 façons différentes. Bien sûr, la graine de données toujours correctement appartient au système de production. C'est le genre de pas à la question des méthodes de test.
- En général, je préfère garder la semence de données à un minimum, mais pour certaines choses c'est justifié. Mes critères sont les suivants: 1. Il est fondamental pour l'application. 2. Il ne change pas (sauf si global des hypothèses de changement). 3. Vous avez souvent besoin de la présence de la graine de données pour tester d'autres modèles de relations. Pour l'un, je préfère tester sans base de données de persistance lorsqu'il n'est pas nécessaire, mais pour tester les requêtes relationnelles vous ne pouvez pas simplement se moquer de qui. Si il y a un tableau statique de faits que mes relations se joignent contre, je préfère l'avoir en dormance dans la base de données que d'avoir à le recharger pour chaque exemple de test à l'aide d'une usine.
- il y a un tableau statique de faits que mes relations se joignent contre, je préfère l'avoir en dormance dans la base de données que d'avoir à le recharger pour chaque exemple de test à l'aide d'une usine."—Je ne pense pas que l'une de ces alternatives est une bonne idée. Au lieu de cela, il suffit de créer le 1 ou 2 articles dont vous avez besoin pour chaque exemple de test, ce qui ne sera pas l'ensemble du tableau. L'avoir en dormance dans la DB signifie que vous avez un tas de données inutiles confusion de vos tests. Mettre une autre manière, rien ne doit être "endormi" dans un test; tout devrait être là parce qu'il doit être, il test.
- Je suis généralement d'accord, et je préfère la même chose que vous: il permet de voir explicitement ce qui se passe dans un test. Ce n'est pas idéal pour 100% des situations; il devient une question de pragmatisme, c'est plus "pure" de l'isolement. Le rechargement de quelque chose que toujours reste exactement la même dans tous exemple est stupide: à la fois dans la base de données & mentale en contexte. Quand je dit que je "dois le recharger pour chaque test", oui cela signifie que le 1 ou 2 dossiers, mais c'est distrayant de bruit pour une axiome qui ne change jamais.
- Pour cela, je suis en désaccord avec votre "jamais, jamais, jamais de réponse. Il n'est pas question de faire "beaucoup" d'hypothèses, mais seulement les quelques très de celles de base.
- quelque chose qui reste toujours exactement la même dans tous les cas est stupide"—d'Accord. Ce n'est pas du tout de quoi je parle. Il semble que votre approche de test crée trop de dossiers. Si vous avez une table de pays, un test peut seulement besoin d'Italie, un autre peut-être seulement besoin de la France, et un troisième peut-être besoin Ruritania, qui n'existe pas réellement, mais est pratique pour les tests! • "c'est distrayant de bruit pour une axiome qui ne change jamais"—Si elle ne change jamais, pourquoi avez-vous besoin d'autant de tests? Pour les différents cas, non? Ne pas les différents cas de besoin différents dossiers mis en place?
- pas à propos de faire "beaucoup" d'hypothèses, mais seulement les quelques très de celles de base"—Chaque enregistrement dans votre essai DB avant un test commence est une hypothèse (ou plus d'un). Vous devez généralement faire le moins d'hypothèses possibles dans le test, ce qui signifie que vous devez généralement faire que quelques enregistrements que possible. Habituellement, la meilleure façon de le faire est d'adapter les peu vous avez besoin pour chaque test.
- en désaccord avec votre "jamais, jamais, jamais" réponse"—Pourquoi? Toute situation de test impliquant des semences de données peuvent être logiquement réduit à celui qui n'en a pas. Chaque fois que j'ai vu que la réduction faite, elle a permis en plus de tests. J'ai essayé assez difficile de penser à une situation dans laquelle les essais de semences pourrait être bénéfique, et je ne peux vraiment pas; otoh, que, j'ai vu leur causer des problèmes à de nombreuses reprises. Si j'ai raison sur ce point, alors la conclusion est très claire.
- Wow. Grâce Marnen. Vous avez juste changé ma vie.
- Heureux de vous aider. Oserais-je vous demander comment? 🙂
- et si j'ai changé votre vie pour le mieux, n'hésitez pas à upvote!)
- Ses l'ensemble de l'implicite/explicite argument. Je n'avais jamais entendu parler avant, et je suis vendue par votre raisonnement. J'ai été, admittently sceptique au début, mais il a le sens parfait. Merci pour le partage. Aussi, je upboated vous. Aussi agréable violon. 😉
- Cool. Ouais, il est tentant de prendre des raccourcis dans les tests, mais c'est généralement ce n'est pas une bonne idée.
- Ce n'est pas que c'était un raccourci. Mon application fonctionne sur beaucoup de randomnization par une IA. Et j'ai besoin de construire un accompagnement suite de tests qui est aussi une IA qui apprend de l'autre. Mes tests sont simples, mais vous m'a fait réaliser que mes tests doivent couvrir chaque situation individuelle par les usines plutôt que d'évaluer la couverture randomnization. Cependant, je vais finir par enlever le capuchon de ma suite avec quelque chose de "similaire" n'est pas aussi général que c'est maintenant ( aux termes de votre argumentation. )
- Cela devrait probablement devenir une Pile séparée de Débordement de la question à ce point, mais... deux points: 1. Pourquoi vos tests être une IA? Il me semble que vous devez générer votre tests manuellement de sorte que vous pouvez être absolument certain de ce que vous faites des tests. 2. J'utilise des données aléatoires dans mes tests. Je pense que c'est orthogonale à la question de la graine de données et les usines.
- Je pense que ce que je ne comprends pas à propos de ce qui est: pourquoi statique de données de configuration stockées dans la base de données seront traitées de manière différente à la statique des informations de configuration stockées dans les fichiers yaml? Je n'ai pas entendu dire que les fichiers yaml ne doit être remplie avec des données suffisantes pour passer des tests, et il semble conceptuellement la même chose pour moi. Personnellement, j'ai besoin de la config info dans la base de données parce que j'ai besoin d'y accéder à partir de SQL.
- Vous apportez une question intéressante. J'ai l'habitude de ne pas utiliser les fichiers de configuration Yaml pour tout, mais les choses les plus simples (par exemple, DB infos de connexion) dans mon environnement de test, donc ce n'est pas quelque chose que j'ai pu croiser beaucoup. Mais je pense que je dirais qu'ici, le principe est le même: votre installation d'essai doit toujours être aussi faible que possible, et je voudrais donc recommander à l'encontre de grosse application des fichiers de configuration dans votre environnement de test. Comme avec la DB, mon inclination serait de laisser chaque cas de test définir uniquement les config des valeurs qui sont nécessaires pour que ça passe.
- Il;s une discussion intéressante. Pour moi la difficulté d'anticiper les effets secondaires dans un système complexe qui signifie que je voudrais un système de test aussi semblable que possible à la production de configuration pour l'application de la systémique, de tests, de nouvelles informations/éléments de configuration peuvent causer des logiques différents chemins à suivre. Pour les tests unitaires, peut-être une autre approche pourrait être approprié, mais comme j'ai besoin de cette configuration complète pour les tests d'intégration, je serais pas mis en place d'un environnement limité pour les tests unitaires.
- moi la difficulté d'anticiper les effets secondaires dans un système complexe qui signifie que je voudrais un système de test aussi semblable que possible à la production de configuration" Oui, mais seulement pour vos tests d'intégration. • "comme j'ai besoin de cette configuration complète pour les tests d'intégration, je ne serait pas définir un environnement de test unitaire." Mais c'est exactement ce que vous devez faire. Une unité de test ne devrait test unité. Si elle s'appuie sur des effets secondaires de configuration d'autres données, alors vous êtes le test de votre configuration; ce n'est plus une unité de test. Ce type de test a un endroit, mais pas dans les tests unitaires.
- Pourriez-vous modifier votre réponse afin d'être plus clair que vous êtes seul à s'opposer à cela dans le contexte de tests unitaires, pas de tests d'intégration?
- Non, parce que je suis aussi s'y opposer dans le cadre de tests d'intégration. Si vous chargez le plein de graines ou de config de données, vous ne devez le faire dans un ensemble limité de tests d'intégration dont l'objectif spécifique est de test de données. Vous ne devez pas le faire dans tous les tests d'intégration.
- Nous allons simplement pas d'accord alors, parce que je veux de système/tests d'intégration est un environnement absolument aussi proche que possible de la production de configuration du système. Je pense que votre approche peut être gérable pour les systèmes simples, mais crée un haut niveau de gestion des coûts, le niveau de complexité et de risque pour rien de plus.
- Vous savez, vous avez m'a fait penser à ce sujet, et je pense que j'ai peut-être modifier mes réponses, à vous au sujet de la config de données. Plus j'y pense, plus je pense qu'il y a est une différence fondamentale entre les fichiers Yaml/variables d'environnement d'une part et DB dossiers sur l'autre. La différence est peut-être que le fichier Yaml/env y sont mis avant que l'application n'est jamais déployé, de sorte que vous pouvez les traiter comme des hypothèses comme l'OS. DB graines, otoh, que, sont généralement dans le domaine de l'application, de sorte que vos tests ne faut pas courir avec eux. Peut-être?
- C'est peut-être une situation où il est utile de considérer "ce qui est arrivé en premier, l'application ou la base de données?" comme une expérience de pensée. Si l'application a été ajouté sur le dessus d'une base de données existante – la base de données ayant une existence en cours de validité sans l'application, plutôt que d'être là pour le soutenir, est – ce que le changement de l'examen? Données est quelque chose qui est là pour soutenir l'application, ou de données est considéré comme indépendant?
- Je ne pense pas que c'est terriblement pertinente. Je suis en essais à l'état actuel du système, et non pas son histoire.
InformationsquelleAutor Marnen Laibow-Koser
12

J'ai mis en place mon rake spec tâche pour charger automatiquement db/graines.rb, donc je dépend que de la configuration de la base de données pour un premier run. Ajoutez ceci à votre Rakefile:
```
task :spec     => "db:seed"
task :cucumber => "db:seed"
```
Puis, sur d'autres pistes je viens de l'appeler rspec spec directement pour sauter à la graine de l'étape et éviter le rechargement. J'ai configurer la base de données nettoyant pour ignorer la graine tables comme ceci:
```
RSpec.configure do |config|

  config.add_setting(:seed_tables)
  config.seed_tables = %w(countries roles product_types)

  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation, except: config.seed_tables)
  end

  config.around(:each) do |example|
    if example.metadata[:no_transactions]
      DatabaseCleaner.strategy = :truncation, {except: config.seed_tables}
    else
      DatabaseCleaner.strategy = :transaction
    end
    DatabaseCleaner.start
    example.run
    DatabaseCleaner.clean
  end
end
```
Pour les scénarios qui ont besoin de données validées, je peux ajouter:
```
describe "commit for real", use_transactions: false do
  # ...
end
```
Ce sera tronquée, de tout ce qui est après l'exemple fonctionne, sauf les graines de tables. Il est supposé que vous n'avez jamais écrire quoi que ce soit à la graine tables! Cela est généralement une hypothèse sûre, depuis la graine de données est généralement statiques.

Pour tous les autres scénarios, je compte sur les transactions à l'annulation des enregistrements insérés. La base de données est retourné à l'état d'origine, avec les données de la graine tables intacte. Il est sûr d'écrire pour la postérité tables ici si vous en avez besoin.

Pour reconstruire la graine tables, il vous suffit de lancer rake spec de nouveau.
- Merci cela a fonctionné pour moi!
- Nous sommes à la gestion d'une suite de test criblés avec des luminaires et des hypothèses, et en le déplaçant à plus d'usine mis en place. Le déménagement de nos graines de données sur les appareils et dans ce jeu de stratégie est une partie essentielle de celle - merci pour votre réponse, elle a permis de SÉCHER certains de nos mise en œuvre
- Il a travaillé pour moi (Rails 4 et beaucoup de choses à charger sur les semences). Merci. Vous êtes mes héros d'aujourd'hui.
InformationsquelleAutor Andrew Vit
7

Pour charger les graines dans rspec vous devez l'ajouter après la base de données nettoyage de la confg.avant(:suite) dans
spec_helper.rb
```
config.before(:suite) do
  DatabaseCleaner.clean_with(:truncation)
  load "#{Rails.root}/db/seeds.rb" 
end
```
InformationsquelleAutor Ahmad Hussain

Dans Rails 4.2.0 et RSpec 3.x, c'est comment mon rails_helper.rb semble.

RSpec.configure do |config|
  config.include FactoryGirl::Syntax::Methods
  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = false

  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each, :js => true) do
    DatabaseCleaner.strategy = :truncation
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

  config.before(:all) do
    Rails.application.load_seed # loading seeds
  end
end

InformationsquelleAutor Andrew Lobban

0
1. copie de la graine.rb fichier dans le fichier config/initializers dossier.Ainsi la graine.rb fichier sera exécuté sur le serveur de démarrage.
2. Exécutez la commande ci-dessous pour remplir le test de db avec la semence.rb données
  
  RAILS_ENV=test rake db:graine
InformationsquelleAutor vidur punj
-1

Je pense que nous devrions utiliser
```
config.before(:each) do
  Rails.application.load_seed # loading seeds
end
```
comme avant(:all) exécute le bloc une fois tous les exemples sont exécutés.

Donc, si nous utilisons before :all, la graine de données seront effacées.

InformationsquelleAutor Yang

Vous devez vous connecter pour publier un commentaire.