Building tests as modules
A low code, write-once test framework using test actions as instructions
Let’s talk a bit about testing time and scenarios.
Let’s assume you’ve written more than 300 tests on average by now. That means you’ve spent more than 300 minutes just waiting for them to pass or fail. I think we can agree, that’s a lotta waiting time.
In this blog, we’ll build a modular test framework that will help us execute our tests through the shortest possible paths toward an expected assertion. And we’ll also build a web app to make the whole setup easier to use.
At the bottom, you’ll find the link to a template repository on Github that can be easily adapted to any product logic even if what you do is Android or iOS. But first, let’s outline why we may need to write tests as modules.
Note that this approach is not meant to replace regression testing, it is important to keep a set of repeatable, thorough scripts separate for that.
Laying the foundation
- Say we have a product, let’s call it Coffee Dojo.
- Let’s assume we sell coffee online on our website.
- We need to test that our users can choose and pay for their favorite coffee successfully.
Typically we’d have a test suite that covers numerous scenarios for each path our users might explore. There are, however, underlying issues with this approach
- The scenario list is never extensive enough. A user somewhere will always try to order pineapple juice instead.
- We write more scenarios to cover up but the more extensive the list gets, the more expensive regression testing becomes.
- The tests also become difficult to manage over time as the product changes.
- Ever had to comment or breakpoint a section of your test because you only want to debug another section.
Our approach to solving them…
Today, we’ll build a test framework where our test steps are abstracted into action logics (you might already be familiar with this if you write POM).
- We’ll define some scenarios for our product and identify individual action steps.
- Write these steps into test methods.
- Then, build a UI tool to help us construct and arrange our preferred scenarios using the steps.
- Lastly, execute each scenario action in the sequence.
We’ll be building a test that can interlock scenarios.
Why is this better?
- This will solve our initial bloat problem by writing only test actions and not repetitive scenarios (which almost always only has minor differences).
- Time: Running automated tests through the shortest possible path will truly become possible. (since we only construct what we need).
- We are now testing for results on actual product logic and not just code.
- Our new test actions become the fundamentals of writing more test cases or paths.
Technicals of what you see above
1.) An assistive UI that helps in setting up our test scenario actions.
2.a.) A storage file, typically a JSON file managed via the file system which stores our preferred steps saved from the UI tool.
2.b.) A storage file, typically a JSON file managed via the file system, stores our details about each transaction in our test scenario.
3.) A test runner which uses the helper engine in calling each scenario action.
4.) Our engine serving JSON files as action attributes to each test method.
5.) Test methods individual path through the user experience as given requirements from our JSON file.
Conclusion
That's it! A test suite that not only runs a set of instructions but now allows more flexible interoperability of those instructions.
And with just a bit of Javascript, some node APIs, an Express Js app, and coffee, we can run each instruction in any order, making our assertions along the process.
Check out the Github repository and add some extra methods of your own, or rewrite it all using any language or paradigm of your choice.
Have fun and talk to you in the next one!
- Code on Github
