Google Test

Google Test

Developer(s)	Google Inc.
Stable release	1.7 / September 2013 (2013-09)
Development status	Active
Written in	C++
Operating system	Linux, Windows, Mac OS X
Type	Unit testing tool
License	BSD 3-clauses
Website	github.com/google/googletest/

Google Test is a unit testing library for the C++ programming language, based on the xUnit architecture. The library is released under the BSD 3-clause license. It can be compiled for a variety of POSIX and Windows platforms, allowing unit-testing of 'C' sources as well as C++ with minimal source modification. The tests themselves could be run one at a time, or even be called to run all at once. This makes the debugging process very specific and caters to the need of many programmers and coders alike.

Approach towards testing

At Google, software testing is part of a centralized organization called Engineering Productivity that spans the developer and tester tool chain, release engineering, and testing from the unit level all the way to exploratory testing. There are a great deal of shared tools and test infrastructure for web properties such as search, ads, apps, YouTube, and everything else on the Web.

Google’s success at testing cannot be compared to that of a small or simple software portfolio. The size and complexity of Google’s software testing problem are immense. From client operating systems, to web apps, to mobile, to enterprise, to commerce and social, Google operates in pretty much every industry vertical. What Google testers accomplish on a daily basis cannot be credited to working on easy problems. Google testers face nearly every testing challenge that exists every single day.

Ultimately, quality is not of the highest importance. Simply put, quality is not equal to test. Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

Types of Google Tests

Google introduced its own classification of test types. Instead of categorizations like unit, functional or integration test they have only three categories: small, medium, and large scale tests:

Small Tests (Unit Tests)

Small tests are mostly (but not always) automated and exercise the code within a single function or module. The focus is on typical functional issues, data corruption, error conditions, and off-by-one mistakes. Small tests are of short duration, usually running in seconds or less. They are most likely written by a Software Engineer (SWE), less often by an Software Engineer in Test (SET), and hardly ever by a Test Engineer (TE). Small tests generally require sample environments to run and be tested in. Software developers rarely write small tests but might run them when they are trying to diagnose a particular failure. The question a small test attempts to answer is, “Does this code do what it is supposed to do?”

Medium Tests (Integration Tests)

Medium tests are usually automated and involve two or more interacting features. The focus is on testing the interaction between features that call each other or interact directly. Software engineers drive the development of these tests early in the product cycle as individual features are completed and developers are heavily involved in writing, debugging, and maintaining the actual tests. If a medium test fails or breaks, the developer takes care of it autonomously. The question a medium test attempts to answer is, “Does a set of near adjacent functions operate with each other the way they are supposed to?”

Large Tests (Acceptance Tests)

Large tests cover three or more features and represent real user scenarios with real user data sources. There is some concern with overall integration of the features, but large tests tend to be more results-driven, checking that the software satisfies user needs. All three roles are involved in writing large tests and everything from automation to exploratory testing can be the vehicle to accomplish them. The question a large test attempts to answer is, “Does the product operate the way a user would expect and produce the desired results?”

Fidelity

This test will fail under the condition that the code has failed during a test case or the test process itself. In other words; when the code breaks, the test is failed.

Resilience

The test should not fail if a test case does not pass. The test only fails when there is a breaking change that is implemented to the code being tested.

Precision

When the test fails, the exact error will be located and notified to the tester.

Others

• Basic Test
• Floating Point Comparisons
• Death Test

Projects using Google Test

Besides being developed and used at Google, many other projects implement Google Test as well:

• The Chromium projects (behind the Chrome browser and Chrome OS)
• The LLVM compiler
• Protocol Buffers (Google's data interchange format)
• The OpenCV computer vision library.
• The Gromacs molecular dynamics simulation package.

Google Test UI is test runner that runs one's test binary, allows one to track its progress via a progress bar, and displays a list of test failures. Clicking on one shows failure text. Google Test UI is written in C#.

Popular Tools used in Chrome with association to Google Test:

• Developer tools: Look at the page’s elements, resources, and scripts, and enable resource tracking.
• JavaScript Console: Does JavaScript in the Console execute correctly?
• Viewing source code: Is it easy to read through the use of color coding and other help, and is it easy to get to a relevant section?
• Task Manager: Do processes show up correctly and is it easy to see how many resources the web page consumes?

Fixtures

Fixture testing is crucial in computer code because it allows the testing of time and memory management. If these areas are lacking, bugs may arise, and ultimately the code may become incompatible or even fail to run in the first place. Google Test can specifically handle and run this type of test. When doing so, it can also recognize the type of fixture test required. Fixtures more or less in Google Tests are considered a class and can be instantiated as one as well. There are also details when understanding how fixtures work, and here are some of these details:

• One could do initialization or allocation of resources in either the constructor or the SetUp method. The choice is left to you, the user.
• One could do deallocation of resources in TearDown or the destructor routine. However, if they want exception handling you must do it only in the TearDown code because throwing an exception from the destructor results in undefined behavior.
• The Google assertion macros may throw exceptions in platforms where they are enabled in future releases. Therefore, it's a good idea to use assertion macros in the TearDown code for better maintenance.
• The same test fixture is not used across multiple tests. For every new unit test, the framework creates a new test fixture. So in Listing 14, the SetUp (please use proper spelling here) routine is called twice because two myFixture1 objects are created.

See also

• List of unit testing frameworks
• CppUnit

External links

• Google Test
• Google Test Primer documentation
• A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11
• The Google Test and Development Environment, Anthony Vallone, 2014-01-21