Google Test

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Google Test
Developer(s) Google Inc.
Stable release 1.7 / September 2013; 10 months ago (2013-09)
Development status Active
Written in C++
Operating system Linux, Windows, Mac OS X
Type Unit testing tool
License BSD 3-clauses
Website code.google.com/p/googletest/

Google Test is a unit testing library for the C++ programming language, based on the xUnit architecture.[1] The library is released under the BSD 3-clause license.[2] 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. Google Test is a debugger for computer programs and code because at the first sign of a failure, the debugger is automatically invoked.[3] 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.

Google's Approach Towards Testing Software[edit]

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. [4] 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. [5]

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. [6]

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. [7]

Types of Google Tests[edit]

Three main types are small, medium, and large scale tests:

Small Tests[edit]

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 SWE, less often by an SET, and hardly ever by TEs. [8] 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?” [9]

Medium Tests[edit]

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. [10] 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?” [11]

Large Tests[edit]

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?” [12]

Fidelity[edit]

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. [13]

Resilience[edit]

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. [14]

Precision[edit]

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

Others[edit]

  • Basic Test [16]
  • Floating Point Comparisons [17]
  • Death Test [18]

Projects using Google Test[edit]

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

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#.[19]

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? [20]

Fixtures[edit]

Fixture testing is crucial in computer code because it allows the testing of time and memory management. [21] 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 is 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.[22]

See also[edit]

References[edit]

  1. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 2013-08-14
  2. ^ Google Test's site, retrieved 2013-08-14, cites New BSD as license. The license file is at code.google.com/p/googletest/source/browse/trunk/LICENSE
  3. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 201-04-28
  4. ^ Whittaker, James How Google Tests Software Page 5, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-02
  5. ^ Whittaker, James How Google Tests Software Page 5, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-02
  6. ^ Whittaker, James How Google Tests Software Page 6, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-02
  7. ^ Whittaker, James How Google Tests Software Page 7, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-02
  8. ^ Whittaker, James How Google Tests Software Page 12, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-05
  9. ^ Whittaker, James How Google Tests Software Page 12, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-05
  10. ^ Whittaker, James How Google Tests Software Page 12, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-05
  11. ^ Whittaker, James How Google Tests Software Page 12, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-05
  12. ^ Whittaker, James How Google Tests Software Page 13, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-05
  13. ^ The Google Test and Development Environment, Anthony Vallone, 2014-01-21, retrieved 201-05-10
  14. ^ The Google Test and Development Environment, Anthony Vallone, 2014-01-21, retrieved 201-05-10
  15. ^ The Google Test and Development Environment, Anthony Vallone, 2014-01-21, retrieved 201-05-10
  16. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 201-04-28
  17. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 201-04-28
  18. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 201-04-28
  19. ^ Google Test retrieved 2014-04-28
  20. ^ Whittaker, James How Google Tests Software Page 251, Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7, retrieved 201-05-02
  21. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 201-04-28
  22. ^ A quick introduction to the Google C++ Testing Framework, Arpan Sen, IBM DeveloperWorks, 2010-05-11, retrieved 2014-04-28

Further Reading[edit]

  • Whittaker, James How Google Tests Software Boston Massachusetts: Pearson Education 2012. ISBN 0-321-80302-7

External links[edit]