I had a similar issue when I first picked rspec up over a decade ago. At first I was drawn to the allure of an approach that would have the tests better match t

I had a similar issue when I first picked rspec up over a decade ago. At first I was drawn to the allure of an approach that would have the tests better match the intention of a customer (more general BDD, and not just rspec). You’d sit down with the customer and write down what they wanted to happen in natural prose, the tests would (almost) write themselves, and the opportunity for misalignment or miscommunication would vanish! Except it wasn’t natural prose. It ended up being ham-fisted attempts to write “as a user, when I…” style paragraphs that most closely matched whatever marchers already existed. Then there’s be nuance in the differences so you’d have to write specific assertions anyway. In the end it rarely felt like magic to me, and that I spent just as much time if not more writing and maintaining the test implementation as I’d always done. Just now with an extra layer of abstraction and misdirection. At some point I realised the value wasn’t in BDD, it was just the conversations it was forcing. Nobody outside our team cared if the tests were green if it didn’t actually give them the outcome they wanted. There was no pointing feeling like you’d won on a technicality. So I switched back to implementing tests the way that was quickest and easiest for us. And writing the other forms of documentation others needed, in the formats that were best for them.