From c6a971d971e9c8d732795dd6af335de148d5e148 Mon Sep 17 00:00:00 2001 From: John Beard Date: Mon, 29 Oct 2018 13:52:44 +0000 Subject: [PATCH] Dev docs: Add TOC to testing markdown --- Documentation/development/testing.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/Documentation/development/testing.md b/Documentation/development/testing.md index 9abfbfaea6..0b47d13a1e 100644 --- a/Documentation/development/testing.md +++ b/Documentation/development/testing.md @@ -1,6 +1,8 @@ # Testing KiCad # -# Unit tests # +[TOC] + +# Unit tests {#unit-tests} KiCad has a limited number of unit tests, which can be used to check that certain functionality works. @@ -13,13 +15,13 @@ required to add a test to the testing suite. The test CMake targets generally start with `qa_`, the names of the tests within CTest are the same but without the `qa_` prefix. -## Running tests ## +## Running tests {#running-tests} You can run all tests after building with `make test` or `ctest`. The latter option allows many CTest options which can be useful, especially in automated or CI environments. -### Running specific tests ## +### Running specific tests {#running-specific-tests} To run a specific test executable, you can just run with `ctest` or run the executable directly. Running directly is often the simplest way when @@ -42,7 +44,7 @@ Common useful patterns: You can rebuild just a specific test with CMake to avoid rebuilding everything when working on a small area, e.g. `make qa_common`. -### Writing Boost tests ### +## Writing Boost tests {#writing-boost-tests} Boost unit tests are straightforward to write. Individual test cases can be registered with: @@ -68,7 +70,7 @@ messages inside tested functions (i.e. where you don't have access to the Boost unit test headers). These will always be printed, so take care to remove them before committing, or they'll show up when KiCad runs normally! -## Python modules ## +## Python modules {#python-tests} The Pcbnew Python modules have some test programs in the `qa` directory. You must have the `KICAD_SCRIPTING_MODULES` option on in CMake to @@ -87,7 +89,7 @@ from the source tree: cd /path/to/kicad/source/qa python2 testcase/test_001_pcb_load.py -### Diagnosing segfaults ### +### Diagnosing segfaults {#python-segfaults} Although the module is Python, it links against a C++ library (the same one used by KiCad Pcbnew), so it can segfault if the library @@ -103,7 +105,7 @@ You can run the tests in GDB to trace this: If the test segfaults, you will get a familiar backtrace, just like if you were running pcbnew under GDB. -## Fuzz testing ## +# Fuzz testing {#fuzz-testing} It is possible to run fuzz testing on some parts of KiCad. To do this for a generic function, you need to be able to pass some kind of input from the fuzz @@ -147,13 +149,13 @@ where: The AFL TUI will then display the fuzzing progress, and you can use the hang- or crash-provoking inputs to debug code as needed. -# Run-time debugging # +# Run-time debugging {#run-time} KiCad can be debugged at run-time, either under a full debugger such as GDB, or using simple methods like logging debug to the console. -## Printing debug ## +## Printing debug {#print-debug} If you are compiling KiCad yourself, you can simply add debugging statements to relevant places in the code, for example: @@ -168,7 +170,7 @@ You can also use `std::cout` and `printf`. Ensure you do not leave this kind of debugging in place when submitting code. -## Printing trace ## +## Printing trace {#trace-debug} Some parts of the code have "trace" that can be enabled selectively according to a "mask", for example: