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
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
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 –