Update google test doc

6-InRealEnvironment/6-Tools.ipynb

 %% Cell type:markdown id: tags:
 
 # [Getting started in C++](/) - [C++ in a real environment](./0-main.ipynb) - [External tools](./6-Tools.ipynb)
 
 %% Cell type:markdown id: tags:
 
 <h1>Table of contents<span class="tocSkip"></span></h1>
 <div class="toc"><ul class="toc-item"><li><span><a href="#Introduction" data-toc-modified-id="Introduction-1">Introduction</a></span></li><li><span><a href="#Online-compilers" data-toc-modified-id="Online-compilers-2">Online compilers</a></span></li><li><span><a href="#Static-analyzer-tools" data-toc-modified-id="Static-analyzer-tools-3">Static analyzer tools</a></span></li><li><span><a href="#Valgrind" data-toc-modified-id="Valgrind-4">Valgrind</a></span></li><li><span><a href="#Address-sanitizer" data-toc-modified-id="Address-sanitizer-5">Address sanitizer</a></span></li><li><span><a href="#Sonarqube" data-toc-modified-id="Sonarqube-6">Sonarqube</a></span></li><li><span><a href="#Tests" data-toc-modified-id="Tests-7">Tests</a></span><ul class="toc-item"><li><span><a href="#Boost-tests" data-toc-modified-id="Boost-tests-7.1">Boost tests</a></span></li><li><span><a href="#Catch2" data-toc-modified-id="Catch2-7.2">Catch2</a></span></li><li><span><a href="#Google-test" data-toc-modified-id="Google-test-7.3">Google test</a></span></li></ul></li><li><span><a href="#Build-system" data-toc-modified-id="Build-system-8">Build system</a></span></li><li><span><a href="#Code-formatters" data-toc-modified-id="Code-formatters-9">Code formatters</a></span></li><li><span><a href="#Doxygen" data-toc-modified-id="Doxygen-10">Doxygen</a></span></li><li><span><a href="#More..." data-toc-modified-id="More...-11">More...</a></span></li></ul></div>
 
 %% Cell type:markdown id: tags:
 
 ## Introduction
 
 The purpose of this notebook is just to namedrop briefly some facilities related to C++ that might be useful.
 It's far from exhaustive - I won't present debuggers as usually they are provided directly with your IDE (and if you're a Vim or Emacs user you probably already familiar with [gdb](https://www.gnu.org/software/gdb/)).
 
 Some tools are redundant, but they are complementary: the more you may be able to use the better. The constraint is time: it is not straightforward to use some of those, and even for the user-friendly ones there is a non neglictible set-up time. But for projects that are gaining traction it becomes a no-brainer at some point to set-up those properly once and for all - usually part of [continuous integration](https://gitlab.inria.fr/FormationIntegrationContinue/gitlabciintroduction) process.
 
 
 ## Online compilers
 
 This [blog post](https://arne-mertz.de/2017/05/online-compilers/) gives several such online compilers we mentioned several times in this tutorial.
 
 I have used only [Coliru](http://coliru.stacked-crooked.com/) which provides an API to incorporate directly some interactive code in a Web page (disclaimer - I have not used that feature yet) and [Wandbox](http://melpon.org/wandbox) which may be useful in day-to-day work as you may try a snippet of code with many configurations. It's useful for instance when you intend to use a bleeding-edge feature to see which version of compilers support it or not.
 
 ## Static analyzer tools
 
 [cppcheck](http://cppcheck.sourceforge.net/) is a static analyser program; it might really help you to find some questionable constructs in your code. As many tools, it's not 100 % accurate and sometimes it may raise false positives, but I nonetheless recommend it warmly.
 
 [cpplint](https://github.com/cpplint/cpplint) is also worth a look, we mentioned it for instance in [this chapter](./2-FileStructure.ipynb) to track down missing includes in files.
 
 [clang-tidy](https://clang.llvm.org/extra/clang-tidy/) was recently recommanded to us by colleagues from [LoOPS network](https://reseau-loops.github.io/index.html).
 
 
 
 ## Valgrind
 
 [Valgrind](valgrind.org/) is mostly known as a leak checker, but is really a jack-of-all-trade tool; callgrind for instance may be used to profile your code and see where most of the computation time is spent. Some lesser-known tools are also incredibly useful: [Verrou](https://github.com/edf-hpc/verrou) for instance, developed at EDF, is a floating-point checker which helps you figure out if at some point some of your computations might be skewed by the way the computer approximates the real numbers.
 
 Unfortunately, macOS support is scarse: sometimes they plainly say it is not up-to-date, but even when they say it works the outputs were never satisfactory for me (always check `valgrind ls` first as they recommend on their website...). So even if I develop mostly in macOS I always fire up valgrind in a Linux environment.
 
 ## Address sanitizer
 
 A [recent "concurrent"](https://github.com/google/sanitizers/wiki/AddressSanitizer) (once again use both if possible!) to Valgrind, which has the advantage of running with a much better runtime (Valgrind slows down your program tremendously). Might be integrated in some IDEs (it is in XCode on macOS).
 
 
 ## Sonarqube
 
 [Sonarqube](https://www.sonarqube.org/) is a development platform which inspects your code and helps to figure out where there are issues. It enables integration of multiple tools such as cppcheck mentioned earlier. If you're Inria staff, an instance was set by our [Bordeaux colleagues](http://sed.bordeaux.inria.fr/) and is [available](https://sonarqube.inria.fr/) for you.
 
 For open-source projects, the company behind Sonarqube provides a [freely accessible platform]( https://sonarcloud.io/about).
 
 
 ## Tests
 
 These are frameworks to write your tests; to actually run them you should see what your build system provides (for instance CMake comes with CTest which takes gracefully the management of tests in your project).
 
 ### Boost tests
 
 [Boost test](https://www.boost.org/doc/libs/1_69_0/libs/test/doc/html/index.html) is a widely used facility to write unit and integration tests with your code.
 
 It might be used as a header-only or as a compiled library; for big projects they recommend using the latter.
 
 ### Catch2
 
 [Catch2](https://github.com/catchorg/Catch2) is a more recent test facility which is aimed at being user-friendly.
 
 ### Doctest
 
 [doctest](https://github.com/onqtam/doctest) is a C++ testing framework but is by far the fastest both in compile times (by orders of magnitude) and runtime compared to other feature-rich alternatives. It brings the ability of compiled languages to have tests written directly in the production code thanks to a fast, transparent and flexible test runner with a clean interface.
 
 ### Google test
 
-This test utility is the only one we know that provide mocks; unfortunately I can't give you first-hand feedback.
+[GoogleTest](https://google.github.io/googletest/) includes everything that is needed for testing: [xUnit](https://en.wikipedia.org/wiki/XUnit), test discovery, rich test assertions, death tests, XML test report generation, ...
+It is also the only one we know that provide mocks. It is worth saying that mocking in C++ requires your application to be specially designed for it, more informations are available on the [gMock cookbook](https://google.github.io/googletest/gmock_cook_book.html)
 
 
 
 ## Build system
 
 Already mentioned [here](./1-SetUpEnvironment.ipynb#Build-system).
 
 ## Code formatters
 
 It is useful to delegate the check on your code format to an external tool, which may take a bit of time to configurate to suit your needs.
 
 I can mention [Uncrustify](http://uncrustify.sourceforge.net/): plenty of options to configure, even if they're not easy to figure out.
 
 [clang-format](https://clang.llvm.org/docs/ClangFormat.html) probably provides a better trade-off power/complexity but requires LLVM clang to be installed on your system (AppleClang won't do).
 
 
 ## Doxygen
 
 [Doxygen](http://www.doxygen.nl/) is a software to write an automatic documentation for your functions / classes / types / you name it.
 
 It is rather easy to set up to easy task but may become a tad more difficult once you want to tackle more advanced features. Nonetheless it is the de-facto standard for C++ documentation and it's really something you should set up quite early if you're working on a project meant to stay for a while: it's really a hassle to spend countless hours providing after the fact such guidance in the code. As for compilers, you should strive to provide a documentation without any warning.
 
 An important drawback of Doxygen is that its "compilation" of your project is much less advanced than the one provided by your compiler:
 
 * No parallelism in some steps.
 * Everything is redone at each Doxygen call.
 
 So expect for important projects the time to generate Doxygen documentation to be bigger than compilation time.
 
 I have observed Doxygen is not very efficient on macOS for sizeable projects: time is much more important than the one observed in Alpine Docker images...
 
 
 ## More...
 
 Our colleagues at Inria Bordeaux also recommend some additional tools in the Inria SonarQube
 [documentation](https://sonarqube.bordeaux.inria.fr/pages/documentation.html#orgd4ab5b1).
 
 
 
 %% Cell type:markdown id: tags:
 
 
 © _CNRS 2016_ - _Inria 2018-2020_
 _This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) under the terms of the licence [Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)](http://creativecommons.org/licenses/by-nc-sa/4.0/)_
 _The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_