Debugging and Unit Testing

Enabling Debugging

Enable uSched debug messages by setting the CONFIG_DEBUG definition to 1 in include/config.h file:

#define CONFIG_DEBUG 1

Compiler Flags

Always use, at least, the following compiler flags when using gcc or clang:

-fstrict-aliasing -pedantic -Wall -Werror

If you're using another compiler, make sure you setup it correctly to trigger the same warnings that are issued by gcc (or clang) with the above flags.

Runtime Analysis

After Enabling Debugging, build and install the project. Then start uSched modules using valgrind in the following order:

~# valgrind --leak-check=full --show-reachable=yes --track-origins=yes uss
~# valgrind --leak-check=full --show-reachable=yes --track-origins=yes use
~# valgrind --leak-check=full --show-reachable=yes --track-origins=yes usd

Static Analysis

Always use splint to analyze the code. If you're unsure about what flags you should use, cleanup the project (running the undo script) and perform:

~# make test

This will run several static analysis tools, including splint, scan-build and pscan.

Behavioral Testing

Grant that all features behave as expected. Although the make test procedure will perform some behavioral testing by using uSched Client, it's not granted that everything is covered there at all times. Think about what you've done and what will be directly or indirectly affected and run some tests of your own.

Remote Testing

When working with code that may affect remote management features, always grant that remote connections are working as expected. If possible, run the client and the server in two different architectures with different endianness (you can use qemu for that purpose). If you can't, or don't want to perform such tests, request some uSched developer to do it for you.