Best practises for Testing

.

System Testing

It can happen that a new process, workflow, or data flow needs to be implemented in a production system. This kind of update goes beyond simply adding new Masterdata, rather the user is looking for a different outcome in surrounding systems, and therefore full system testing should be applied.

In such cases the best approach is usually a new, separate instance of OACT in a test-environment, potentially in a Virtual Machine (see https://www.virtualbox.org/). A new instance requires some technical understanding but can be deployed in a matter of minutes. This totally eliminates the risk of test- and production-data getting mixed up. mariadb-dump or mysqldump can be used to copy production data to a new environment.

Testing which implies a change of other infrastructure or systems outside of OACT should almost always be done in a separate environment, including Operating System major updates, security settings, system settings, as well as major updates to oprtating systems or software used by OACT such as MariaDB, PHP (if OACT-GUI is used), or Python.

Unit or Function Testing

Preference should always be given to testing in a separate environment. In some situations it may be necessary to carry out testing in a live production environment, and that should be reserved for small-scope testing only. In that case, it is recommended to always use testcase-specific operators, users, and Masterdata, and ensure that in- and out-flows of test data are segregated from Production flows. In particular, test-specific Channels may be enough to isolate test- and prod-data, but this should be evaluated and confirmed on a case-by-case basis.

Any Unit or Function testing in a production system should make use of a relevant backup routine before making any changes.

Pointing the GUI to alternative databases

In the case of system-testing described above, the entire OACT System is deployed to a virtual machine. However, if only deploying an alternative database, e.g. DEV or TEST, you might want to only deploy a database, and point the existing GUI to that. Another use-case is if the installation does not have GUI installed at all, and you want to use a GUI only temporarily without installing it on the system. This can be achieved by manually editing the file : /connections/ConnectionManager.php on any system with the GUI installed, with the relevant connection settings. Note that this will affect all users.