16 October 2026, 07:31 PM
Hi all,
Been going back and forth on this with my team for a few weeks now and wanted to hear from people who have actually tried it.
We're a small team, four developers and one QA person, building a booking platform. Our tests are mostly unit tests plus a handful of API checks. The problem is that half our bugs aren't really "bugs" in the code sense. The feature works exactly as written, it just isn't what the product person meant. Classic misunderstanding stuff.
Someone suggested we try BDD. If you're wondering what is behaviour driven development in the first place, this glossary page explains it pretty simply: what is behaviour driven development. The short version is that you write the expected behaviour in plain language (Given / When / Then) before building anything, and the whole team agrees on it. Those scenarios then become automated tests.
What I like about the idea
The conversation part honestly sounds more useful than the tests. Sitting down with the product owner and writing "Given a user has an expired card, When they try to book, Then they see a payment error" forces everyone to think about edge cases before a line of code is written. That alone would probably have saved us a few rewrites last quarter.
What worries me
1. Time. We already feel stretched. Writing feature files AND step definitions feels like extra work on top of extra work.
2. Maintenance. I've read a few horror stories about step definition libraries turning into a mess once you have a few hundred scenarios.
3. Buy-in. If the product side doesn't actually read or help write the scenarios, it feels like we'd just be writing tests in a more awkward format.
What I'm thinking of trying
Not going all in. Just picking one feature, probably the booking and cancellation flow since that's where most of our arguments happen, and writing scenarios for it together with the product owner. If it reduces the back and forth, we expand. If not, we drop it without much lost.
So for those of you who have used BDD on a small team:
- Did it actually reduce misunderstandings, or did it become a test-writing chore?
- Which tool did you go with? We're mostly Python so I'm looking at Behave and pytest-bdd.
- Anything you wish you'd known before starting?
Would really appreciate any honest experiences, good or bad. Thanks!
Been going back and forth on this with my team for a few weeks now and wanted to hear from people who have actually tried it.
We're a small team, four developers and one QA person, building a booking platform. Our tests are mostly unit tests plus a handful of API checks. The problem is that half our bugs aren't really "bugs" in the code sense. The feature works exactly as written, it just isn't what the product person meant. Classic misunderstanding stuff.
Someone suggested we try BDD. If you're wondering what is behaviour driven development in the first place, this glossary page explains it pretty simply: what is behaviour driven development. The short version is that you write the expected behaviour in plain language (Given / When / Then) before building anything, and the whole team agrees on it. Those scenarios then become automated tests.
What I like about the idea
The conversation part honestly sounds more useful than the tests. Sitting down with the product owner and writing "Given a user has an expired card, When they try to book, Then they see a payment error" forces everyone to think about edge cases before a line of code is written. That alone would probably have saved us a few rewrites last quarter.
What worries me
1. Time. We already feel stretched. Writing feature files AND step definitions feels like extra work on top of extra work.
2. Maintenance. I've read a few horror stories about step definition libraries turning into a mess once you have a few hundred scenarios.
3. Buy-in. If the product side doesn't actually read or help write the scenarios, it feels like we'd just be writing tests in a more awkward format.
What I'm thinking of trying
Not going all in. Just picking one feature, probably the booking and cancellation flow since that's where most of our arguments happen, and writing scenarios for it together with the product owner. If it reduces the back and forth, we expand. If not, we drop it without much lost.
So for those of you who have used BDD on a small team:
- Did it actually reduce misunderstandings, or did it become a test-writing chore?
- Which tool did you go with? We're mostly Python so I'm looking at Behave and pytest-bdd.
- Anything you wish you'd known before starting?
Would really appreciate any honest experiences, good or bad. Thanks!