I like tests. I think they are necessary to get the feedback I need in order to feel confident about what I have made. Especially with writing software, as it is something rather abstract ( I like algorithms and related things and like to do things myself ) and therefore feedback helps me develop a feel for what I am doing.

Other people, especially in organisations tend to use tests as a way to define workloads and to make sure that many people can work together somewhat seamlessly. As such, when I looked on the internet for testing support software, I found this and to be honest, I found it rather overwhelming.

I am also of the opinion, that keeping things simple is a generally good strategy, even when simple does not (necessarily) mean user friendly (at least to the uninitiated). What I mean by simple is "conceptually simple". So that once the concept is understood it is clearly visible.

Now testing is something that ( at least for C++ ) can't be integrated into the "production" (with that I mean the program that is the point of the software) program without at least some trickery. Of course there is the preprocessor that can help a lot with testing and is the main tool that is used with the testing frameworks that operate directly from within the production source. I however currently think that testing is ( at least conceptually ) not part of the language ( at least not part of C++ anyway ). It can be integrated with some work ( as in the testing frameworks referenced above ) but only with some quite opaque compiler and preprocessor magic.

As such I currently think that testing should be delegated to the build mechanism as ( at least for me ) it belongs there. It after all is responsible for taking the sources and turning them into runnable code. This comes with some drawbacks that ( very probably at least ) have been addressed by the various frameworks out there and some things that are subject to opinion.

I for example don't like a thousand lines of test code at the end of every source file, I'd rather have that in a separate file, even though I am still somewhat split on documentation in that respect. If I am however already putting the tests into another file, I can also just put in a main() and have a test program without needing to worry about strange artifacts or warnings in the "production" code.

I admit that this has the drawbacks of having to write a main function over and over again, and I have the feeling that my opinion about testing frameworks will change if my skill and intuitive understanding of the language and the runtime/compiler-features grows, but for now, standing in front of this large mountain of testing frameworks that all do a million things that I don't understand and don't know why I would need (yet), Im opting to write little standalone programs and integrating them into the build system because that seems the most natural thing to me at the moment. I am happy that meson ( the build system that I am using ) has support for that very thing.

I have to fight my urge to be overly perfectionist and this is one of these decisions where I am trying to do the obvious next step that will wind up with me refactoring code. At least it has the benefit of me doing something at all.

Have a nice day.