2010-12-14 64 views
2

Donc, je commence à construire une nouvelle application, ma première grande dans les rails depuis le passage de .net. Je veux vraiment BDD l'ensemble de l'application afin que j'ai concombre tout mis en place et prêt à partir.Bonne façon de tester des scénarios avec du concombre (rails 2.3.8)

J'ai écrit plus de quelques tests pour les choses simples (suppression, ajout, mise à jour) et ainsi de suite mais maintenant je suis coincé en essayant de comprendre comment tester ce scénario.

J'ai ces modèles Utilisateur, compte, plan chaque compte a un forfait, les forfaits sont facturables chaque mois (le jour même où le compte a été créé).

Je veux tester la sélection d'un plan, créer un compte, vérifier le processus de facturation (même maquette, sans PayPal à ce stade).

J'apprécierais l'aide avec ceci, juste pour souligner, je ne cherche pas le code complet, juste une explication de comment (dans le concept) iriez-vous et examiner ceci. De plus, le plan est évolutif et rétrograde, donc je veux le tester aussi.

Merci d'avance pour votre aide

Répondre

3

J'aime pratiquer en dehors-dans le développement, où l'on commence par l'écriture de tests d'acceptation, puis déposez-les dans des tests unitaires pour gérer la logique de domaine. Prenons la création d'un compte comme exemple.

Commencez par écrire une histoire de concombre pour la fonction désirée. Par exemple:

Feature: Create an account 
    In order to use the application 
    As a user 
    I want to create an account 

    Scenario: Create an account from home page 
    Given I am on the home page 
    When I follow "Sign up" 
    And I fill in "Username" with "bob" 
    And I fill in "Password" with "test123" 
    And I press "Create" 
    Then I should see "You have successfully signed up! You may now sign in." 

Quand nous courons nos fonctions de concombre à l'aide de la commande cucumber features, la première étape dans le scénario échouera car la page d'accueil n'existe pas encore. Pour le créer, nous pouvons le considérer comme une fonctionnalité distincte. Par conséquent, nous pourrions écrire une autre caractéristique de concombre comme:

Scenario: Visitor visits the home page 
    When I go to the home page 
    Then I should see "Welcome to the Website of Awesomeness" 

L'exécution de cette fonction, nous découvrons qu'il n'y a pas de chemin racine défini dans l'application Rails. Une fois le problème résolu, nous aurons besoin d'un contrôleur, d'une vue et du texte de la vue. Jusqu'à présent, nous avons seulement écrit des tests de concombre.

Une fois que toutes ces caractéristiques sont passées, nous nous rendons compte qu'un nom d'utilisateur devrait être requis. Nous pouvons écrire une étape de concombre pour tester ce cas:

Scenario: Username must be filled out 
    Given I am on the home page 
    When I follow "Sign up" 
    And I fill in "Password" with "test123" 
    And I press "Create" 
    Then I should see "Username cannot be blank." 

Pour mettre en œuvre cela, il faut ajouter une validation à notre modèle qui validera l'inclusion d'un nom d'utilisateur. Nous allons maintenant passer aux tests unitaires car nous modifions la logique du domaine. En règle générale, lorsque vous modifiez un modèle, vous devez le placer dans RSpec ou Test :: Unit et tester directement cette modification. Par exemple, en utilisant RSpec, nous ajouterions une spécification pour s'assurer que les noms d'utilisateur doivent être présents (et uniques, etc.). Une fois ce test passé, notre scénario devrait également commencer à passer.

Cela a été long, mais il devrait vous aider à commencer à pratiquer BDD d'une manière très réelle. Pour plus d'informations, voir le livre RSpec (qui contient une mine d'informations sur les pratiques externes utilisant Cucumber et RSpec): http://www.pragprog.com/titles/achbd/the-rspec-book

+0

J'ai tous ces tests, j'ai dit toutes les bases comme l'ouverture d'un compte validations et tout du reste sont déjà mis en œuvre.la question était spécifiquement pour les paiements et les plans et la facturation mensuelle. – KensoDev

+0

Commencez par vous assurer que la logique du domaine pour les plans et les paiements est élaborée dans votre suite de tests unitaires, puis travaillez à créer une suite de tests d'acceptation qui frappe les serveurs de test de votre fournisseur de paiement. Une bonne ressource pourrait être de feuilleter les exemples de scénarios de concombre que Chargify a publiés dans leurs documents et d'en tirer des idées: http://docs.chargify.com/api-migrations#api-migrations-json-create –