Avoid common pitfalls

Test automation brings a number of pitfalls that you should avoid.  In this page we mention a few that should be avoided as much as possible

Don’t use a test tool that cannot be maintained by the development team

Test automation is a domain of its own. There are many different tools, all based on different technologies. There is a good reason for that. The ideal test tool does not exist. Second best is a test tool that your development team can maintain, therefore always look for test tooling that:

  • Is written in the same language as the app you are testing
  • Can be maintained with the existing knowledge in your team
  • Has specific features that support the app/platform that you are testing.

Don’t try to test processes with a high coverage

Processes are the easiest to understand from an end user perspective. However, process testing with high coverage is an impossible task if you look  at the number of variations that can occur in a process. It is better to:

  • Rely on unit and component testing for testing the extreme scenario’s
  • Focus the process testing on happy flow and only cover the scenario’s with the highest risks
  • Use a product risk analysis to determine the processes that need testing

Don’t build screens and API’s for testing purposes only

Although in Mendix is is relatively easy to build screens or API’s it is not a good idea to create screens and API’s just for test automation purposes because:

  • These test screens and API’s pollute your Mendix models and therefore your Mendix app will be more difficult to maintain
  • Test screens and API’s can be dangerous in production because they can cause security risks
  • It is expensive to maintain screens and API’s for test purposes only

Avoid a large testdebt

Mendix projects often start small. Because a Mendix team can create new functionality very fast it is possible to create so much functionality that a serious test debt is already present after a few months of development. Avoid this testdebt by:

  • Creating tests as soon as possible (as soon as the code becomes stable)
  • Invest in testing early. The later you start the less coverage you get for the same investment
  • Prevent refactoring of the code that is necessary for test automation purposes. It is easy to make code testable when first created. It can be painfully hard to make code testable once in production
Foto Niels

Need an expert to help avoid pitfalls

Contact us and one of our experts will help you