You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

134 regels
5.0 KiB

  1. /**
  2. @mainpage
  3. This is the online reference for developing with the cmocka library. It
  4. documents the cmocka C API.
  5. cmocka is an elegant unit testing framework for C with support for mock
  6. objects. It only requires the standard C library, works on a lot of platforms
  7. (including embedded) and with different compilers.
  8. http://cmocka.org/
  9. @section main-features Features
  10. Tests written with cmocka are compiled into stand-alone executables and linked with the
  11. CMock library, the standard C library and module being tested. Any symbols
  12. external to the module being tested should be mocked - replaced with functions
  13. that return values determined by the test - within the test application. Even
  14. though significant differences may exist between the target execution
  15. environment of a code module and the environment used to test the code the unit
  16. testing is still valid since its goal is to test the logic of a code modules at
  17. a functional level and not necessarily all of its interactions with the target
  18. execution environment.
  19. The CMocka library provides:
  20. - Support for mock objects.
  21. - Test fixtures.
  22. - Only requires a C library
  23. - Exception handling for signals (SIGSEGV, SIGILL, ...)
  24. - No use of fork()
  25. - Very well tested
  26. - Testing of memory leaks, buffer overflows and underflows.
  27. - A set of assert macros.
  28. - Several supported output formats (stdout, TAP, xUnit XML, Subunit)
  29. - License: Apache License 2.0
  30. @section main-test A cmocka test
  31. Test cases are functions with the signature void function(void **state). Test
  32. applications initialize a table with test case function pointers using
  33. unit_test() macros. This table is then passed to the run_tests() macro to
  34. execute the tests. run_tests() sets up the appropriate exception / signal
  35. handlers and other data structures prior to running each test function. When a
  36. unit test is complete run_tests() performs various checks to determine whether
  37. the test succeeded.
  38. @code
  39. #include <stdarg.h>
  40. #include <stddef.h>
  41. #include <setjmp.h>
  42. #include <cmocka.h>
  43. /* A test case that does nothing and succeeds. */
  44. static void null_test_success(void **state) {
  45. (void) state; /* unused */
  46. }
  47. int main(void) {
  48. const struct CMUnitTest tests[] = {
  49. cmocka_unit_test(null_test_success),
  50. };
  51. return cmocka_run_group_tests(tests, NULL, NULL);
  52. }
  53. @endcode
  54. @section main-mock Mock objects
  55. You may already have heard the term "Mock Object". It describes a special case
  56. of an object that mimics a real instance of an interface in order to provide
  57. enough of that interface for testing. While there are several unit testing
  58. frameworks that already provide some easy to use interface for creating
  59. different kinds of "fake" objects for testing, there may be some confusion in
  60. terms of how these test objects are programmed and what the behavioral
  61. differences are between them.
  62. Mock objects include some logic and the test driver is able to modify the
  63. behaviour and state. The object can call some functions or act on different
  64. input (abort a test if it is wrong). The test driver injects what it expects
  65. the mock object to return. CMocka provides and API to easily mock code.
  66. <a href="https://lwn.net/Articles/558106/">Learn more ...</a>
  67. @section main-embedded Embedded platforms
  68. It is possible that some embedded platforms do not provide definitions for
  69. required types or that the guards to protect them are not defined. To address
  70. this issue you can create a header file name 'cmocka_platform.h' with the
  71. required types and definitions. After that point cmake to the include directory
  72. using:
  73. <pre>
  74. cmake -DCMOCKA_PLATFORM_INCLUDE=/home/compiler/my/include_directory ..
  75. </pre>
  76. @section main-threads Threading
  77. cmocka is not fully thread safe and it is not the goal of it to be it. We have
  78. several global variables to track test states. They are marked as thread local
  79. but it is possible that you still run into issues. However if you use cmocka
  80. for writing tests in an application which uses threads, you can set the
  81. following envionment variable:
  82. <pre>
  83. CMOCKA_TEST_ABORT='1' ./my_threading_test
  84. </pre>
  85. With this environment variable set to '1', cmocka will call <tt>abort()</tt> if
  86. a test fails.
  87. @section main-output Output formats
  88. By default, cmocka prints human-readable test output to stderr. It is
  89. possible to configure several other output formats. The configuration is
  90. done using the <tt>CMOCKA_MESSAGE_OUTPUT</tt> environment variable. The
  91. supported values are:
  92. - <tt>STDOUT</tt> for the default standard output printer
  93. - <tt>SUBUNIT</tt> for subunit output
  94. - <tt>TAP</tt> for Test Anything Protocol (TAP) output
  95. - <tt>XML</tt> for xUnit XML format
  96. The case doesn't matter.
  97. The XML output goes to stderr by default. If the environment variable
  98. <tt>CMOCKA_XML_FILE</tt> exists and the file specified by this variable
  99. doesn't exist yet, then cmocka will put the output to this file. Note
  100. that if you are have several groups you should set <tt>CMOCKA_XML_FILE</tt>
  101. to <tt>CMOCKA_XML_FILE=cm_%%g.xml</tt>. In this %g will be replaced by
  102. the group_name of the test and a file will be created for each group,
  103. othwerwise all groups will be printed into the same file.
  104. */