Because you, the client of the test suite, are supposed to add the body of the function after using the macro. All the other functions are defined as empty functions (i.e. no setup required), or are implemented in the "Setup" class that is inherited (multiple inheritance being used in the second macro) which will be called FooSetup (and implemented by you as well, maybe with help from another macro), if you pass Foo as the "name" macro argument.

So you need to understand:

macros as token concatenating and text pasting devices (using #, ## macro operators)

the macro is incomplete (i.e. non-compiling) code when expanded and requires the client to provide the function body (may have helper macros to assist in that too, I expect there is at least a macro to close the test function definition, and probably many more)

multiple inheritance (used by the 2nd macro only)

EDIT: More fundamentally, macros (#defines) ARE NOT C++ CODE, they are just bits of text pasted into the program source when the macro is expanded by the preprocessor. It just happens that expanding the macro when given certain arguments results in a snippet of code which may be handy when passed through a C++ compiler. It's basically a way to save a lot of very boilerplate code having to be typed by you, the user of the test suite.

Replace "you" with "user of your test suite" if you are attempting to roll your own test suite framework though. As others have said, I wouldn't recommend it, you have a working framework with examples already.

If you really really want to make your own test suite (and not just "zig a zig ahh"), start off not using any #defines at all, then when you realise exactly what the boilerplate code needs to look like for various tests, start turning it into token pasting/concatenating macro snippets of code that is added to by the client code. Expect this process to be annoying and error prone (or not flexible enough) at first though,