Remix.run Logo
bluGill 2 hours ago

I you are using googletest, you owe it to yourself to check out catch2 which I find much better and uses modern C++. There are a few other test frameworks in C++ that look better than google test as well, but catch2 is the one I settled on (and seems to be the best supported): feel free to check them out.

I've given up on mock frameworks. They make it too easy to make an interface for everything and then test that you are calling functions with the expected parameters instead of the program works as you want. A slight change to how I call some function results in 1000 failed tests and yet I'm confident that I didn't break anything the user could notice (sometimes I'm wrong in this confidence - but none of the failing tests give me any clue that I'm wrong!)

Maxatar an hour ago | parent | next [-]

catch2 has become fairly bloated. doctest takes all of the best parts of catch2 without all the bloat and the end result is a test framework that is literally over 10x faster than catch2. It's also like 90% compatible with catch2 so porting your tests to it is pretty easy.

Especially if you have a build process that always runs your unit tests, it's nice to have a very fast test/compile/debug loop.

https://github.com/doctest/doctest

gary_0 an hour ago | parent [-]

I was just about to suggest doctest, you beat me to it! I'm all about faster compile times, and it was mostly a drop-in replacement for catch2 in my case.

Also, IMO, both doctest and catch2 are far superior to Google Test.

ehoh an hour ago | parent | prev [-]

Sounds like the mocks are overused or used inappropriately in your experience (whether by a colleague or yourself).

Mocks have their place. A prototypical example is at user-visible endpoints (eg: a mock client).

bluGill an hour ago | parent [-]

I have found in my world it is easy to setup a test database (we use sqlite!) and the file system is fast enough (I have code to force using a different directory for files). I have been playing with starting a dbus server on a different port in my tests and then starting the real server to test against (with mixed results - I need a better way to know when dbus is running). I have had great success by writing a fake for one service that is painful - the fake tracks the information I really care about and so lets me query on things that matter not what the function signature was.

I'm not arguing that mocks don't have their place. However I have found that by declaring I won't use them at all I overall come up with better solutions and thus better tests.