Travailler sur une nouvelle application 3.2.9 avec RSPEC et Capybara.
J'ai ce qui suit dans le gemfile: p> et les suivants dans SPEC / SPEC_HELTER .rb: p> et dans spécifications / demandes / asdf_spec.rb: p> Ce test échoue: P> Failure/Error: visit asdfs_path
NoMethodError:
undefined method `visit' for #<RSpec::Core::ExampleGroup::Nested_1::Nested_2::Nested_1:0x007fa7b68961a0>
# ./spec/requests/asdfs_spec.rb:19:in `block (4 levels) in <top (required)>'
3 Réponses :
Le problème est à Capybara Gem lui-même. p>
gem 'capybara', '1.1.2' code> résout ce problème (version 2.0.x échoue) p>
Oui, c'était une question de version 2.x. Mais allez, la réponse n'est pas de dégrader. :)
C'était donc une modification de la version 2 de Capybara. J'ai trouvé ceci: p>
http://alindeman.github.com/2012/11/11/RSPEC-Rails-and-CapyBara-2.0-Qu-YOU-Need-Anko.html P>
qui explique: p>
Lors de la mise à niveau vers Capybara 2.0, Capybara ne sera pas disponible par Par défaut em> strong> dans les spécifications de demande RSPEC. Au lieu de cela, un nouveau type de spécification - le Feature Spec - a été créée pour une utilisation avec Capybara. P>
Pour passer à Capybara 2.0, vous devez faire quelques choses: p>
- Mettez à niveau RSPec-rails à 2.12.0 ou plus LI>
- Déplacez tous les tests qui utilisent Capybara à partir de spécifications / demandes à spécifications / fonctionnalités. Capybara Les tests utilisent la méthode de visite et affirment généralement contre la page. LI> ul> blockQuote>
Dans l'intervalle avant de déplacer vos tests de fonctionnalité sur Spécifications / fonctionnalités b> de SPEC / DEMANDES B>, vous pouvez faire passer votre suite en passant à nouveau en les marquant avec Type :: fonctionnalité code>.
Capybara 1.1.2 a également fourni certains matchers assez utiles dans les spécifications de demande (par exemple.
Quelques informations supplémentaires pour que quiconque a le même problème avec la mise à niveau Capybara vers Ceci est pas < / forte> recommandé mais il existe un moyen de garder vos spécifications à fonctionner telles quelles: p> Les DOCS indiquent que si vous allez ce itinéraire, vous prenez en charge le comportement prévu et vous prenez un risque. P> et définitivement ne pas cela comme une raison pour ne pas passer à J'espère que cela aide toute personne confondue par les nouveaux changements. p> p> 2.x code>. Découvrez Rspec-rails Docs sous le Mise à niveau vers la section Capybara 2 . < P> Fondamentalement, afin d'utiliser le Capybara DSL (page & Visite), vous devez déplacer vos spécifications existantes dans le répertoire
SPEC / Fonctionnalités CODE>. Vous ne pouvez donc utiliser que
page et visiter code> dans des tests d'acceptation. Pas plus de page et de visite dans les spécifications de contrôleur et de demande. Seul le test de rack DSL
(obtenir | post | Met | Supprimer | Delete / réponse.Body) Code> est autorisé dans le contrôleur et demande des spécifications. P>
Capybara 2.x Code>. Les spécifications de fonctionnalités sont faciles à utiliser et sont faciles à lire.
Caractéristique code> est juste un alias pour
décrire code>,
est un alias pour
avant code>,
scénario code > Pour
il code> et
donné code> pour
laisse code>. P>
Utilisez-vous Capybara 2.0?
Oui! Mon Google-Search-fu était faible.