2010-11-19 27 views
0

Voici un exemple easyb scénario à partir du site easyb:Est-il possible de séparer Groovy d'easyb des définitions de scénarios anglaises simples?

before "start selenium", { 
given "selenium is up and running", { 
    selenium = new DefaultSelenium("localhost", 
    4444, "*firefox", "http://acme.racing.net/greport") 
    selenium.start() 
} 
} 

scenario "a valid person has been entered", { 

when "filling out the person form with a first and last name", { 
    selenium.open("http://acme.racing.net/greport/personracereport.html") 
    selenium.type("fname", "Britney") 
    selenium.type("lname", "Smith") 
} 

and "the submit link has been clicked", { 
    selenium.click("submit") 
} 

then "the report should have a list of races for that person", { 
    selenium.waitForPageToLoad("5000") 
    values = ["Mclean 1/2 Marathon", "Reston 5K", "Herndon 10K", "Leesburg 10K"] 
    for(i in 0..<values.size()){ 
    selenium.getText("//table//tr[${(i+3)}]/td").shouldBeEqualTo values[i] 
    } 
} 
} 

after "stop selenium" , { 
then "selenium should be shutdown", { 
    selenium.stop() 
} 
} 

Est-il possible de séparer le Groovy de l'anglais, de présenter quelque chose comme ceci:

scenario "a valid person has been entered" 
    given "the website is running" 
    when "filling out the person form with a first and last name" 
    and "the submit link has been clicked" 
    then "the report should have a list of races for that person" 

De cette façon, mon PHB a gagné » t obtenir tout confus par les accolades et Groovy.

Répondre

1

Probablement pas avec un effort justifiable. Néanmoins, vous pouvez facilement définir les fermetures de code en externe. Les parties « lisibles par l'homme » doit ressembler à ceci:

scenario "a valid person has been entered", { 
    when "filling out the person form with a first and last name", 
     fillOutPersonForm 
    and "the submit link has been clicked", 
     clickSubmitLink 
    then "the report should have a list of races for that person", 
     checkRacesList 
} 

Assurez-vous que les noms de fermeture sont descriptives et autodocumenté. En fait, je les trouve plus facile à lire que les descriptions écrites entièrement ...

Les définitions de fermeture ont été définies comme:

def fillOutPersonForm = { 
    selenium.open("http://acme.racing.net/greport/personracereport.html") 
    selenium.type("fname", "Britney") 
    selenium.type("lname", "Smith") 
} 
+0

pensé que cela pourrait descendre à cela. Au moins, vous pouvez réutiliser une bonne partie du code entre différents scénarios. Est-il plus «groovier» d'utiliser des fermetures plutôt que des méthodes ici? Et quel est le but de la description entièrement écrite si les noms descriptifs de fermeture/méthode sont plus lisibles ?! – Armand

+0

Vous ne pouvez pas utiliser de méthodes ici car les instances de fermeture sont passées en arguments aux méthodes EasyB. Cela ne peut pas (vraiment) être fait avec des méthodes, et c'est la différence la plus importante entre les deux. - Quant aux descriptions textuelles, leurs instructions environnantes peuvent être exécutées sans corps de code. De plus, les non-programmeurs peuvent ne pas avoir le sentiment d'écrire des noms expressifs de fermeture/méthodes. – robbbert

1

En fait, je crois que ce qui est déjà une caractéristique de l'ANT easyb via l'intégration. Découvrez http://www.easyb.org/running.html, dans la section "Impression d'histoire".

1

En tant qu'extension de SJG'sanswer, voici un extrait de code pour ce faire par programme.

L'easyb documentation at http://www.easyb.org/running.html décrit uniquement comment créer la vue de texte 'Story' à partir de la ligne de commande. Il est une tâche simple de le faire avec le code Groovy ...

import org.easyb.BehaviorRunner 

def params=["C:/temp/teststory.story", "-txtstory", "C:/temp/testoutput.html"] as String[] 
BehaviorRunner.main(params) 

Vous pouvez utiliser une approche similaire pour les rapports HTML et les rapports XML à l'aide -html ou -xml comme le 2ème paramètre.

Je ne suis toujours pas sûr des paramètres requis pour que seuls les rapports soient créés sans exécuter les tests. Cela devrait être possible, voir issue 165 fixed Il serait bien d'ajouter ceci comme la dernière partie d'une histoire afin que la documentation 'utilisateur' soit toujours créée, l'extrait ci-dessus provoque l'exécution des tests et ne peut donc pas être inclus dans la même fichier d'histoire sinon il entrerait dans une boucle récursive.

+0

merci pour la réponse détaillée. Si je comprends bien, cela permet l'affichage du texte du scénario, mais ne permettrait pas de le modifier sans voir le code; Est-ce exact? – Armand

+0

@Alison, oui il s'agit d'une transformation à sens unique du texte de scénario + scénario vers du texte de scénario. Si vous avez utilisé Robbbert's [réponse] (http://stackoverflow.com/questions/4224168/is-it-possible-to-separate-easybs-groovy-from-plain-english-scenario-definitions/4226086#4226086) ci-dessus et diviser le code de test technique en fermetures, puis le texte du scénario principal resterait lisible par les non-développeurs. – Chris