Unit‑testing microflows with user‑specific access rules

0
I am using the Mendix UnitTesting module to verify that our security (access rules) works as expected.The idea is to:Run a microflow as a specific user.Assert that the user can only see / manipulate the objects they are allowed to.Ensure that the test does not affect the real data – i.e. all changes should be rolled back when the test finishes.Example flow I want to test:What I’ve Tried1. Create a unit‑test that calls the target microflow directly (as the test user).Works, but the microflow runs with the system user, so the access‑rule checks are bypassed.2. Use ExecuteMicroflowAsUser (Community Commons Java Action) to invoke the microflow under the test user’s context.The microflow executes, but its changes are not reverted at the end of the test. Moreover, any objects created or modified in the parent test flow are not visible inside the called sub‑flow.3. Attempt to test a delete‑operation that should be blocked for the user.The test crashes with the exception:com.mendix.modules.microflowengine.MicroflowException: Object access cannot be retrieved. Specific IssuesNo transaction rollback – after the test finishes, data created/changed by the sub‑flow remains in the database.Isolation problem – objects prepared in the main test flow are not accessible inside the sub‑flow called via ExecuteMicroflowAsUser.Exception – trying to delete an object that the user should not have rights to throws Object access cannot be retrieved and aborts the test.What I’m Looking ForBest practice for unit‑testing microflows under a specific user context while keeping the test data isolated and automatically rolled back. Did anybody succeed in doing something like this?Whether the UnitTesting module itself provides a way to run a microflow as a user (instead of using Community Commons), I guess not?Any alternatives to ExecuteMicroflowAsUser that respect Mendix’s transaction handling (e.g., using the native RunAsUser action, test‑specific security settings, or a custom wrapper).Guidance on how to assert that a user cannot delete an object without causing the test to crash (e.g., catching the exception, checking return values, using security‑rule‑aware APIs).
asked
1 answers
0

Hi,


From what I know, this is expected behavior rather than a bug.


The UnitTest module runs in system context, and when using ExecuteMicroflowAsUser, the microflow is executed in a separate context/transaction. Because of that:


  • Changes may not be rolled back
  • Objects may not be shared between contexts
  • Security exceptions can occur at runtime


So, as far as I know, UnitTest is not really designed to validate access rules by switching user context.


As a suggestion, you could:


  • Test business logic separately
  • Wrap security-sensitive logic (e.g. return a boolean instead of letting it throw)
  • Avoid using ExecuteMicroflowAsUser inside unit tests


So this seems more like a limitation of how transactions and contexts work in Mendix rather than an actual issue.


If this resolves your issue, you can mark it as accepted.


answered