haskal
/
kicad
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Dev docs: Add TOC to testing markdown

This commit is contained in:
John Beard 2018-10-29 13:52:44 +00:00 committed by Wayne Stambaugh
parent e601b42207
commit c6a971d971
1 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
Documentation/development/testing.md
View File

@ -1,6 +1,8 @@
# Testing KiCad # # Testing KiCad #
# Unit tests # [TOC]
# Unit tests {#unit-tests}
KiCad has a limited number of unit tests, which can be used to KiCad has a limited number of unit tests, which can be used to
check that certain functionality works. 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 The test CMake targets generally start with `qa_`, the names of the tests
within CTest are the same but without the `qa_` prefix. 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 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 option allows many CTest options which can be useful, especially in automated
or CI environments. 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 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 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 You can rebuild just a specific test with CMake to avoid rebuilding
everything when working on a small area, e.g. `make qa_common`. 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 Boost unit tests are straightforward to write. Individual test cases can be
registered with: 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 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! 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. The Pcbnew Python modules have some test programs in the `qa` directory.
You must have the `KICAD_SCRIPTING_MODULES` option on in CMake to 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 cd /path/to/kicad/source/qa
python2 testcase/test_001_pcb_load.py python2 testcase/test_001_pcb_load.py
### Diagnosing segfaults ### ### Diagnosing segfaults {#python-segfaults}
Although the module is Python, it links against a C++ library 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 (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 the test segfaults, you will get a familiar backtrace, just like
if you were running pcbnew under GDB. 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 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 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 The AFL TUI will then display the fuzzing progress, and you can use the hang- or
crash-provoking inputs to debug code as needed. 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 KiCad can be debugged at run-time, either under a full debugger
such as GDB, or using simple methods like logging debug to the such as GDB, or using simple methods like logging debug to the
console. console.
## Printing debug ## ## Printing debug {#print-debug}
If you are compiling KiCad yourself, you can simply add debugging statements to If you are compiling KiCad yourself, you can simply add debugging statements to
relevant places in the code, for example: 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 Ensure you do not leave this kind of debugging in place when
submitting code. submitting code.
## Printing trace ## ## Printing trace {#trace-debug}
Some parts of the code have "trace" that can be enabled selectively according to Some parts of the code have "trace" that can be enabled selectively according to
a "mask", for example: a "mask", for example: