1. 13 Mar, 2017 2 commits
    • Geir Istad's avatar
      test_srtp.c: Regression test for issue #256 · a156f4a2
      Geir Istad authored
      This is simply a regression test and a model for how we can test the
      generation of IVs without firing up a full crypto session.
      This test should be agnostic to the endianness of the system since it
      only deals with setting of single bytes for the postcondition IVs.
      We check that each IV is generated as expected and we check that each IV
      is distinct.
    • Geir Istad's avatar
      WIP IV regression tests · cd7beb45
      Geir Istad authored
  2. 08 Mar, 2017 2 commits
  3. 07 Mar, 2017 3 commits
  4. 06 Mar, 2017 3 commits
    • Geir Istad's avatar
      test_srtp.c: Naming for the one and only test · f4b4173c
      Geir Istad authored
      Test name was fairly ambiguous. It might make slightly more sense now.
    • Geir Istad's avatar
      test/test_srtp.c: Add missing newline · df7266cb
      Geir Istad authored
    • 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