| Both sides previous revision Previous revision Next revision | Previous revision |
| user_guide:extend:unit_tests [2019/11/11 23:38] – ↷ Page moved and renamed from dev_corner:testcases to user_guide:extend:unit_tests gawrilow | user_guide:extend:unit_tests [2023/05/17 12:13] (current) – Typo lkastner |
|---|
| compare_values('ID', expected, expression); | compare_values('ID', expected, expression); |
| |
| Test is succeeded if //expected// and //expression// are of same type and have equal values. For C++ objects, the overloaded operator == is used. String values are compared with operator ''eq'' . polymake `big' objects may not be tested this way; use ''compare_objects'' as described below. | Test is succeeded if //expected// and //expression// are of same type and have equal values. For C++ objects, the overloaded operator == is used. String values are compared with operator ''eq'' . polymake `big' objects may not be tested this way; use ''compare_object'' as described below. |
| |
| **Caution:** if you want to compare values of different type, e.g. a Rational result of expression with an integral constant, you must either create the expected value of a proper type: | **Caution:** if you want to compare values of different type, e.g. a Rational result of expression with an integral constant, you must either create the expected value of a proper type: |
| simulates the F1 context help function of the interactive shell. Expected help topic headers should be listed in the order they would appear in the real session, that is, describing incomplete expressions from right to left. | simulates the F1 context help function of the interactive shell. Expected help topic headers should be listed in the order they would appear in the real session, that is, describing incomplete expressions from right to left. |
| |
| ==== Testing Transformation Scripts ==== | ==== Testing Data Upgrade Rules ==== |
| |
| Each time when you introduce a format change and create a XSLT version upgrade script, you should add testcases for it in the testgroup ''upgrade'' of the affected application. Preparing such a testcase is extremely simple: you take a data file in an old (pre-conversion) format, store it in two copies, e.g. ''Name-Version.poly'' and ''Name-Version-in.poly'', and load the ''Name-Version.poly'' into polymake, which automatically applies the transformation and stores it in the updated form. Then you add the following line to ''test.pl'': | Each time when you introduce an incompatible data model change and introduce upgrade rules, you should add testcases for them in the testgroup ''upgrade'' of the affected application. Preparing such a testcase is extremely simple: you take a data file in an old (pre-conversion) format, store it in two copies, e.g. ''Name-OldVersion.poly'' and ''Name-OldVersion-in.poly'', and load the ''Name-Version.poly'' into polymake, which automatically applies the upgrade rules and stores it in the updated form. Once you verified the correctness of data transformation, add the following line to ''test.pl'': |
| compare_transformed_object('Name-Version'); | compare_transformed_object('Name-OldVersion'); |
| |
| | |
| |
| |
| ===== Testing PTL data structures ===== | ===== Testing core library C++ components ===== |
| All tests for internal data structures are in ''polymake/testscenarios/core_lib_tests''. | Unit tests for core library components are kept in ''testscenarios/core_lib_tests''. They are based on [[https://github.com/google/googletest/blob/master/docs/index.md | googletest framework]] which should be installed on your computer separately. |
| |
| 1. Implement your change/addition to the PTL. | Please be aware that these tests may not involve any components depending on perl, which for the time being includes BigObjects. |
| |
| 2. Put a c++ file that tests your feature into ''testscenarios/core_lib_tests/source/polymake-pico/apps/test/src/''. Note that during execution of the tests, this file will get copied to the very similar directory ''testscenarios/core_lib_tests/polymake-pico/apps/test/src/''; don't let yourself get confused and edit the wrong file! | 1. Put the unit tests in a c++ file into ''testscenarios/core_lib_tests/src/''. |
| |
| 3. Put a trivial file that calls your test function into ''testscenarios/core_lib_tests/source/polymake-pico/apps/test/scripts/'' | 2. Change into ''testscenarios/core_lib_tests'', build and run the entire unit test suite once by issuing ''./build_test.sh'' |
| |
| 4. Put the expected output into ''testscenarios/core_lib_tests/expected/'' | 3. Add more unit tests to the same c++ file and run them exclusively: |
| |
| 5. Execute the tests by issuing ''./perform.sh'' (and not sh ./perform.sh) inside ''testscenarios/core_lib_tests'' | ninja -C work/build/Opt |
| | work/build/Opt/all_tests --gtest_filter=SUITABLE_PATTERN |
| | |
| | You can still use the script ''./build_test.sh'' for repeated test runs, it will just take longer because it starts a full clean build every time. |
| |
| 6. Relax if the tests pass; else iterate. | 4. If you want to debug failing tests, build them in Debug mode: |
| | |
| | ./build_test.sh --build-mode=Debug |
| | gdb -args work/build/Debug/all_tests --gtest_filter=SUITABLE_PATTERN |
| | |
| | Again, to avoid repeated full clean builds after fixing the library code or the tests, you can use ''ninja -C work/build/Debug'' |
| |
| ===== Investigating Failures ===== | ===== Investigating Failures ===== |