• Geir Istad's avatar
    Introduction of CUTest Framework · 25cea284
    Geir Istad authored
    This framework is header only which is the main reason it was chosen.
    More information about it (not that much really!) can be found in [1].
    The license is MIT and the copyright notice is included in the header
    cutest.h so I think putting the file in our repo is OK wrt licensing.
    Location of new files and structure for unit tests are up for discussion.
    Note that I am including "srtp.c" in "test_srtp.c" in order to test it's
    internal (static) functions.
    Alternatively we could try to test from public API, however that is
    already done in for example /test/srtp_driver.c which functions more
    like an integration/module test.
    The purpose of the unit tests are (for now) testing of lower level
    functions that are not exposed
    in the public API.
    Alternative layout could be to put the unit tests in a /test/ folder in
    the root directory of the file that is being tested.
    Alternative frameworks considered:
    cmocka [2] does not require external tools and have support for mocking.
    It does however require more than a header to run. This seems like the
    best bet if we do want to introduce a unit test system that supports more
    advanced functionality.
    CTest [3] introduces a dependency on cmake - depending on both make and
    cmake seems kind of annoying.
    Google Test [4] requires a C++98 compatible compiler, requiring this for
    a C library seems excessive.
    [1] https://github.com/mity/cutest
    [2] https://cmocka.org/
    [3] https://cmake.org/cmake/help/v3.0/manual/ctest.1.html
    [4] https://github.com/google/googletest
.gitignore 632 Bytes