Test the Architecture with Google Test

Google Test is a relatively small library which is used by many developers, as of March 2020 the project has 805 watching, 14.6k starred and 5.8k forked.¹ The library has many related open source projects as visualized below.

Using an operational view on C++ testing, it is observed that Google Test is like a core which can be used in different kind of open source test projects. So operation is mainly done by extensions, while support is provided using different independent projects for different extensions.

A typical use case would look as follows: A developer needs to check if code works as intended. The developer uses the Google Test library to write tests that ensure correct functionality. It then uses the Google Test system to execute the test, which delivers a report on the tests and their results.¹

Software patterns

When thinking in terms of Architectural styles, we can see that the architecture of this project is very flat there is virtually no layering. This is partially due to that it is not a stand alone object. It is made to be used with your own code, which becomes a part of the system. However the choices made by the developers resulted in interesting software patterns, which we will come back to shortly. The developers of Google Test decided to make the system a base in which extensions could be added for other features like parallelism ² or special features for a specific project³. This choice has effects on the non-functional properties.

Extendability can be very useful to keep the base code small. More classic systems often have a lot of code or functions which will not be utilized in any project. However they are build in the software, so you pay the price in memory, complexity and sometimes performance. By using extensions, the amount of unused code is minimized.

This also helps with maintainability. If something breaks, the effects are contained to the extension. This makes it easier to spot and fix the problem, while the rest can continue to function. Moreover, this systems allows for multiple users/developers to create their own extension for their own needs with relative ease.

There is a downside to using an extension based system. Because extensions should be stand alone or dependent on as few as possible other extensions, code repetition can increase. This means the codebase could actually become bigger than an equivalent monolithic design, an effect that grows worse as more extensions get added. This can get especially bad without central guidelines and organization.

Usability of the system should be high in order to allow a diverse community to make use of the system. First, documentation should be available for each available function of the code base. Moreover, diverse amounts of platforms are available, thus the system should be compatible at least for the following platforms: Linux, Mac OS X, Windows, Cygwin, MinGW, Windows Mobile, Symbian and PlatformIO. While the code base should be kept maintainable.

Compatibility for different platforms and maintainability of the code base can however pose a conflict of interest, in particular with respect to required code duplication for the diverse platforms.

Development view

A system can be viewed in different views to describe the different perspectives of a system. The most elaborate view for the Google Test framework is the development view. Typical aspects of this view are the organization of the modules, the coding styles which are enforced on the developers and the pipeline of checks on new commits ⁴.

Google test consists out of two main components, googletest and googlemock ¹. The first is the core functionality of Google Test providing among others the assert statements. The second provides mock classes as an extension. Each file in the project contains an extensive amount of comments. This is a good standard, especially in open source projects. This way other developers can easier see the meaning of the code and can faster start to write their own code. On the other hand, some files are more than 1000 lines of code excluding white spaces and comments which does not improve the readability of the code.

When you make a commit within the project, multiple checks are done to ensure that the code is working comments are in place. Two continuous integration (CI) tools are used: Travis CI and Appveyor. There are some pull requests currently open where one of the two fails and the other passes. So these two CI tools really complement each other as an extra check that the commit does what it is supposed to do.

Another check for each commit is done by the googlebot ⁵. This bot checks if all contributors of an eventual pull request signed the Contributor License Agreement. This is a typical agreement seen within open source projects. It defines the terms under which the code is contributed to a company (in this case Google). This prevents a lot of legal issues later on in the process if someone claims his or her code as his or her property. The Googlebot also checks if everyone who made a commit in a pull request consents that the code is merged to the master. Next to these checks there are also a lot guidelines for the developers such as coding style which helps the project to keep a uniform style.

Deployment- and runtime view

Two other popular views are the deployment- and the runtime view. These views are not very elaborate for the Google Test framework. Since Google Test is a framework, it does not need any extra hardware for deployment. Google also does not have to take a network connection into account (except for developing). The framework will be online via github and that is also the only extra third party software they need. Deployment of the framework at Github therefore does not need many resources. The same holds for the amount of resources during runtime.

The user has to have a network connection for a short time. As a user you need to download the framework once. Users can download the framework directly from the github page and set it up from scratch. An eventual upgrade can be obtained be replacing the updated files. An alternative way is via Visual Studio ⁶. In Visual Studio you can create a Google Test application which has the framework automatically included in your application. An upgrade of Google Test will be taken care of by Visual Studio. Therefore at the user site the deployment view also needs minimal resources, namely only the short network connection. The runtime view depends on the way the user installs the framework. If the users use Visual Studio it is straightforward. From scratch it will be harder.