These are for a mix of end to end and integration tests.

I mostly do unit tests as a dev, so our tests are simple enough that they don’t benefit from more structure than being grouped by suite. E.g.:

• AuthService
  • valid user creds can login
  • invalid user creds cannot login
  • non-existent user gets same error as wrong creds
• UserSettingsService
  • can change language
  • cannot set empty password

These don’t have long flows, so there’s no benefit to documenting steps (they usually have one step).

My complaint about cucumber/gherkin isn’t with documenting steps, it’s with managing them in separate files. We have a Service.feature file that documents the scenario and the ServiceTest.java that documents the steps. I don’t see the point in having those be separate files, especially since the only people defining inputs and scenarios are the devs (dedicated QA in our case). We occasionally have our BE devs help write a few tests, and every time it’s a struggle for them to figure out where everything is. It just feels over-engineered.

In unit tests, we parameterize our tests just like with cucumber, we just do so in the code. E.g. in Python:

@parameterized.expand([(1, 2), (2, 4)])
def test_duplicate(num, exp):
    res = dup(num)
    assert res == exp

I would much prefer something like that in our end to end and integration tests.