Google Test Framework – First thoughts.

I have started a personal project to rebuild some software libraries that to take advantage the knowledge I have gained over the years and one of the things I wanted to do this time around was incorporate a unit testing framework. I selected the Google Unit test framework, gtest, because of these primary factors:

  • C++
  • Free
  • Can compile on multiple platforms
  • Been around a while
  • Good user community.

So I started building my unit test project following the simple examples and everything does go pretty smoothly at first. For the simple classes in the library I could easily create the test cases and to fully exercise all the calls for this class. However, as I continued to add more class I quickly realized the first drawback to my approach. The main file, the one that contains all the testing macros, gets large and unreadable very quickly with only a few classes added of the 100 or so I have planned. So clearly this will take some investigation on how to organize better. I will write about how I will solve this in future posts.

The gmock library addition to gtest was a nice find to help in working with abstract classes and template designs.  I found this very helpful for dealing with factory patterns and chain of responsibility calls to make sure calls were getting to the intended implementations. These take a bit more design thought to create good unit test cases, but worth the effort.

The second problem I encountered is something many embedded developers I feel will struggle, that is testing classes that are tied to a real-time operating system and to hardware level interactions. Searches for solutions on this topic did not provide much insight for solving these.

FreeRTOS is my current RTOS of choice, so I figured I would try integrating that first. It didn’t go so well. My hope was I could take the demo project for my platform, using Visual Studio 2010 on Windows 7, and drop the gtest in the middle. I should have known better, the part that gets in the way is the run to completion requirements for the gtest framework doesn’t work with FreeRTOS scheduler. I am not without hope, I plan on writing posts in the future on how to tackle this and get it to work.

Generally I am happy with how using gtest is going and encourage embedded developers to give it a good look for their own projects.

About Chris Snyder

Owner of Common Ground Software Solutions, LLC
This entry was posted in General. Bookmark the permalink.

One Response to Google Test Framework – First thoughts.

  1. Patriciabut says:

    There is definately a great deal to learn about this issue. I like all of the points you made.

Leave a Reply