1. 29 Mar, 2017 1 commit
    • Pascal Bühler's avatar
      Add strict-prototypes warning if supported. · bb6ef8a3
      Pascal Bühler authored
      Ensure that all functions are correctly declared for c.
      There was one function in libsrtp that was not declared correctly
      and now it can be caught.
      
      This flags needed a custom program to check in configure, the built
      in function was invalid when using this flag.
      bb6ef8a3
  2. 27 Mar, 2017 1 commit
    • Geir Istad's avatar
      Bump copyright year · 445c1c94
      Geir Istad authored
      test_srtp.c had incorrect year (copy paste), updated to current year.
      445c1c94
  3. 14 Mar, 2017 2 commits
  4. 13 Mar, 2017 4 commits
  5. 08 Mar, 2017 2 commits
  6. 07 Mar, 2017 3 commits
  7. 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.
      f4b4173c
    • Geir Istad's avatar
      test/test_srtp.c: Add missing newline · df7266cb
      Geir Istad authored
      df7266cb
    • 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
      25cea284