0

I like the idea of focusing on business scenarios. However, as a developper I also want error cases to have automated non-regression tests.

For example, in a e-commerce feature, there would be a scenario

James uses his credit card to pay
James should see that the purchase was successful

But what about scenarios where his credit card is invalid or his bank rejected the transaction. These scenarios are strongly linked to implementation details.

I don't see how I can handle automated testing of these scenarios within the Serenity philosophy. If I write scenarios, i will have to mention current implementation details. When reading literature around Serenity I feel like it's only meant to test the happy path because this is what business people care about. However in the real world error cases and more complex flows are important parts of the applications, and benefit from automated tests.

Could you please help me understand how I should approach testing those scenarios? Thanks!

lwouis
  • 21
  • 5

1 Answers1

1

I think your question is related to BDD/Gherkin, rather than Serenity. BDD absolutely does not limit acceptance criteria to happy day paths - I would even say that is an anti-pattern. If the business is interested in a negative path (and often they are), it should be an acceptance criteria. For example:

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

John Smart
  • 969
  • 1
  • 5
  • 5
  • On the serenity-js documentation, [tasks](http://serenity-js.org/design/screenplay-pattern.html#task) are supposed to be high level. I have trouble understanding how I can express in broad terms an error case which depends on implementation details. For instance, an input not meeting a regex. This would be an interaction. How would I differentiate the many things that can go wrong. Let's say James tries to pay, then the bank could reject payment for 10 reasons. How do I differentiate the 10 scenarios when the tasks are the same. Only the interactions/assertions would change – lwouis May 22 '18 at 17:49
  • For edge cases that really depend on implementation details, unit testing is probably the best place. Ask yourself if the business need to know about this edge case. Is it a business rule, or a technical constraint? If it is a business rule, it can usually be data driven, and you just describe the 10 scenarios in terms of what data goes in. – John Smart Jul 05 '18 at 12:36
  • Eg. ``` Scenario: James has reported his card stolen Given James has a $1000 limit on his credit card And he has reported his card stolen When he attempts to purchase a meal costing $150 Then the transaction should be refused ``` – John Smart Jul 05 '18 at 12:36