I support I sort of consider it the user’s responsiblility to have configured a color scheme where most colors are readable. However, it would be both easy and a good idea to make it possible to configure the color scheme (at least from the source code), and I should probably add an option to output without colors (and enable that option by default when the output is not a TTY).

I always wanted a terminal which would automatically corrected colors based on contrast. At least a separate color scheme for default background color.

It should not be that hard, maybe I could add PoC using suckless’s st to my overly long TODO list…

It’s actually quite readable in black on white. Though I agree with the general sentiment, and it’s probably quite a bit worse on a yellowish background.

I really would have liked to print the line number where the assertion fails, but I’m not sure if that’s possible. Because of the use of macros, everything ends up on the same line after the preprocessor, so __LINE__ will be the same for everything. If you know of a way to fix that, I’d love to hear it. (The "in example.c:files" message was originally supposed to be "in example.c:<line number>")

More different asserts is a good idea, and so is renaming the header - the thing was under the temporary name “testfw” until right before I made this post.

There’s a couple of ways I can imagine that would be possible. Currently, each top-level describe generates a function; I could have a global array of function pointers, and use the __COUNTER__ macro to automatically insert describe‘s functions into that array. However, that would mean that the length of the array would have to be static. It probably wouldn’t be too bad though if it was configurable by defining a macro before including the library, and defaulting the length to something like 1024, though.

Another solution would be to not have these top-level describes, and instead have a macro called testsuite or something, which generates a main function. This would mean that, if your test suite is in multiple files, you’d have to be very careful what you have in those files, because they would be included from a function body, but it would be doable.

I think the first approach would be the best. You could then also have a runtests() macro which loops from 0 through __COUNTER__ - 2 and runs all the tests.

That’s i3-gaps, the terminal is termite, and the shell is zsh.

It’s not entirely independent, as it depends on the "it" macro to create a bunch of variables and run the deferred statements. A stand-alone implementation would require a macro you call at the beginning of a block which will contain deferred expressions, and a macro you call before every return, so it’s not as nice to use. It also relies on GNU extensions, which imo is okay for a test suite, but I’d be careful relying on them in regular code.

Anyways, I did the work to extract it into its own small library: https://gist.github.com/mortie/0696f1cf717d192a33b7d842144dcf4a

Example usage:

#include "defer.h"
#include <stdio.h>
int main() {
    defer_init();
    defer(printf("world\n"));
    defer(printf("hello "));
    defer_return(0);
}

If you want to do anything interesting with it, feel free to.