Мы используем SpecFlow для функциональных тестов, которые предполагают заменить ручное тестирование, когда человек читает сгенерированную электронную почту и подтверждает, что все разделы соответствуют спецификации. Проблема заключается в том, что сценарий Контуры стали расти, чтобы иметь слишком много параметровКак адресовать сценарии сценария SpecFlow с слишком большим количеством параметров?
Scenario Outline: generate and send confirmation email
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',...
Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',..
Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',...
....
Примеры:
| EmbeddedItinerary | Param1_1| Param1_2| Param1_3| Param2_1| Param2_2| Param2_3| Param3_1| Param3_2| Param3_3|...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
Но число столбцов в примерах стало бы неуправляемым. Я хочу иметь многострочные примеры (но по другой причине в Multiple Multi-Line Examples in SpecFlow Feature File).
Опция, которую я вижу, заключается в том, чтобы хранить все ExpectedResults во встроенном файле ресурсов xml или json, а функции SpecFlow довольно малы, например.
Scenario Outline: generate and send confirmation email with correct email address for flight section
Given I have stored embedded resource '<EmbeddedItinerary>'
When Generate confirmation email
Then sections should be as specified in '<ExpectedResultsFile>'
Examples:
| EmbeddedItinerary | ExpectedResultsFile
| Itinerary_1 | ExpectedResults1 |
| Itinerary_2 | ExpectedResults2 |
...
Это хорошая идея?
Может ли кто-нибудь предложить лучший способ (более стиль SpecFlow)? Я забочусь о том, чтобы переносить ожидаемые данные в отдельные файлы. Я теряю видимость, что является одним из преимуществ функций SpecFlow.
Обновление: при написании этого вопроса я нашел коммерческий продукт ($ AUD 255 на одного пользователя) Specflow + Excel http://www.specflow.org/plus/excel/getting-started/, который может удовлетворить мое требование по поддержанию большого количества столбцов.
Является ли это зрелым/надежным продуктом? Должен ли я использовать его вместо собственного анализа файлов ожидаемых результатов в проприетарном формате?
Спасибо, Андреас, один из моих коллег хочет сделать то же самое. Я обеспокоен тем, что фактический бизнес-сценарий - отправить электронное письмо со всеми разделами и убедиться, что все разделы верны. Ваш подход, чтобы разделить его на отдельные сценарии для каждого отдельного раздела, больше похож на модульное тестирование, которое мы делаем в любом случае (но без SpecFlow). Я ошибаюсь? –
Это зависит от вашего определения Unit для UnitTest.Обычно это класс, так что вы тестируете поведение одного класса без зависимостей. Если в автоматическом тесте задействовано больше, чем вы, вы начинаете называть это интеграционным тестом. Поскольку вы генерируете текст и отправляете eMails, я предполагаю, что у вас здесь более одного класса. Это означает, что у вас есть интеграционный тест. –
Как решить, какие значения должны быть протестированы в одном и том же тесте, зависит от вашего кода. Если вы всегда получаете одинаковое содержимое раздела, независимо от того, что вы проверяете в первую очередь, это не имеет значения для результата, если вы проверяете их в одном сценарии или в нескольких. Но если, например, section2 зависит от того, что вы сначала проверяете section1, тогда вам нужно проверить их все в одном сценарии, потому что section1 - это более новый доступ, если вы их разделяете. –