Skip to content

06 UnitTestXxx

Jump to bottom
JackHeeley edited this page Feb 4, 2022 · 10 revisions

Unit test projects

Three unit test projects are supplied, mapping to each of the three runtime projects described earlier. These are

  • UnitTestBasicUniversalCppSupport
  • UnitTestExtendedUniversalCppSupport
  • UnitTestSampleProgram

Each of these provides a(n extensible) test bed to exercise and demonstrate parts of the project under test. Each has some level of coverage of the methods in the runtime components.

Features

The unit tests make use of a header utf8_assert.hpp which wraps microsoft assert, and allows the utf8 everywhere paradigm to be extended to standard unit tests, built in the othodox way, using the Microsoft unit test framework.

Limitations

  1. Test coverage is appropriate (much less than 100%). This is consistent with the test driven approach of extending coverage as and when it is found wanting.

  2. Some tests will fail if the system has no optical media device (or none attached). Some tests may fail if the device doesn't have a motor or a lock mechanism on the tray. Some test sequences use eject and load, and that might not be supported on every CDROM device. If there is a spring mechanism, you may need to close the door by hand after an eject during some test sequences.

  3. After eject/load the system can decide data is stale and may not be quick to trust the 'swapped' media content. Depending on test sequence this may stress a subsequent test. Most sensitive tests attempt waits and retries, but this might not be good enough on all systems. All tests should pass if run individually. Run all tests, and then re-run failed tests before you draw a final conclusion.

  4. Some (read image) tests have been marked with TEST_IGNORE attribute so that the remaining tests can be run quickly and frequently. This is the reason that some test results are counted beside a warning sign in the test explorer, rather than being counted as a pass or a fail. Before check-in I also run the sample program, and mount and inspect the image file it makes. I do this and run all unit tests for all 4 build configurations (release and debug, x86 and x64).

  5. Be aware that using mount to confirm/inspect the image file integrity, only works for certain CDROM formats. Other formats will be reported as 'corrupt' ISO 9660 images. This doesn't indicate that the file was not read correctly. It only means that this method of validating the read is limited and the result is inconclusive with these test inputs.

  6. Visual Studio test discovery sometimes (very rarely) gets its architecture in a twist. If all tests fail don't believe it, and don't be downhearted! Its probably just trying to run 64-bit tests with a 32-bit architecture assumption. It will recover if you persist (try things like switching test architectures, choosing another build configuration, doing clean and rebuild etc).

Clone this wiki locally