Cucumber vs Plain test code

Choose a tool by the tests you need to maintain and the evidence your team needs from failures. This page makes no speed, market-share or salary claims. The recommendations are practical judgments based on the capabilities described in the linked official documentation.

At a glance

The same testing problem, side by side

Consider a coupon that should be rejected after expiry. In Cucumber, express the scenario in business terms: the coupon has expired, the customer applies it, the basket keeps its undiscounted amount and explains the rejection. A step definition then calls the API or UI library and asserts that outcome. Avoid turning every click into a separate sentence.

In direct test code, name the test “expired coupon leaves total unchanged,” create the same state, perform the same action and assert the same result. Domain helpers can keep setup readable without a text-to-code mapping layer. Neither approach supplies the expiry rule: the team still needs an agreed clock and boundary example.

Where Cucumber is the better choice

Choose Cucumber when product, development and testing colleagues actively discuss and maintain concrete examples together, and executable scenarios help preserve that agreement. Use a small domain vocabulary and keep UI mechanics in implementation code.

For a refund policy with several time boundaries and eligibility rules, an Examples table can become a useful discussion artifact. It loses value if only automation engineers read it or update it after the behavior is already built.

Where Plain test code is the better choice

Choose direct tests when the audience is primarily engineers and the extra feature-file and step-mapping layer does not improve shared understanding. Clear test names and domain helpers can express acceptance intent without Gherkin.

A low-level JSON serializer or parser usually benefits from focused code assertions rather than business prose for each internal branch. Keep customer-facing examples in the appropriate layer, and avoid reusing one enormous helper merely to reduce line count.

A useful pilot

Take one reproducible ShopLite defect and write the expected behavior in plain language first. Decide whether a feature file improves the conversation, then implement the smallest appropriate check. This page contains no executed Cucumber suite and makes no claim that an illustrative scenario was automated.

How to decide

1. Ask who will read and change the examples before deciding to add a feature-file layer.
2. Try one disputed business rule in a collaborative discussion and capture the agreed boundary cases.
3. Implement a small example, then observe how another person diagnoses a deliberately failing assertion and adds a new case.
4. Keep Cucumber if the shared language continues to earn its maintenance cost; keep collaborative BDD habits even if you use direct tests.

How to explain the choice in an interview

Describe your project’s constraints, the alternatives you considered and the evidence behind your choice. Separate features you checked in documentation from workflows you personally ran. A maintainable test that reveals a useful failure is a stronger example than a claim that one tool always wins.