How do experts UnitTest all the microflows?

Hey Yuki,
 

Unit testing can be a daunting task, man. Especially when you have large complex microflows. And I don’t know if you were looking for an answer from a dev’s perspective, but that’s what I have to give. Some of the best advice I’ve received that has helped me improve as a developer and helps with approaching unit tests is:

1. Whenever possible, simplify microflows to 10 or less activities. 
   1. This pushes you to create reusable components
   2. It generally results in a more readable and approachable microflow
   3. It generally helps with the creation of unit tests by allowing you to test the individual parts and pieces of a microflow rather than having to figure out how to prepare every require component at one time outside of runtime.
2. Create tests as you go. Creating the unit test prior to actually developing, or in other words applying a test driven approach to development, can help you understand what you have and what is expected before developing out the solution. In some cases, during writing of the test you may even create reusable microflows that can be implemented in the delivered logic.

 

As far as your question goes about not testing ‘all’ of the microflows, there are some microflows that are simple and straight forward enough they may not require regular execution of unit tests. Some of these flows may be things like validation microflows or microflows meant to fetch a set of data. You are asserting some things with these microflows, like the entity you’re validating hasn’t had required fields added to it, or the data required has been loaded into the system. By testing these once to ensure they’re performing the action they’re expected to, but not necessarily going through the full process of writing a complete unit test, you can save yourself time and allow yourself to focus on more complex functionality.

I hope these bits of advice ​​​​​help.​​ For reference, here is the unit test module I tend to use for development tests: https://marketplace.mendix.com/link/component/390

I hope some part of this helps and wish you all the best,
Austin

Created 2023-09-29

Austin Aylworth

Hey Yuki, I know it talks about this in the document you shared, but another couple of options would be to use: 1. Selenium IDE - This will allow you to test the overall functionality of a flow by recording a set of user steps. Its very convenient for initial testing as well as integration testing later on. 2. DevTools recently received an update that has a recorder functionality. This is more for performance testing, but it seems like you could use it in the same way as Selenium. It also appears to support puppeteer script generation Another thing I think is worth talking about is selecting the pieces of your large microflow that are most important. Generally the primary logic hinges on a few actions, and the other steps are there to prepare data or remove it accordingly. I'd say focus on those few actions where the true logic hinges. If the whole of your 25 activity microflow is built up of important logic I'd recommend putting in some effort to separate those actions in sub-microflows. Doing this will allow you to generate focused tests for each sub-microflow. Also, you can expose an endpoint in your app the takes OQL or SQL statements as input, executes them, and returns a valid or invalid result. You could use this as a way to run tests against the data layer of your application. Of course this endpoint would only be utilized for testing and not actual logic, but it could be an option for you to write and execute tests outside of Mendix if the UnitTest module is becoming too cumbersome. Also, if it's setting up your tests that is cumbersome, I've seen someone create a java action that essentially creates an object of a specified entity with randomly generated values for each of it's fields. So it's possible to create an action like that. I also found this module that may be able to help with the generation of test data: https://marketplace.mendix.com/link/component/112021 More than anything, Yuki, it sounds like there is some technical debt built up in your application that could use some addressing. After doing so it should make testing it that much easier. If you'd like to sit down and talk about it one of these days and show me what you're working with I may be able to offer additional insights. All the best, Austin

Created 2023-10-04

Austin Aylworth

Thanks, Austin! I was looking for a developer's perspective, and your advice is truly valuable, giving us some hope. I've got the two key points: simplifying microflows and creating tests as we code. The challenge is that, in my mega project, the microflows typically have around 25 activities or more, and microflows heavily rely on OQL/SQL activities. I'm grateful for the reference, and I am currently using the unittesting module. However, it's becoming quite resource-intensive to maintain. Are there any alternative approaches for conducting unit testing and checking coverage when making changes? Your insights are greatly appreciated. You're our last hope on this matter...

Created 2023-10-04

Yuki Aibe