Est-il préférable de spécifier tous les paramètres d'un donné dans une ligne, ou chaque paramètre sur une ligne séparée?

Question

Vaut-il mieux spécifier tous les paramètres d'une donnée dans une ligne, ou chaque paramètre sur une ligne séparée? c'est-à-dire quel est le meilleur?

séparé Et pour chaque paramètre

Scenario: some random scenario 
Given a menu with a menu width of 19 
And quit text of "quit" 
And Fruit options of 
    |Text| 
    |some text| 
    When ... 
    Then ... 

ou tous les paremters pour la spécifique donnée sur une ligne

Scenario: Some scenario 
Given a menu with quit text of "quit" and menu width of 19 and Fruit options of 
    |Text| 
    |Some text| 
    When ... 
Then ... 

Cela semble (et j'espère que je me trompe) à avoir les implications suivantes pour la façon dont vous écrivez vos liaisons, ainsi que commence à influencer la façon dont vous écrivez votre classe, ce qui ne devrait pas! à-dire première option (séparée et pour chaque paramètre) la liaison est plus facile d'écrire si votre classe a des propriétés publiques qui sont définies une par une après l'objet est créé ...

private Menu _menu; 
[Given(@"a menu of fruit options")] 
public void GivenAMenuOfFruitOptions(Table table) 
{ 
    string[] fruitOptions = table.GetColumn("Fruit"); 
    _menu = new Menu(fruitOptions,null); 
} 

[Given(@"a menu width of (.*)")] 
public void GivenAMenuWidthOf(string width) 
{ 
    _menu.Width = int.Parse(width); 
} 

[Given(@"a Quite text of ""(.*)""")] 
public void GivenAMenuWidthOf(string quitText) 
{ 
    _menu.QuitText = quitText; 
} 

alors que la deuxième (sur un seul line) il est plus facile d'avoir un objet avec un constructeur qui prend tous les paramètres comme arguments constructeur.

private Menu _menu; 
[Given(@"a menu with quit text of ""(.*)"" and menu width of (\d+) and Fruit options of ")] 
public void GivenAMenuOfFruitOptions(string quitText, int width, Table table) 
{ 
    string[] fruitOptions = table.GetColumn("Fruit"); 
    _menu = new Menu(fruitOptions,width, quitText); 
} 

Je me sens comme si je me manque quelque chose, parce que la mise en œuvre de specflow ne devrait pas influencer le code que je vous écris, et je suis inquiet que # 1 ci-dessus va encourager les objets trop stateful. Je suis un toxicomane apatride fonctionnel.

Les pointeurs vous seront très utiles.

TXS à l'avance,

acclamations, Alan

Answer 1

Je suis en train d'écrire des tests de style BDD et je suis en utilisant la première méthode parce que ...

1. Les méthodes de configuration (également pour la vérification) pourrait être réutilisé dans des tests connexes.
2. Tout test défectueux mettra en évidence la méthode exacte qui échoue, y compris la configuration.
3. Élimine la duplication pour les tests connexes et sera donc plus facile à maintenir. Ne pas répondre à la question complète

Answer 2

, mais juste cette partie:

Je me sens comme si je me manque quelque chose, parce que la mise en œuvre de specflow ne devrait pas influencer le code que je vous écris, et Je suis inquiet que # 1 ci-dessus va encourager les objets trop étatful. Je suis un toxicomane fonctionnel sans état.

Je ne pense pas que ce soit un problème que la formulation des scénarios influence le code de liaison. C'est pourquoi c'est contraignant (d'autres cadres l'appellent "colle" qui le souligne encore plus). Vous pouvez avoir une entreprise bien conçue ou une logique d'automatisation que vous devez conduire avec le code de liaison.Fonctionnel/sans état: Il n'y a pas d'option de chaînage intégrée pour les liaisons pas (la méthode de liaison renvoie quelque chose que le suivant reçoit), mais vous pouvez créer une sorte de classe de contexte d'étape (en utilisant l'injection de contexte: http://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ContextInjection/) vous pouvez réaliser un design similaire.