In clinical diagnostic laboratories, end-to-end testing of complex LIMS workflows is a critical part of the laboratory validation process. Performing these tests manually takes a Herculean effort. They’re hugely time-consuming and prone to error. Automated testing is an obvious solution, but these tests can also be expensive and take considerable time to create. That’s why we developed a reliable and cost-effective way to automate the testing of Clarity LIMS workflows.

Why automate tests?

Automated tests help define what the code is supposed to do. Once set up, they let you identify and fix issues quicker than manual testing and at a lower cost. They also offer a repeatable process for testing changes to your application without the need for human involvement. And they provide one of the best ways of finding regressions in your system and verifying that nothing was broken as a result of a change you’ve made.

‍

Specifically, the benefits of our Clarity LIMS automated workflow testing include:

‍

• Faster development. You can generally write automated testing of most steps with basic validation in 50 lines of code or less.
• Faster integration testing. You can quickly test code and configuration changes in context, and run full end-to-end tests frequently.
• Fewer post-deployment issues. You can run automated tests on the production system to verify the complete workflow, from end to end.
• Greater confidence when making changes. You can refine your code or workflow more often, knowing that automated testing is likely to catch any issues.

How to build automated Clarity workflow tests

Choose UI- or API-driven testing

If you want to build automated workflow tests, the first step is to choose user interface (UI)-driven or application programming interface (API)-driven testing.

‍

• UI-driven testing aims to guarantee that testing exactly matches the user experience. However, it’s complex to build and might break with new Clarity LIMS releases or UI- based configuration changes, such as adding a new field to a table.
• API-driven testing is simple and familiar in that the code is similar to that used in integrations. Although it may not match the UI behavior exactly, the Clarity LIMS API granularity is a close match to user actions, which is why this is the option we generally choose.

Write the automated testing scripts

The next step is to write the scripts that drive the automated tests. If you’re using API-driven testing, you will write these scripts using the Clarity LIMS API. (We highly recommend you leverage our free open-source Clarity LIMS library for this.) Those familiar with Clarity LIMS may have experience with using the Clarity LIMS API to script external program plugins (EPPs) or to extract data. However, note that the usage of the API for testing works a little differently—in this case, it’s used to 1) start steps, 2) push them through the step lifecycle, and 3) complete them, all without user interaction.

‍

What do we mean by the step lifecycle?

1. Start a step. Steps are started by posting a step-creation element to the …/api/v2/steps endpoint. The endpoint returns a step element describing the started step.
2. Run through step states. Step elements have a current state attribute, the values of which closely match the tabs that the user sees in the UI (e.g., Pooling, Placement, Record Details). The sequence of states for a step depends on the configuration of the step.
3. Advance a step. Steps are advanced by posting a step element to the …/api/v2/steps/advance endpoint. The test script has to ensure that the step is in the right state to advance, that all necessary user-defined functions have been set and placements performed. The endpoint will return the current state of the step.
4. Automatically trigger EPPs. If there are automatically triggered EPPs in a step, they will be triggered when the step is started or advanced through the API.

Account for instrument and system integrations

If your workflows include instrument and system integrations, you’ll also need to account for those. For file-based integrations, your test script can upload and download files through the Clarity LIMS API. For more advanced instrument integrations, depending on whether the Clarity LIMS API or the instrument makes the call, you can either simulate the call via a test script, have a simple emulator for the instrument, or modify the integration code to allow for the integration to be bypassed.

Five tips for success

Lastly, we’d like to leave you with five tips to help you succeed:

‍

1. Start small.
2. Consider “Happy Path” testing, which often has the highest return.
3. Worry about “Unhappy Path” testing later (scenarios where samples fail lab processes).
4. Run tests frequently to determine if problems exist or have been introduced.
5. Use our open-source Clarity LIMS library, which makes writing and reading the tests much easier.

‍

The approach we’ve outlined here results in a stable, reliable, and relatively simple suite of tests that closely simulates user behavior. Investing in automated testing is worth it for many reasons—including the savings in time and effort compared to manual testing, reducing the risk of errors, and ensuring continued regulatory compliance.

‍

Check out our Clarity LIMS library and contact us if you need help writing automated tests.

‍