... | ... | @@ -117,8 +117,8 @@ Kea undergoes extensive tests during its development. The following is a excerpt |
|
|
- Kea uses CI (Continuous Integration). This means that great majority of tests (all unit and system tests, and most performance tests) are run for every commit. Many lighter tests are ran on branches, before the code is even accepted.
|
|
|
- Negative testing. Many unit and system tests check for negative scenarios, such as incomplete, broken, truncated packets, API commands, configuration files, incorrect sequences (such as sending packets in invalid order) and more.
|
|
|
- We use many tools that perform automatic code quality checks
|
|
|
- We use static code analyzers: clang's Thread Sanitizer (TSAN), Coverity Scan, shellcheck, danger
|
|
|
- We use dynamic code analyzers: Valgrind
|
|
|
- We use static code analyzers: Coverity Scan, shellcheck, danger
|
|
|
- We use dynamic code analyzers: Valgrind, clang's Thread Sanitizer (TSAN)
|
|
|
|
|
|
## Fuzz testing
|
|
|
|
... | ... | @@ -126,7 +126,7 @@ We have a process for running fuzz testing, using [AFL](https://github.com/googl |
|
|
|
|
|
## Release integrity
|
|
|
|
|
|
Software releases are signed with pgp, and distributed via the ISC web site, which is itself DNSSEC-signed, so you can be confident the software has not been tampered with.
|
|
|
Software releases are signed with PGP, and distributed via the ISC web site, which is itself DNSSEC-signed, so you can be confident the software has not been tampered with.
|
|
|
|
|
|
|
|
|
# 4. FAQ
|
... | ... | |