Timeline for What levels to test on with BDD/Cucumber?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 5, 2017 at 13:45 | comment | added | nepa | We currently plan to set a test architecture in place where we have separated execution logic from the test workflow (so the unit test just consist of calls to service.givenLoginSucceeds(); or someUnit.whenXyz() or thenAbc() etc.). The "step definitions" which are separated by scope (e.g. business domain, system, component or unit under test) can be annotated to be usable from Cucumber or such as needed. This way we have: Self-explaining code and high reusability which is beneficial for both, conventional and BDD tests and better maintainability. That could keep the cost in balance. | |
| Dec 5, 2017 at 12:39 | comment | added | k3b | Using bdd or unittests it is always a tradeoff between benefit/cost of development/maintanave and intended audience developer or domainexpert. Since businessrules are driven by domainexperts and probably change more often I assume that the bdd development/maintenace overhead is well spend here. May be my assumtion is wrong that bdd is more work than tdd. I have done a lot of tdd while own experience with cocumber/bdd is limited to a few examples (more read about it than doing myself) | |
| Dec 5, 2017 at 10:40 | comment | added | nepa | That's very precise, thanks! But doesn't it make sense to test on the unit level with BDD too in some cases when there are specific business rules tied to the unit? | |
| Dec 4, 2017 at 17:05 | history | edited | k3b | CC BY-SA 3.0 | added 344 characters in body |
| Dec 4, 2017 at 16:32 | history | answered | k3b | CC BY-SA 3.0 |