Лучше ли указывать все параметры данного в одной строке, или каждый параметр в отдельной строке? - PullRequest
Новая
       18

Лучше ли указывать все параметры данного в одной строке, или каждый параметр в отдельной строке?

1 голос
/ 08 июля 2010

Лучше ли указывать все параметры заданного значения в одной строке или каждый параметр в отдельной строке? то есть что лучше?

отдельно и для каждого параметра 

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

или все паромтеры для конкретного заданного в одной строке 

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

Похоже (и я надеюсь, что я ошибаюсь) иметь следующие последствия для того, как вы пишете свои привязки, а также начинает влиять на то, как вы пишете свой класс, чего не должно быть! то есть первый вариант (отдельный И для каждого параметра) связывание легче написать, если у вашего класса есть общедоступные свойства, которые устанавливаются один за другим после создания объекта ... 

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;
}

тогда как второй вариант (все в одной строке) проще иметь объект с конструктором, который принимает все параметры в качестве аргументов конструктора. 

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);
}

Мне кажется, что я что-то упускаю, потому что реализация specflow не должна влиять на код, который я пишу, и я беспокоюсь, что # 1 выше будет стимулировать чрезмерно сохраняющие состояние объекты. Я функциональный наркоман без состояния.

Любые указатели будут наиболее полезны.

txs заранее,

ура, Алан

Ответы [ 2 ]

0 голосов
/ 09 июля 2010

Не отвечая на полный вопрос, но только на эту часть:

Мне кажется, что я что-то упускаю, потому что реализация specflow не должна влиять на код, который я пишу, и ябеспокоит то, что № 1 выше будет поощрять чрезмерно наполненные состояниями объекты.Я - функциональный наркоман без состояния.

Я не думаю, что проблема заключается в том, что формулировка сценариев влияет на код привязки.Вот почему он является обязательным (другие фреймворки называют его «клеем», который подчеркивает это еще больше).Вы можете иметь хорошо продуманную бизнес-логику или логику автоматизации, которую вам придется использовать с помощью связующего кода.

Функциональный / не имеющий состояния: для привязок шага нет встроенной опции связывания (метод связывания возвращает то, что получает следующий), но вы можете создать некий класс контекста шага (используя контекстное внедрение: http://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ContextInjection/), где вы можете достичь аналогичного дизайна.

0 голосов
/ 09 июля 2010

Я пишу тесты в стиле BDD и использую первый метод, потому что ...

  1. Методы настройки (также для проверки) могут повторно использоваться в связанных тестах.
  2. Любые неудачные тесты будут выделять точный метод, который не пройден, включая настройку.
  3. Устраняет дублирование для связанных тестов и, следовательно, будет проще в обслуживании.
...