Neither. We used Katalon for a while (Selenium based), but there are a lot of downsides.

- It’s complex to rerun tests when you changed your data, unless you add scripts to undo everything so you can start over. If you have a lot of integrations this won’t work at all.

- You can monitor if processes finish (succesfully), but it’s difficult to have your test suite evaluate the result if that depends on data or, even worse, document contents or integration with other applications.

- It’s a ton of work to keep your test scripts up to date with your model and pages. Every little change can ruin your test script.

If you really want to build something like regression tests, build it in Mendix itself so you can reuse existing flows. There are modules available to build your scripts that even (optionally) rollback changes after the test is done.

Based on my testing experience with Mendix, I would recommend the following steps:

1. Make sure you cover complex microflows with Unit Tests where possible, as larger or more complex microflows can start to produce unexpected results if they are re-used often with various input parameters. You can use the Unit Testing module for this purpose.
2. You can extract the logic from a ACT-microflow into a SUB-microflow to make it easier to test without relying on GUI testing solutions. This is faster and often preferable if testing certain functionality is required.
3. Stay away from testing the Mendix platform itself. This often yields no benefits as you cannot make changes yourself to the underlying components. However, if you require certain QA-mechanisms regardless of customer trust in the Mendix platform, or if you want to test the differences between Mendix versions, this advice can be ignored.
4. Only rely on GUI testing for a limited amount of user interactions, as making GUI tests often has a high-effort learning curve, making it not suitable for many starting Mendix developers. When you do write tests, make sure that you leverage test tooling that doesn't require a deep understanding of a secondary programming language for the reason previously mentioned. Good examples are FitNesse and Robot Framework, as they leverage DSL for writing tests. Based on my personal experience, this is often easier for Mendix developers to understand.
5. For a testing framework, no matter which choice you make, choose something that works well with modern JavaScript/ TypeScript frameworks. Selenium-based tools often attempt to find XPaths when the page is loaded, whereas this doesn't always mean that the element is loaded in a single-page TypeScript application like Mendix applications. Tools such as Playwright work better as they automatically re-attempt to find the element until the time-out is reached.

I hope this helps you out, please let me know if you have any further questions, or mark the question as answered if this completely answers the question.