I have used Cucumber in various projects, but haven't yet had the pleasure of seeing it all work out.

- No one wanted to "collaborate", or check a "documentation" based on the Cucumber code. Yes, it's code, it lives in an IDE, in git, and non-technical folks just generally don't deal with that world. No one in my projects ever even brought such an idea up. Non-technical folks looked at our Cucumber code as in "what tests do we have?" or "how do you guys work". Nothing in their domain.

- Why do we have programming languages and don't programm computers using natural language? You'll find out when you try BDD! You end up coding the complexities that natural language glosses over, you'll fight similar Cucumber statements trying to get some reusability and so on. In the end you wonder why you bother with the 1-2 extra layers of Cucumber anyway.

- At the same time, good test code is easily readable for semi-technical people. In testing it ends up with a lot of clicking and entering values in text fields in an application the business analyst will be familiar with. Whenever they are willing, they'll figure out Selenium code.

- Have you ever wished that you have some

  Scenario: Sunday isn't Friday
    Given today is Sunday
    When I ask whether it's Friday yet
    Then I should be told "Nope"
on top of, say, Boolean checkIfFriday() in your code? Truth is, a lot of testing code is click here, enter text there. Wrapped in the right function, organized in the right way (Page Object Model?) and it's all readable, maintainable and done in a reasonable time.

I would advise against BDD/Cucumber and to be convinced otherwise I'd have to see a well though-out and realistic working example.

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.