README 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175
  1. % backend/tests/README 2024-11-18
  2. Zint backend test suite
  3. -----------------------
  4. In order to build the zint test suite, zint has to be compiled with the
  5. ZINT_TEST option enabled:
  6. cd <project-dir>
  7. mkdir build
  8. cd build
  9. cmake -DZINT_TEST=ON ..
  10. cmake --build .
  11. When using generators that support multiple build configurations, such as
  12. Visual C++ Project Files (the default generator on win32), the configuration
  13. can be provided via --config:
  14. cd <project-dir>
  15. mkdir build
  16. cd build
  17. cmake -DZINT_TEST=ON -DCMAKE_BUILD_TYPE=Debug ..
  18. cmake --build . --config Debug
  19. Note specifying a matching CMAKE_BUILD_TYPE is required to set the test PATH
  20. environment for Windows.
  21. ------------------------------------------------------------------------------
  22. In order to run the test suite, the path of the zint library may need to be
  23. communicated to the runtime linker. On UNIX-like systems, this is done by
  24. exporting LD_LIBRARY_PATH to the path containing the zint library, which is
  25. <build-dir>/backend:
  26. cd <project-dir>
  27. cd build
  28. export LD_LIBRARY_PATH=$(pwd)/backend
  29. Setting LD_LIBRARY_PATH is not required if the zint library to be tested is
  30. installed into a system library path ( /usr/lib for example ) prior to running
  31. the tests, or if the tests are not run individually.
  32. (On Windows, the PATH may need to be set to include the DLL location.)
  33. ------------------------------------------------------------------------------
  34. To run all tests (within <build-dir>):
  35. ctest
  36. When using a generator that does support multiple build configurations, the
  37. configuration that was used to build the project has to be explicitly provided
  38. to ctest, even if it was the default one:
  39. ctest -C Debug
  40. For various useful options, e.g. matching (-R) and excluding (-E) tests, see
  41. https://cmake.org/cmake/help/latest/manual/ctest.1.html#options
  42. Tests can also be run individually, eg:
  43. backend/tests/test_common
  44. backend/tests/test_vector
  45. To run a single test function within an individual test, use '-f <func-name>':
  46. backend/tests/test_common -f utf8_to_unicode
  47. backend/tests/test_dotcode -f input
  48. To exclude a single test function, use '-n <func-name>':
  49. backend/tests/test_common -n utf8_to_unicode
  50. backend/tests/test_dotcode -n input
  51. To run all test functions that match (i.e. contain) a string, use '-m <string>':
  52. backend/tests/test_common -m not_sane
  53. backend/tests/test_dotcode -m encode
  54. To run a single dataset item in a single test function, use '-i <index>':
  55. backend/tests/test_dotcode -f input -i 2
  56. To run a range of dataset items in a single test function, use '-i <start>-<end>':
  57. backend/tests/test_dotcode -f input -i 2-5
  58. The '<start>' or '<end>' can be left out:
  59. backend/tests/test_dotcode -f input -i 2-
  60. To exclude a single dataset item in a single test function, use '-x <index>':
  61. backend/tests/test_dotcode -f input -x 4
  62. This can also take a range, '-x <start>-<end>':
  63. backend/tests/test_dotcode -f input -x 4-6
  64. Exclude can be used multiple times (unlike '-i'):
  65. backend/tests/test_dotcode -f input -x 4 -x 6-8
  66. The include and exclude options can be used together:
  67. backend/tests/test_dotcode -f input -i 2-7 -x 4 -x 6
  68. To show debug info (if any), use '-d <flag>':
  69. backend/tests/test_dotcode -f input -i 2 -d 1
  70. E.g. to print which dataset items are being run, use '-d 16':
  71. backend/tests/test_dotcode -f input -d 16 -i 2
  72. (for other flags see <project-dir>/backend/tests/testcommon.h)
  73. To run a test against BWIPP (if any), use '-d 128':
  74. backend/tests/test_composite -d 128
  75. (see also <project-dir>/backend/tests/tools/run_bwipp_tests.sh)
  76. To run a test against ZXing-C++ (if any), use '-d 512':
  77. backend/tests/test_rss -d 512
  78. (see also <project-dir>/backend/tests/tools/run_zxingcpp_tests.sh)
  79. To generate test data (if available), use '-g':
  80. backend/tests/test_dotcode -f encode -g
  81. ------------------------------------------------------------------------------
  82. If the zint library was built with static linkage support, i.e. ZINT_STATIC
  83. is ON, an additional test executable, which uses the zint-static library, will
  84. be built. The static variant of each test shares the test name, but has a
  85. "-static" suffix. For example,
  86. backend/tests/test_dotcode
  87. would run the dotcode test that uses the shared zint library, while
  88. backend/tests/test_dotcode-static
  89. runs the same test built against the zint-static library.
  90. ------------------------------------------------------------------------------
  91. To make with gcc sanitize, first set for libzint and make:
  92. cd <project-dir>
  93. cd build
  94. cmake -DZINT_SANITIZE=ON ..
  95. make && sudo make install
  96. Similarly to make with gcc debug:
  97. cd <project-dir>
  98. cd build
  99. cmake -DZINT_DEBUG=ON ..
  100. make && sudo make install
  101. To undo sanitize/debug, remake each after setting:
  102. cmake -DZINT_SANITIZE=OFF ..
  103. cmake -DZINT_DEBUG=OFF ..
  104. To get a clean libzint, set the above and also:
  105. cmake -DZINT_TEST=OFF ..
  106. (The tests will now fail to link.)