I see so many programmers tying themselves up in knots, trying to find “the right” testing strategy. I’d like to offer them a simple idea intended to make at least one of these knots loosen itself and disappear.
At some time a project will arrive to this point in which test category to favor on the long run. A lot of developer say that if you want to understand how a project works just check the requirements, if there are no clear written requirements, then they say go ahead and check the tests, if there arenl no tests you are more than screwed and you have the possibility to either leave the project as soon as possible or to show a way how a project should be maintained and not just kept alive.
I have worked on projects where we had no tests, and I have worked on projects where there were a tons of unit and integration tests, but the unit tests were tautological, and the it tests were clearly not validating the requirements just the developers assumptions, which is still not enough for you to understand the project and be confident when you change something.
I’m keen on introducing cucumber based tests on any projects which has real business logic with proper scenarios and not just crud based apps
These sound to me like projects where the programmers wrote tests without thinking about the purpose or value of those tests. Maybe they were only starting to learn. Maybe they were being instructed to write tests without understanding the reasons. Maybe they felt too much pressure to ask helpful questions. Maybe they worried that nobody would be able to answer those questions.
Customer Tests can help us understand what the system is trying to do. It sounds like this specific purpose interests you a lot right now. I hope you find your opportunity and that those tests help you. They don’t even need to be Cucumber-based tests, but as long as they are examples written from the point of view of someone using the system, then I imagine they will help you.
Good luck.
Recently I have shared a testing strategy - State Transitions testing. This strategy involves writing the requirements as a set of state transitions and creating test cases for each transition. This approach enables writing test cases quickly. When a test case is written for one transition, it can be easily replicated for the remaining transitions. Examples for a Spring Boot application and an Angular app are at:
Thank you. I should have said BDD testing instead of Cucumber as that is just a shiny tool but requires a mature team to use it, if not used well it can lead to chaos as well.
Indeed, this is an example of how testing strategy influences design choices. I remember this especially when trying to write automated tests for transitions between web pages 20 years ago. I realized that it would help to design the web pages in a way that makes them less dependent on the path taken to arrive there—and that seems quite obvious in retrospect, but it didn’t seem obvious at the time. This was we could treat a Workflow as a sequence of individual Steps that were easier to test with unit tests. Having clear State Transitions in the style of a finite state machine makes it easier to notice when we’ve introduced annoying assumptions about global state that affect our ability to “jump to the middle” of a Workflow. This encourages us to have less of that global state, but instead to design that as temporary inputs to a page, such as HTTP Request Query Parameters.
We then only need Workflow tests if we feel any doubt about whether we’ve correctly assembled a sensible Workflow from the Steps. (If I feel such a doubt, that nudges me to clarify the inputs to and the outputs of a Step.)