tree: 4c061f4686c9d0691a5f9131b060c06e21242eeb [path history] [tgz]
  1. ajax/
  2. dir with spaces/
  3. imagetest/
  4. protected/
  5. .leading.dot.txt
  6. 1000images.lua
  7. 100images.htm
  8. all_build_flags.pl
  9. bad.cgi
  10. bad2.cgi
  11. bad_page.lp
  12. bad_script.lua
  13. cgi_test.c
  14. cgi_test.html
  15. civetweb_check.h
  16. CMakeLists.txt
  17. cors.html
  18. cors.reply.html
  19. cors.reply.lua
  20. cors.reply.shtml
  21. delayed.cgi
  22. echo.lua
  23. embed.c
  24. env.cgi
  25. error.lua
  26. error404.htm
  27. exit.lua
  28. exploit.pl
  29. filehandler.lua
  30. form.html
  31. handle_form.lua
  32. hello.cgi
  33. hello.shtml
  34. hello.txt
  35. hello_gz.txt.gz
  36. hello_gz_unzipped.txt
  37. html_esc.lua
  38. HugeText.lua
  39. linux.cgi
  40. linux_fail.cgi
  41. linux_fail_silent.cgi
  42. lua_preload_file.lua
  43. main.c
  44. MakefileTest.mk
  45. MethodTest.xhtml
  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. public_func.c
  71. public_func.h
  72. public_server.c
  73. public_server.h
  74. README.md
  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