tree: 4c061f4686c9d0691a5f9131b060c06e21242eeb [path history] [tgz]
  1. .leading.dot.txt
  2. 1000images.lua
  3. 100images.htm
  4. CMakeLists.txt
  5. HugeText.lua
  6. MakefileTest.mk
  7. MethodTest.xhtml
  8. README.md
  9. ajax/
  10. all_build_flags.pl
  11. bad.cgi
  12. bad2.cgi
  13. bad_page.lp
  14. bad_script.lua
  15. cgi_test.c
  16. cgi_test.html
  17. civetweb_check.h
  18. cors.html
  19. cors.reply.html
  20. cors.reply.lua
  21. cors.reply.shtml
  22. delayed.cgi
  23. dir with spaces/
  24. echo.lua
  25. embed.c
  26. env.cgi
  27. error.lua
  28. error404.htm
  29. exit.lua
  30. exploit.pl
  31. filehandler.lua
  32. form.html
  33. handle_form.lua
  34. hello.cgi
  35. hello.shtml
  36. hello.txt
  37. hello_gz.txt.gz
  38. hello_gz_unzipped.txt
  39. html_esc.lua
  40. imagetest/
  41. linux.cgi
  42. linux_fail.cgi
  43. linux_fail_silent.cgi
  44. lua_preload_file.lua
  45. main.c
  46. page.lp
  47. page.lua
  48. page.ssjs
  49. page2.lp
  50. page2.lua
  51. page2.ssjs
  52. page3.lp
  53. page3.lua
  54. page3.ssjs
  55. page3a.lp
  56. page3r.lp
  57. page3v.lp
  58. page4.lua
  59. page5.lua
  60. page6.lua
  61. page_keep_alive.lua
  62. page_keep_alive_chunked.lua
  63. page_status.lua
  64. passfile
  65. prime.ssjs
  66. private.c
  67. private.h
  68. private_exe.c
  69. private_exe.h
  70. protected/
  71. public_func.c
  72. public_func.h
  73. public_server.c
  74. public_server.h
  75. require_test.lua
  76. resource_script_demo.lua
  77. shared.c
  78. shared.h
  79. ssi_test.shtml
  80. syntax_error.ssjs
  81. test.ico
  82. test.pl
  83. testclient.c
  84. timeout.cgi
  85. timertest.c
  86. timertest.h
  87. websocket.lua
  88. websocket.xhtml
  89. windows.cgi
  90. windows.cgi.cmd
  91. windows_fail.cgi
  92. windows_fail.cgi.cmd
  93. windows_fail_silent.cgi
  94. windows_fail_silent.cgi.cmd
  95. ws_status.lua
  96. x.php
thirdparty/civetweb-1.10/test/README.md

Testing

C API

The unit tests leverage the CTest and Check frameworks to provide a easy environment to build up unit tests. They are split into Public and Private test suites reflecting the public and internal API functions of civetweb.

When adding new functionality to civetweb tests should be written so that the new functionality will be tested across the continuous build servers. There are various levels of the unit tests:

  • Tests are included in
  • Test Cases which are there are multiple in
  • Test Suites which are ran by the check framework by
  • civetweb-unit-tests which is driven using the --suite and --test-case arguments by
  • CTest via add_test in CMakeLists.txt

Each test suite and test case is ran individually by CTest so that it provides good feedback to the continuous integration servers and also CMake. Adding a new test case or suite will require the corresponding add_test driver to be added to CMakeLists.txt