Testing your code — intro into Googletest

Deathpulse nm
Jul 30, 2017 · 4 min read

The most sure shot way of validating your code is by testing it. Just like how Proxy tests her solution by taking a few example problems where her code should succeed (or Fail) and testing it against her code. But Proxy here makes a few modifications to her code, to make it more efficient, and alas, she has to go through her tests again to validate his code post modifications.

This might not sound like a difficult task, and for a small program — it isn’t. For large and modular programs however, like the majority of applications built today: testing the entire code manually isn’t nearly as efficient or as foolproof as it can be. For example if we were to see if every function/method/variable in the code and verify that individually they work as intended and then test the code in it’s entirety: we know that this code works as intended and not because the test cases like these work out just fine:

A decently stupid example

We also make a header file for this function so that the tests themselves can access it. It goes without saying that you could write tests in the same file — but it is a much safer and cleaner practice to separate your tests from your main code.

So how do we make tests for this particular function? First we clone the googletest repo into our working directory. Now we move along to creating the tests themselves.

We try and think of different scenarios where function would succeed(or fail) and create tests for them.

You can make assertions about the behavior of the functions and hence create tests for them. Now as to the kind of assertions you can make — you have 2 at your disposal, a fatal(ASSERT_*) and a non-fatal assertion(EXPECT_*). Both have the same set of operations that they can assert — just at a level that could either be ignored and you could move onto checking the other behavior checks on the same function or at a level where this behavior check will show if the function is working or not(as in our case if it fails to show negative integers as negative — the function kind of fails its purpose). To know more about these two levels of assertions click me.

We do have something fundamental missing though. Maybe its not the main concern but for any C/C++ program to work — we require a little something<wink>. In our case — googletest provides its own makefile that you could use as a template and fill in the required dependencies. (In case you do not know what a Makefile is). In our case we use the following makefile:

If you can read the Makefile, you can see that I’ve put the 2 *.cpp and 1*.h files into a folder called src and placed the Makefile outside it (this is to maintain structure, you could even have another folder called executables where you would place your executable). After running make (which basically compiles using the code including the googletest libs and links the object files together to form the final executable, in our case being check_positive_test). Now you should have an executable by the name of check_positive_test and when you run it — you should see a couple of nicely color coded messages that that describe the tests that were successful and that failed.

Fail? what — but I thought this function was perfect T_T

Here we see that the test_case_name: FunctionTest with the test_name: NegativeInt has failed, this points to the fact that our function has failed the tests we made for the negative integers. After some brainstorming we finally come up with some code that makes sense even when negative integers are involved.

Note that the changes made are in the same file check_positive.cpp(I have created another file so as to preserve both files as gists).

Now when we run make again and run the executable again.

and Ho Ho Ho — does the all green color scheme look grand. Henceforth any new changes to the tests or new functions etc that are added will include the older tests as well so at any point you’re basically creating code that passes every previous test that you thought up. By the time you finish writing up code — it’s basically ready to go, no preliminary checks, no tests — nothing. This affects the way you write code and forces you approach a problem and solve it in a foolproof way.

Nader looks pretty confused with Proxy’s code.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade