Summary

This PR adds an automated framework for unit-testing, as well as a completely redone Makefile to support it, with some additional quality-of-life features.

Makefile changes

The Makefile now has 2 separate build profiles: a release build and a debug build. Both targets compile into their own object files and resulting binaries. This means there is no need to rebuild the entire project when switching between debug/releases builds. Each resulting binary goes inside the bin folder, with the exception of the release build being copied as webserv under the workspace root, when the build target is webserv or all (default).

The primary differences in the debug build are the following CFLAGS:

-g debug symbols
-O0 disable optimizations
-D TEST defines the TEST feature macro, enabling testing code & leaks call on exit
-D LOGLEVEL_INFO enables info-level log messages

Release build in contrast sets flags as:

-O3 optimization level 3
-Wpedantic pedantic error messages
-D LOGLEVEL_ERR log only errors

Primary rules of the Makefile are now as follows:

make / make all - builds all targets, (bin/debug, bin/release, bin/test, ./webserv)
make webserv - builds bin/release and copies it into the project root
make debug / make d - builds bin/debug (development build)
make release - release build
make test / make t - builds and runs unit tests
make run / make r - builds and runs the "RUN_TARGET" specified in the makefile, (debug by default)
make fmt - Runs clang-format on all .hpp/.cpp files inside src and test
fclean, clean, re

Unit testing

The project now contains a basic python script that finds all test functions inside the project and generates a main in order to run those tests. The make rule make test or make t as a shortcut, can be used to build and run all tests in the project. This rule is also executed in the PR workflow build job.

Small warning: The python script is very basic and does not do a lot of error checking. If the test build fails, running clang-format has a good chance to fix that, since the script is fairly fragile to bad formatting.

How to write a test?

There's a small working example in Reader.hpp / Reader.cpp. Intended use works as follows:

For a class Foo you'd like to unit test, inside the same source/header files & after the definitions for Foo, insert a preprocessor feature block with #ifdef TEST and #endif (both in source and header). This will ensure the testcode is not included in the release build.
Inside the feature conditional, define a class FooTest that inherits from Foo.
In the source file, include testutils.hpp.
Inside the derived test class you can define static void functions, with a name ending with _test. The python script will automatically find and call these functions when tests are ran.

The test functions should look somewhat like this:

void FooTest::foo_basic_test()
{
    BEGIN // <- defined in testutils, will open a block for catching exceptions

    bool result = Foo::some_function(); // <- use functions from the class you're testing

    EXPECT(result == true); // <- defined in testutils, insert any boolean expression you expect
    // to eval as true. If the expectation above evaluates to false, the test fails and outputs the 
    // name of this function + file + linenumber

    EXPECT(true); // <- you can place multiple expectations in the same test

    try { /* Some function that SHOULD throw an exception */ }
    catch (/*exception type*/)
    {
        // If the function you're testing should throw an exception, you can catch it and return to 
        // pass the test
        return;
    }
    EXPECT(false); // This will fail the test if the catch block wasn't reached

    END // <- defined in testutils, any exceptions that were not caught will fail the test here
}

Note also: Multiple test classes in one file are not supported!

alcjzk / Webserv

Unit testing & Makefile update #12

Summary

Makefile changes

Unit testing

How to write a test?