StoryQ BDD, Дано или Когда без тела

Я хотел бы сделать очень простой тест для конструктора моего класса,

[Test]
public void InitLensShadingPluginTest()
{
    _lensShadingStory.WithScenario("Init Lens Shading plug-in")
        .Given(InitLensShadingPlugin)
        .When(Nothing)
        .Then(PluginIsCreated)
        .Execute();
}

это может быть в Given или When it... Я думаю, что это должно быть в When(), но на самом деле это не имеет значения.

private void InitLensShadingPlugin()
{
    _plugin = new LSCPlugin(_imagesDatabaseProvider, n_iExternalToolImageViewerControl);
}

Поскольку тестируется Конструктор, мне нечего делать внутри оператора When(),

А в Then() я утверждаю о создании плагина.

private void PluginIsCreated()
{
    Assert.NotNull(_plugin);
}

мой вопрос касается StoryQ, так как я не хочу ничего делать внутри. Когда () я пытался использовать When(()=>{}), однако это не поддерживается storyQ, это означает, что мне нужно реализовать что-то вроде

private void Nothing()
{
}

и позвони When(Nothing)

есть ли лучшая практика?


c# bdd storyq
person Gilad    schedule 18.01.2018    source источник
comment
Почему вам необходимо написать этот тест как сценарий BDD? Потому что это не так. Лучшей практикой для BDD является наличие осмысленных сценариев, вытекающих из обсуждения с бизнесом.   -  person rad    schedule 18.01.2018
comment
@rad Я экспериментирую с тем, что я могу или не могу делать с StoryQ, я использую Nunit, однако мне всегда кажется странным, что вам нужно использовать две среды тестирования вместо одной.   -  person Gilad    schedule 21.01.2018
comment
в этом случае нет необходимости использовать эти 2 фреймворка, на самом деле я сомневаюсь, что этот сценарий является хорошим кандидатом для тестирования. Вы должны тестировать поведение, и обычно не рекомендуется помещать логику/поведение в конструктор. Письменные сценарии BDD отлично подходят для общения с бизнесом и создания универсального языка предметной области, совместно используемого с бизнесом. Если вы не в этом случае, просто используйте NUnit, лол. И для меня совершенно нормально иметь только когда и затем шаги, если сценарий не имеет предшествующего необходимого состояния. Если у вас нет шага «когда», возможно, это запах поведения, которое нужно тестировать.   -  person rad    schedule 22.01.2018
comment
@rad BDD фактически начался на уровне класса; описание примеров поведения класса. JBehave (первый фреймворк) изначально задумывался как замена JUnit. Таким образом, у нас есть примеры (не тесты) поведения по всему стеку; многомасштабный, как говорит Дэн Норт. Я обычно начинаю с одного класса как на уровне модуля, так и на уровне системы, а затем распределяю обязанности по мере их возникновения, так что этот подход подходит для обоих. См. также мой комментарий о сценариях без указания времени; очень часто используется для инициализации github.com/lunivore/kgol/ blob/solution/src/scenarios/resources/   -  person Lunivore    schedule 23.01.2018
comment
@lunivore Я думаю, что есть много способов читать и делать BDD, мне очень нравится эволюция с тех пор, как Дэн Норт написал свою первую статью об этом, чтобы сделать ее больше об общении с бизнесом (спецификация на примере ...). И я согласен с тем, что ваш сценарий имеет ценность, но его можно легко написать так, что когда вы начинаете игру, сетка должна быть пустой ... и я думаю, я также могу отстаивать то, что исходный TDD - это намерение ... спасибо, что поделились :)   -  person rad    schedule 23.01.2018
comment
Исследование на примере сначала. Затем уточнение на примере. Затем протестируйте на собственном примере как хороший побочный продукт. Наличие разговоров важнее, чем запись разговоров, важнее, чем автоматизация разговоров. Пожалуйста!   -  person Lunivore    schedule 24.01.2018

Ответы (1)


arrow_upward
1
arrow_downward

Странно, что StoryQ не поддерживает пропущенные шаги; ваш сценарий на самом деле довольно типичен для других примеров, которые я использовал для запуска приложений, игр и т. д. вверх:

Given the chess program is running
Then the pieces should be in the starting positions

например. Таким образом, ваше желание использовать условие, за которым следует результат, совершенно оправдано.

Глядя на API StoryQ, не похоже, что он поддерживает эти пустые шаги. Вы всегда можете создать свой собственный метод и вызывать внутри него оба шага Given и When, возвращая операцию из When:

    .GivenIStartedWith(InitLensShadingPlugin)
    .Then(PluginIsCreated)

Если это кажется слишком неуклюжим, я бы сделал, как вы предложили, и переместил Given в When, вместо этого инициализировав Given пустым методом с более значимым именем:

    Given(NothingIsInitializedYet)
    .When(InitLensShadingPlugin)
    .Then(PluginIsCreated)

Любой из них решит вашу проблему.

Однако, если все, что вы тестируете, — это класс, а не все приложение, использование StoryQ, вероятно, будет излишним. Среды BDD с естественным языком, такие как StoryQ, Cucumber, JBehave и т. д., предназначены для того, чтобы помочь бизнесу и командам разработчиков сотрудничать в изучении требований. Они несут значительные накладные расходы на настройку и обслуживание, поэтому, если аудитория ваших сценариев/примеров на уровне класса является технической, может быть более простой способ.

Для примеров поведения на уровне класса я бы просто использовал простой инструмент модульного тестирования, такой как NUnit или MSpec. Мне нравится использовать NUnit и оставлять в комментариях свое «Дано/Когда/Тогда»:

// Given I initialized the lens shading plugin on startup
_plugin = new LSCPlugin(_imagesDatabaseProvider, n_iExternalToolImageViewerControl);    

// Then the plugin should have been created
Assert.NotNull(_plugin);

Шаги на уровне класса не используются повторно так же, как в полносистемных сценариях, потому что классы имеют гораздо меньшие, более инкапсулированные обязанности; и разработчикам выгодно читать код, а не скрывать его в определениях шагов.

Ваши комментарии Given/When/Then здесь могут по-прежнему повторять сценарии на более высоком уровне, если класс напрямую управляет функциональностью, которую видит пользователь.

Обычно для полносистемных сценариев мы выводим шаги из разговоров с «тремя амигос»:

  • представитель бизнеса (PO, SME, тот, у кого есть проблема, которую нужно решить)
  • тестер (который замечает сценарии, которые мы могли бы пропустить)
  • разработчик (кто собирается решить проблему).

Там может быть пара разработчиков. Дизайнеры пользовательского интерфейса могут принять участие, если захотят. Мэтт Винн говорит, что это "3 amigos, где 3 - любое число от 3 до 7". Лучшее время для разговоров — прямо перед тем, как разработчики возьмутся за работу, чтобы начать кодировать ее.

Однако, если вы работаете самостоятельно, будь то игрушка или реальное приложение, вам могут быть полезны просто воображаемые разговоры. Я использую пикси по имени Чертополох.

person Lunivore    schedule 18.01.2018
comment
Привет, спасибо за отличный ответ. Я использую Nunit, конечно. И я использую шаблон BDD для тестирования системного теста, однако мне было интересно узнать о более простом варианте использования. Спасибо - person Gilad; 19.01.2018