I’m loving the BDD approach to development, but I’ve bumped into a concern with how far to go. This comment from ThoughtWorks most recent Radar gives me pause:
“The advent of behavior-driven design (BDD) testing frameworks like Cucumber, combined with browser automation tools like Selenium, has encouraged widespread use of acceptance testing at the browser level. This unfortunately encouraged doing the bulk of testing where the cost to run the tests is the greatest. Instead, we should test at the appropriate level, as close to the code as possible, so that tests can be run with maximum efficiency. Browser-level tests should be the icing on the cake, supported by acceptance and unit tests executed at appropriate layers.”
So here’s my scenario (pun intended):
I’ve got a basic CRUD app with a business requirement to filter the data displayed based on criteria the end user is permitted to select. For ease of discussion let’s say it’s an app for the power company, and I’m displaying current month-to-date power usage for each customer. The user of this app could narrow the data by selecting a single customer, multiple customers, no customers, or “All customers”. The displayed data will change based on what they select.
For a product stakeholder, these really represent 4 separate scenarios. However from a developer perspective they are practially identical, with the only difference being a parameter passed to the DB. So the question becomes: does the benefit of having each permutation spelled out outweigh the cost of running and maintaining them?
I think BDD principles would probably say “yes” because the communication of the expected behavior is more explicit, but I’m not sure. It certainly has the feel to me of overkill. The scenarios would likely be a lot of copy-paste with minor changes.
My inclination is to cover this functionality with a single scenario that captures the core business value (“when I select a customer I see the power usage data”), and then cover the other permutations with a set of non-UI-based integration tests that validate the service/query returns the correct data. Is this thinking wrong? What’s the best answer to making sure these scenarios are covered, without surrendering the benefits of BDD?
My rule for BDD is that the developers should easily be able to derive the scenarios from whatever behavior is described, and if they can’t, illustrate the behavior with scenarios.
BDD is at its most useful when it’s describing things that are tricky; either when passing expert knowledge to the developers, or narrowing down behavior until uncertainty is discovered. In a CRUD application with basic filters, behavior is really easy to understand.
What you’re describing is probably best covered Dan North’s “Ginger Cake” pattern: take the recipe for something else, but with one aspect of behavior different from another (or in this case with one additional, easy-to-understand aspect of behavior). He also uses copy-paste a bit, and I suspect particularly for this kind of behavior.
So, your inclination is perfectly correct. If automating, I’d probably automate just one example and let unit and integration tests cover the rest.
I’d also want to know why this project was being pursued. There has to be something interesting about it, or it wouldn’t be happening. Find that, and it’s probably a great place to start discussing scenarios.