[FEATURE] How should we standardize testing of our algorithms?

[cclauss]

As discussed at #721 (comment), should we require (or at least encourage) tests with new submission to this repo? Other TheAlgorithms repos require tests. For example, the Python repo runs >520 tests on every pull request. DOing this would give reviewer confidence in the submission, would teach contributors how to do test driven development and would demonstrate to readers how to call the algorithm in a broader context.

Today we already lint our submissions in GitHub Actions but should we go beyond that basic hygiene?

Detailed Description

Context

Possible Implementation

[Ghostkeeper]

I think there are a number of considerations with choosing a testing framework for this repository that are more important than for other projects:

• It needs to be very easy to create tests, since this is for learning.
• The tests need to be easy to read, for the reasons mentioned by Cclaus to teach readers how to call the algorithm in a broader context.
• The tests need to be easy to build. Currently the only dependencies of this project are CMake and the optional Doxygen dependency. This is a big plus for learners, who are often scared away from trying to build+run projects by the difficult process of building it and its dependencies. This is something that most other repositories in TheAlgorithms don't need to consider as much (e.g. because it's not a compiled language).
• [Optional] We could choose to use the same testing framework as the C algorithms repository. If people contribute to both of these repositories, they'd only need to learn about one testing framework. That limits the available testing frameworks to those that support both languages. I don't have a lot of experience with that though.

Things that are perhaps less important for this repository are:

• Feature completeness. We won't need death tests or anything advanced like that. And in fact, usage of advanced features will make it harder to read the tests so even if they are supported by the testing framework, so we may want to discourage usage of advanced features.
• Brevity. Since these algorithms are quite self-contained, it makes sense for the tests to be self-contained too. Makes it easier to read the tests as well. If that comes at the cost of repeating code used to create fixtures or something, that is acceptable. Of course, this should hopefully not go at the cost of readability.

Several good candidates:

• Catch: Nice that it's header-only and single file, so it's easy to build, we could just include it in the repository even if that's really a problem. The syntax is quite simple and easy to read.
• GoogleTest: Serious candidate purely by virtue of being probably the most commonly used testing framework nowadays. If you're not using advanced features, the syntax is also really simple.
• Boost Test: Very similar in usage to GoogleTest, but not quite as popular in the real world. Maybe because it's a bit harder to set up the build system for, in my experience. Once the CMake is written it should be easy enough to build though.

One candidate I'd like to discourage for this repository is CppUnit. Although the framework is quite commonly used and the way of writing tests is very similar to how it's used in the common framework JUnit, the tests are pretty hard to read and verbose. It's hard to learn since there is more bookkeeping to it.