Initial migration from Boost.Test to googletest

[deanberris]

Squashed from a few (local) commits:

• Migrate message_transform_test and utils_thread_pool tests to googletest
• Simplify message testing, breaking it down to basics (construction, equality)
• Add googletest to YCM config
• Add the googletest dependency to CMakeLists.txt
• Add googlemock and googletest submodules properly.
• Add submodules for gtest and gmock

[glynos]

It's interesting you're migrating from Boost.Test, but I wanted to advocate Catch (https://github.com/philsquared/Catch) first ;) Is it too late to try?

[deanberris]

Catch looks interesting. The only reason I'm reluctant with using that, is the fact that I'm unfamiliar with it. I'm sure we can follow the TDD and BDD styles git googletest. There's all sorts of interesting possibilities with googletest that I'm relying on (parameterised test cases, type-parameterised cases, etc.) along with the integration with googlemock.

So while Catch is great for simple tests, I'm already using non-trivial test features from googletest. 😭

[glynos]

Catch is not as feature rich as googletest, for sure, but the reason we use it at work is that it is portable on many platforms and compilers, including embedded or exotic or old ones.

[deanberris]

Hmmm... doesn't this list cover enough interesting ground for googletest:

https://github.com/google/googletest#requirements

?

I don't see myself actually running cpp-netlib tests on embedded environments, and I fully expect to be able to cross-compile Boost, googletest, and cppnetlib libraries appropriately. My thought process here is:

• Developing comprehensive tests is good. googletest allows us to do this quite easily.
• Running tests on a regular basis on exotic/old hardware/environments is a nice goal, but should be doable with cross-compilation instead of expecting to build the stuff on the constrained environments.
• Coverage of platforms where the tests can run is not currently a goal, and familiarity to contributors will, I suspect, be more important.

Lots of large projects are already using googletest, a testament to maturity and scalability/familiarity to lots of potential contributors. Asking people to learn Boost.Test has already been a pain, and asking them to learn Catch is friction I don't think we need to introduce. 😉

[glynos]

You can remove unit_test_framework from the required packages in CMakeLists.txt

[deanberris]

Apparently, not yet because I haven't moved the other tests yet. I was hoping we can do that piece-meal (this only deals with the tests in the libs/network/test/... directory). I'll be migrating other tests later on.

[linquize]

Googletest is more popular

[glynos]

Thanks for your comment, @linquize, you're right, googletest is comfortably the most popular UTF for C++ that I am aware of.

What I wanted to raise is that googletest (and googlemock) requires a lot of work if you want to run tests on a platform that isn't one of the supported ones. This is the reason why we abandoned googletest at my current place of work in favour of Catch. Despite (because of?) its limited scope, it is by far the more portable UTF for C++ available.

I see an important part of cpp-netlib's future in, well, not quite embedded, but constrained environments such as Raspberry PI, or Android. These are platforms where developers would benefit from a simple-to-use C++ networking library (especially HTTP, but we can extend to others). That's why I want cpp-netlib to be as easy to build, use, and verify as possible.

However, I accept @deanberris's arguments (except that I was only ever talking about cross-compiling, I was not advocating building the library on the target environment), and agree that googletest is an improvement over Boost.Test.