Chapter 10. Requirements on execution time

Sometimes it is not enough that your code does the right thing. It must do the right thing with the right timing. Testing time consumption requirements is easy with crpcut.

In order to check performance requirements, crpcut provides the ASSERT macros ASSERT_SCOPE_MAX_CPUTIME_MS(ms), ASSERT_SCOPE_MAX_REALTIME_MS(ms) ASSERT_SCOPE_MIN_REALTIME_MS(ms), and the corresponding VERIFY macros VERIFY_SCOPE_MAX_CPUTIME_MS(ms), VERIFY_SCOPE_MAX_REALTIME_MS(ms) VERIFY_SCOPE_MIN_REALTIME_MS(ms),

Let's use the above macros and put the POSIX function usleep() to the test. The test is to assert that it neither takes too long, nor too short, and also to assert it yields the CPU during the time instead of busy waiting. Below is a small test program for it

     
     #include <crpcut.hpp>
     extern "C"
     {
     #  include <unistd.h>
     }
     TEST(verify_time_consumption_of_usleep)
     {
       ASSERT_SCOPE_MIN_REALTIME_MS(99)
       {
         ASSERT_SCOPE_MAX_REALTIME_MS(101)
         {
           ASSERT_SCOPE_MAX_CPUTIME_MS(1)
           {
             usleep(100000); // 100 ms
           }
         }
       }
     }
     
     
     int main(int argc, char *argv[])
     {
       return crpcut::run(argc, argv);
     }

Running the test program shows that the implementation of usleep() on the computer used for writing this documentation does indeed do the right thing.

     1 test cases selected
     
                    Sum   Critical   Non-critical
     PASSED   :       1          1              0

	Tip
	When hunting down logic bugs in your code, you may want to run tests under time consuming tools like valgrind, but they greatly impacts the timing of your code, invalidating all performance tests. In those situations, the -t / --disable-timeouts command line flag comes to the rescue. It tells crpcut to never fail a test due to its time consumption.

	Tip
	If your continuous integration tool runs unit-tests with code coverage, or a similar environment that severely slows down execution, you can extend all timeouts using the command line parameter --timeout-multiplier=factor, while still enjoying the timed guards against no-progress bugs.