Как справиться с угловыми / краевыми / ошибочными случаями со спокойствием

Question

Мне нравится идея сосредоточиться на бизнес-сценариях.Тем не менее, как разработчик, я также хочу, чтобы случаи ошибок имели автоматические нерегрессионные тесты.

Например, в функции электронной коммерции может быть сценарий

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

Но как насчет сценариев, когда его кредитная карта недействительна или его банк отклонил транзакцию.Эти сценарии тесно связаны с деталями реализации.

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

Не могли бы вы помочь мне понять, как мне следует подходить к тестированию этих сценариев?Спасибо!

Answer 1

Я думаю, что ваш вопрос связан с BDD / Gherkin, а не с Serenity.BDD абсолютно не , а ограничивает критерии приемлемости путями счастливого дня - я бы даже сказал, что это анти-паттерн.Если бизнес заинтересован в отрицательном пути (и часто они есть), это должно быть критерием приемлемости.Например:

Scenario: James has insufficient funds on his account Given James has a $1000 limit on his credit card And he has already spent $900 When he attempts to purchase a meal costing $150 Then the transaction should be refused