Menu

Test

Philipp Klaus Krause

Test

There is various infrastructure for testing sdcc and its components:

Regression tests
The most important aspect is [Regression Testing]: This infrastructure, which lives in sdcc/support/regression is used to compile, assemble and execute (via simulators, mostly uCsim) a large number of tests, for all stable targets.
The purpose of these tests is to ensure that sdcc compiles all the tests into correct code. Individual tests are usually derived from fixed bugs, new features or tests from other projects.

The [Distributed Compile Farm] executes these tests nightly on various host systems. Results can be seen on the Snapshots page via the green (all tests passed, including valdiag) or red (some tests failed) dot.

valdiag tests
This infrastructure, which lives in support/valdiag compiles some tests and checks that diagnostics (errors and warnings) are emitted correctly.

The [Distributed Compile Farm] executes these tests nightly on various host systems. Results can be seen on the Snapshots page via the green (all tests passed, including regression tests) or red (some tests failed) dot.

uCsim regression test
These tests live in sim/ucsim/*.src/test; their purpose is to spot regressions in the uCsim simulator.

historygraphs
These live in ../sdcc-extra/historygraphs. Four benchmarks (Whetstone, Dhrystone, Coremark, stdcbench) can be compiled for and executed for three targets (mcs51, stm8, r3ka). The graphs produced show benchmark score and code size over time. They can help spot performance and code size regressions.

Limited regression tests
These tests live in src/regression; these few tests have much lower coverage than the real regression tests, and are only used for the pic14 and pic16 ports. This infrastructure could be removed when pic14 and pic16 pass the real regression tests.


Related

Wiki: Distributed Compile Farm
Wiki: Home
Wiki: Regression Testing