• tests should be atomic, it should not contain other tests
• start writing tests at pain points, don't get lost
• preparation

  • do all the work which needs to be done for preparation in the given frame
  • if preparation needs to be used in multiple places, create a subVI and re-use it
  • in general: what runs in the given frame, should have been tested already in a separate UT, which should be called from a higher level (exception prove the rule)
• error handling

  • an error in the given frame will skip the execution of the test, what went wrong, should be visible somewhere, but it is not result of the test
  • wire only error out from VI under test to the error assertion
  • in 'given' an 'then' always wire error normally
• tests can test a VI, a class, a DQMH request, a module, an integration, … (don't be too strict)

  • if we'll face requirements for integration tests, which won't fit to our way, we'll discuss and adjust it

These tests are run on the developer PC without having the real hardware available. In order to achieve this, we need to either emulate or simulate any external environment dependencies:

Create digital twins of any external communication partner or device, and create it outside of the module. The module is not changed for this test, it is not aware that it's not talking to the “real” outside world.

Implement the module in a way that it can run without using (reading from or writing to) the real hardware. Usually, this is called a Hardware Abstraction Layer (HAL), and it's usually implemented by using object orientation. Both the real hardware driver class and the simulation class inherit from a common parent. When run on the real hardware, the module loads the actual hardware driver object. When run in simulation, the module loads the simulation (“mock”) object instead. The mock object must be able to serve the module such that the module is fully functional to the rest of the LabVIEW software.

Depending on the specifics of the module, we will either implement a simulation or an emulation.

• for communication via TCP or CAN, it might be quite simple to implement an emulation: Create the counter part of the communication (i.e. a small TCP server or a simple CAN receiver).
• for devices like PowerSupplies, it will be more straight-forward to go with simulation: Implement a mock object that we can instantiate instead of the real hardware driver object.

For DQMH, the API testers with implementing any needed emulation (eg a TCP server loop) and any injection functions

Unit tests are typically written to ensure that a section of an application (usually any smallest testable part, known as a “unit”) meets its design and behaves as intended.

For DQMH, module-level unit tests are available. These usually have wider scope as the whole module is the “unit” being tested.

Once we have all modules extended with either simulation or emulation, we can execute the whole system in that way. That will allow us to test the overall functionality.

Execution of software-only tests can usually be automated rather easily. The preferred method is doing unit testing. CI/CD systems help with event-based execution of unit tests. See our Release Automation Tools for more information.

These tests serve the purpose of testing our software in the actual real operating environment, together with all the components the system will interact with in the real world. This scenario covers both integration and performance tests (depending on the test data sent and the level of logging).

This applies both to complete applications and single modules (if applicable and implemented).

This is usually the first or minimal approach for any sw developer: Manually deploying and running both the LabVIEW software and any other components like hardware etc.

1. Pipeline builds an executable from the latest develop branch
2. Pipeline deploys the exe to the system corresponding to the project
3. Pipeline executes tests automatically
4. Pipeline logs results

• Sam's Refactoring Class
• LMock