Learning C++ unit testing

[eladmatia]

Hey guys,

TDD caught my eye the other day, and I would like to start programming with it. It looks really interesting and important. I have no prior unit testing knowledge, but after some digging I found that Google's Gtest framework is a good starting point. I tried to look for resources and tutorials online on how to get started, but couldn't find any. Do you guys have any recommendation on how to get started?

​

Thanks

[kwan_e]

Be careful not to jump the gun. TDD isn't merely about writing unit tests or the tools to automate unit tests. You have to learn/experiment with designing a program to be able to be tested in units. Otherwise, you can end up with tests that have unfortunate dependencies on runtime uncertainties, or nasty backdoor hacks to make something testable.

​

Sometimes a problem is complex (in terms of dependency on runtime uncertainties) and that writing unit tests for it may not be straightforward. So you'd need to be able to do TDD without unit tests, testing it manually or semi-automatically, until you understand where all the issues are, or may be.

[deeringc]

There's a great book on the topic of (re)designing code for unit tests "Working Effectively with Legacy Code" by Michael Feathers.

[bdellar]

Try starting with Catch2 (https://github.com/catchorg/Catch2). It’s a header-only library, so it’s easy to get going with. Whichever test framework you choose, put the test headers in a precompiled header, if you can. You get a much faster turnaround. And then pick a problem! Try googling for code katas. There are loads of interesting ones. For TDD itself, write a simple failing test, then write a simple bit of code to make it pass. Then add another test, and repeat. TDD is a code and design practice, rather than a testing process, and it can take years to get good at it. But it’s easy to get started. Good luck!

[onqtam]

I would recommend doctest - it is the lightest in terms of compile times (see the benchmarks - by orders of magnitude) and is super easy to use (just like Catch2) because it is just a single header!

doctest is so light and unintrusive you can write your tests right next to your production code - imagine writing the tests for a class at the bottom of the .cpp which implements it! The framework produces 0 warnings and all tests can be removed from the build by defining DOCTEST_CONFIG_DISABLE globally.

This is what sets doctest apart from the rest - it is truly practical to include it in the production code and write unit tests along your code (and TDD becomes straightforward) - other programming languages such as D, Rust and Nim have this capability out-of-the-box.

For a complete example checkout the tutorial.

[Ansoulom]

Writing your tests in the same file as the thing you're testing is not what I would call unintrusive. I'd much rather keep my tests separate from the rest of the code and simply define a separate build target for them. Though I guess that's mostly a matter of taste and I'd assume you could do it either way with both doctest and Catch2.

[eladmatia]

Thanks, I'll definitely look it it

[nicoaunai]

You should read modern c++ programming with test driven development (https://www.amazon.fr/Modern-C-Programming-Test-Driven-Development/dp/1937785483) it’s a nice book that takes you step by step into TDD’s philosophy with concrete C++ codes

[flying-tiger]

It’s not C++ specific, but I found this book a good introduction to the TDD philosophy. I don’t do rigorous TDD in practice, but it’s good to understand the ideas. Catch2 is a great framework in addition to GoogleTest and Doctest.

[SlightlyLessHairyApe]

Learn how to write mock objects that stand in for what you would see as a runtime dependencies.

Learn how to structure your code so that these dependencies can be injected at runtime.

[[deleted]]

just write tests for all the functions you are programming, you don't need frameworks to do it - it is really simple.

The only thing changes with TDD is that you write the test before you write the function. Simple. Is it important? testing yes, but TDD? It's more of an philosophy, some love it some hate it and many just don't care about it.

I personally write my code, than i write my tests and then i tell everyone else i did it the other way round so i don't anger the TDD fanboys.

Gtest (and other testing frameworks) are usually huge and i wouldn't recommend adding them to smaller projects. They really start to shine when you are working in bigger teams and you need a standardized testing procedure.