====== 13 Unit Test Structure ======

In general, we strive to make unit tests and work in a test driven way. But dependent on the project, the customer and the circumstances we don't force unit testing, we force the pragmatic approach. [[kb:bestpractices:testing:|Find out more, how we test at HSE]].

From all the unit testing frameworks, we decided to use [[https://github.com/JKISoftware/Caraya|Caraya]] from JKI. 

===== How do we integrate unit tests in our project structure =====

  * We separate the unit tests (test code) from the source code of the project (code under test) by placing the unit test VIs in a separate folder (next to the ''<Project>_Source'' folder) and creating a separate LV project for it.
  * All the unit tests will be placed in UT_Main.vi between the two Caraya VIs. They serve the purpose to initialize and close a test suite. The connector pattern has to match, in order that our [[code:commercial:rat:tools:testr|RAT TESTR]] can execute it.


==== Directory Structure ====
We have a separate LV project, to allow usage of conditional disable symbols. If the amount of tests is growing, it is useful to structure them in a clean way.

  /<%project directory%>
  /Tests                                     // All sorts of tests for the repo.
      /Unit Tests                            // Unit Tests for the source code.
          /UT_Unit-1                         // All unit tests for a library or class (//Unit-1//).
              UT_Library-1.lvlib             // Library for this logical collection of unit tests.
              UT_Library-1_Main.vi           // This VI executes all unit tests in this library.
              Test_<Description>.vi          // Test case for one or more related unit tests.
          /UT_Unit-2                         // All unit tests for a library or class (//Unit-2//).
          Unit_Tests_<project_name>.lvproj   // Project file for the unit tests.
          UT_Main.vi                         // Main unit testing VI. This VI executes all unit tests.


==== Project Structure ====
  * We want to have clean dependencies and, again, clear separation between test code and code under test.
  * We decided to have a virtual folder ''Code Under Test'' where all dependencies from the tests will be placed.
  * Depending on the project, it might help to recreate the folder structure of disc hierarchy, but it is not mandatory to match 100%.
  * Goal is easy navigation, good orientation while not putting too much effort in it.
  * Auto-Populating folder may be used in exceptional cases if useful.
  * Have a virtual folder ''Unit Tests'' to round off the distinction
  * in some cases, it might be beneficial to wrap unit tests in lvlibs

{{:code:common:pasted:20230508-080315.png}}