I am exploring how to write unit test cases in Moqui. I could find some references of JUnits in the mantle-usl and example components.
The ‘create Sales Order’ test case in OrderToCaseBasicFlow.groovy [1] file helped to understand how to proceed with writing test cases and assert the results.
For the supporting data to create the sales order, I could understand that the demo data [2] needed to be loaded first after which the test was being successful as it used existing data for some products, product Store etc. And when sales order is being created through the test case, it is getting persisted in the database as expected.
I wanted to check how we can create test data that is valid only for the test run and gets deleted after the test run.
Also, what is the recommended way to create the supporting data for our test cases? Should that also be loaded only for the test cases?
It would be great if someone could share some insights on this.
[1] mantle-usl/OrderToCashBasicFlow.groovy at master · moqui/mantle-usl · GitHub
[2] mantle-usl/ZcaProductDemoData.xml at master · moqui/mantle-usl · GitHub
Thank you in advance
2 Likes
The service level integration tests do depend on demo data, but that is not the only purpose of demo data. It is also used to better understand how data is structured and for manual testing as well as automated.
What is the purpose of deleting test data after running tests? Why create and load data only for test cases? Both of these questions come down to what you are trying to accomplish… you mentioned the ‘solutions’ you proposed, but what are the ‘problems’ they solve?
In general testing is done on a disposable H2 database instance. The most common case for running the tests is to load a fresh database (or reload a previously loaded database with ‘gradle reloadsave’), run all or partial tests, examine the database for results as needed, and then throw it away (delete the whole database).
It is also possible to run the tests on other databases, but they are FAR slower when it comes to database metadata (creating tables/FKs/etc, retrieving table/etc metadata) and for the service level tests in Mantle USL and the screen render tests in various components the underlying database doesn’t matter so much (framework unit tests are a different story, those are useful for testing with other databases).
The idea of running tests that leave no trace is interesting, but for service level integration tests this a very low priority compared to being able to test end-to-end business processes in an environment that is as close to production as feasible for frequent test runs (both local and on CI servers, like Travis that Moqui itself uses for commit triggered CI tests).
Tests that leave no trace, or know how to clean themselves up, for this type of logic, would be incredibly difficult to built. Possible? Perhaps, but the tests create and update thousands of records across hundreds of transactions and all of those data changes would have to be tracked and reversed. This would be like implementing a manual transaction rollback… which is extremely difficult to do vs having a database keep data changes segregated from committed data (much easier… but only for the scope of a single transaction).
It is so easy and fast to delete and recreate a database that for testing purposes there is no point in cleaning up the database after running the tests… AND doing so would eliminate the ability to manually examine the resulting data by running Moqui on the same DB after running the tests. This is especially useful for maintaining tests, which unfortunately are sensitive to things like changes to entity field level audit logging (throws off the sequenced IDs with more or fewer audit logged fields).
3 Likes