Why Cucumber is Rubbish for End-to-End Scenarios (and why End-to-End Scenarios are Rubbish too)

Why Cucumber is Rubbish for End-to-End Scenarios (and why End-to-End Scenarios are Rubbish too)

Often, people ask me what they should use for end-to-end scenarios. Those long scenarios that go right through the application from the start to the finish. One of the things I often say is, nothing, if you can avoid it.?

Why do I think this?

First let’s get to Cucumber.?

Cucumber is not designed for long, end-to-end scenarios. Cucumber is not an automation tool. Its sweet spot is for business rules and examples of business rules, and the majority of your executable specifications should be short, focused, and concise. It’s Given-When-Then notation becomes brittle and fragile when applied on long journeys. Plus, these scenarios take ages to write and when you have scenarios that are ten to twenty steps long, they are also very poor communication and documentation tools. They’ve got really nothing going for them.

Now let’s look at end-to-end scenarios in general.

End-to-end scenarios are a terrible drain on your time and a drain on your motivation. To be honest they are a drain on everything.?

It can take days or weeks to write a single end-to-end scenario for a large system. In that time imagine the number of focused business rules that could be written and automated (if your system is designed for that).?

Rather than trying to write huge end-to-end scenarios that test everything. It is much more efficient to focus on getting your system to a state where your business rules can be tested in isolation and where you can do a sequence of operations very quickly to verify each state of the system. That is way, way more effective.

Sure, it takes more work initially. It takes more thought, it takes more design, and it takes more upfront collaboration to get the system in a state where you can do that. But once you reach that state, it makes is so much easier to write high quality tests and scenarios that give you good feedback.??

It may seem counter intuitive but believe me, it does pay off in the long run.?

Have a great day, folks.

hamed Fakoori

Software Engineer

2 年

Trade-off is between speed and defect localization on the one hand and trustworthiness on the other. The solution to get rid of end-to-end testing and isolation-related problems could be to replace them with contract testing.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了