### Install Skia Docserver

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/dev/tools/markdown.md

This command uses the Go package manager to download and install the Skia documentation server from its source repository. Ensure Go is installed on your system before running this command.

```Go
go get skia.googlesource.com/buildbot.git/doc/go/docserver
```

--------------------------------

### Example Usage of JavaScript Page Setup Function

Source: https://github.com/weolar/miniblink49/blob/master/content/resources/HeaderFooterHtml.htm

An example configuration object demonstrating the parameters that can be passed to the 'setup' function. It includes properties for page dimensions, margins, print-specific content (date, title, URL, page number), and a flag for enabling header/footer printing.

```JavaScript
/* setup({ "date":22222.000000, "height":600.000000, "width":600.000000, "pageNumber":"0/1", "title":"hahaha", "topMargin":40, "bottomMargin":180, "url":"file:///E:/test/matter/printing.htm" }); */
```

--------------------------------

### Example mb_config.pyl Configuration with Mixins

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/tools/mb/docs/user_guide.md

This example demonstrates the structure of the `configs` and `mixins` dictionaries within `mb_config.pyl`, showing how build configurations are defined by combining various mixins, each specifying GYP or GN arguments.

```Python
{
  'configs': {
    'linux_release_trybot': ['gyp_release', 'trybot'],
    'gn_shared_debug': None
  },
  'mixins': {
    'bot': {
      'gyp_defines': 'use_goma=1 dcheck_always_on=0',
      'gn_args': 'use_goma=true dcheck_always_on=false'
    },
    'debug': {
      'gn_args': 'is_debug=true'
    },
    'gn': {'type': 'gn'},
    'gyp_release': {
      'mixins': ['release'],
      'type': 'gyp'
    },
    'release': {
      'gn_args': 'is_debug=false'
    },
    'shared': {
      'gn_args': 'is_component_build=true',
      'gyp_defines': 'component=shared_library'
    },
    'trybot': {
      'gyp_defines': 'dcheck_always_on=1',
      'gn_args': 'dcheck_always_on=true'
    }
  }
}
```

--------------------------------

### Installing Software with Microsoft Visual C/C++

Source: https://github.com/weolar/miniblink49/blob/master/third_party/libxml/src/win32/Readme.txt

To install the compiled software into the directory specified during the configuration stage, use the NMAKE utility with the install target. This example uses MSVC.

```Batch
nmake /f Makefile.msvc install
```

--------------------------------

### Install Android Build Prerequisites (Linux/Mac)

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/android.md

Installs Apache Ant and Git, essential utilities required for building Skia on Android, in addition to standard Skia checkout dependencies.

```bash
$ sudo apt-get install ant git
```

--------------------------------

### Display Help for mb Subcommands

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/tools/mb/docs/user_guide.md

The `mb help` command provides comprehensive documentation and usage information for all available `mb` subcommands. It is a quick way to get assistance on how to use the tool effectively.

```shell
mb help
```

--------------------------------

### Install libpng on Ubuntu

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Installs the libpng development packages on Ubuntu using apt-get.

```sh
sudo apt-get install libpng12-0 libpng12-dev
```

--------------------------------

### Build and Run Sample Test with Google Mock Makefile

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gmock/README.md

These commands illustrate how to use the provided Makefile in the Google Mock `make/` directory to build the library and run a sample test. This is a convenient way to get started on systems with GNU make.

```bash
cd ${GMOCK_DIR}/make
make
./gmock_test
```

--------------------------------

### Install Chromium Depot Tools on Linux

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Clones the Chromium depot_tools repository and adds it to the system's PATH for easy access to tools like git-cl.

```sh
git clone 'https://chromium.googlesource.com/chromium/tools/depot_tools.git'
export PATH="${PWD}/depot_tools:${PATH}"
```

--------------------------------

### Install Skia Build Dependencies

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Runs the Skia dependency installation script, which handles common prerequisites on Ubuntu systems. May require superuser privileges.

```sh
tools/install_dependencies.sh
```

--------------------------------

### Run Local Docserver in Preview Mode

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/dev/tools/markdown.md

Execute this command from within the local Git checkout of the Skia repository to start the documentation server. The '--preview' flag enables live reloading of file changes, providing quick feedback during development.

```Shell
docserver --preview
```

--------------------------------

### Example Usage of Google Mock Doctor with Make (Shell)

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gmock/docs/v1_6/FrequentlyAskedQuestions.md

A concrete example showing how to use the Google Mock Doctor with a 'make' command to analyze compiler errors from a test build.

```Shell
make my_test 2>&1 | gmd
```

--------------------------------

### Install and Use Google Mock Doctor Tool (Bash)

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gmock/docs/v1_6/FrequentlyAskedQuestions.md

Provides instructions for installing and using the `gmock_doctor.py` script, a tool designed to diagnose GCC compiler errors related to Google Mock. It illustrates how to create a shell alias for convenience and pipe build output to the tool for analysis.

```Bash
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
```

```Bash
<your-favorite-build-command> <your-test> 2>&1 | gmd
```

```Bash
make my_test 2>&1 | gmd
```

--------------------------------

### Run Local Docserver on Custom Port

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/dev/tools/markdown.md

This command starts the local documentation server with live preview enabled, similar to the default run command, but specifies a custom port (e.g., 8002) if the default port 8000 is unavailable on your machine.

```Shell
docserver --preview --port=:8002
```

--------------------------------

### Getting Started with Google Mock Includes

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/docs/ForDummies.md

To begin using Google Mock in a C++ project, simply include the necessary Google Test and Google Mock header files in your source file. These headers provide the core functionalities required for defining and using mock objects.

```C++
#include "gtest/gtest.h"
#include "gmock/gmock.h"
```

--------------------------------

### C++: Example of Deriving Google Test Fixtures

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/V1_5_FAQ.md

This C++ code demonstrates how to create a hierarchy of test fixtures in Google Test. A `BaseTest` class provides common setup, and `FooTest` derives from it, overriding `SetUp()` and `TearDown()` to add specific logic while ensuring the base fixture's methods are called. This pattern is useful for sharing test infrastructure across multiple test cases.

```cpp
// Defines a base test fixture.
class BaseTest : public ::testing::Test {
  protected:
   ...
};

// Derives a fixture FooTest from BaseTest.
class FooTest : public BaseTest {
  protected:
    virtual void SetUp() {
      BaseTest::SetUp();  // Sets up the base fixture first.
      ... additional set-up work ...
    }
    virtual void TearDown() {
      ... clean-up work for FooTest ...
      BaseTest::TearDown();  // Remember to tear down the base fixture
                             // after cleaning up FooTest!
    }
    ... functions and variables for FooTest ...
};

// Tests that use the fixture FooTest.
TEST_F(FooTest, Bar) { ... }
TEST_F(FooTest, Baz) { ... }

... additional fixtures derived from BaseTest ...
```

--------------------------------

### FFmpeg Installation: Configure, Build, and Install Commands

Source: https://github.com/weolar/miniblink49/blob/master/third_party/ffmpeg/INSTALL.md

This snippet provides the essential command-line steps to configure, compile, and install FFmpeg from its source code. It covers creating the configuration, building the binaries, and installing them to the system. It also notes the option for out-of-tree builds and how to view configuration help.

```bash
./configure
```

```bash
configure --help
```

```bash
make
```

```bash
make install
```

--------------------------------

### Install Miniblink49 Android Application

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/android.md

Installs the compiled Miniblink49 application onto the connected Android device. Ensure the application has been built prior to installation.

```shell
./platform_tools/android/bin/android_install_app
```

--------------------------------

### Build Turbolizer Project with npm

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/tools/turbolizer/README.md

These commands guide the user to the Turbolizer project directory and initiate its build process using npm. `npm i` installs all necessary dependencies, while `npm run-script build` compiles the source code, including TypeScript, into the designated build output directory.

```bash
cd tools/turbolizer
npm i
npm run-script build
```

--------------------------------

### Synchronize GClient repositories (initial checkout)

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

Executes `gclient sync` to perform the initial checkout of the configured repositories. This command will create the `src` directory and pull the main Git repository.

```Shell
$ gclient sync
```

--------------------------------

### Install libgif on Ubuntu

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Installs the libgif development package on Ubuntu and creates a symbolic link for compatibility.

```sh
sudo apt-get install libgif-dev
sudo apt-get install libgif4:i386
sudo ln -s /usr/lib/i386-linux-gnu/libgif.so.4 /usr/lib/i386-linux-gnu/libgif.so
```

--------------------------------

### Deriving Google Test Fixtures for Shared Setup/Teardown

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/V1_6_FAQ.md

This C++ example demonstrates how to create a hierarchy of Google Test fixtures to share common setup and teardown logic. A base fixture defines the shared functionality, and derived fixtures extend it, allowing specific tests to build upon the common foundation while adding their own unique setup or cleanup. It highlights the importance of calling the base class's SetUp/TearDown methods.

```C++
// Defines a base test fixture.
class BaseTest : public ::testing::Test {
  protected:
   ...
};

// Derives a fixture FooTest from BaseTest.
class FooTest : public BaseTest {
  protected:
    virtual void SetUp() {
      BaseTest::SetUp();  // Sets up the base fixture first.
      ... additional set-up work ...
    }
    virtual void TearDown() {
      ... clean-up work for FooTest ...
      BaseTest::TearDown();  // Remember to tear down the base fixture
                             // after cleaning up FooTest!
    }
    ... functions and variables for FooTest ...
};

// Tests that use the fixture FooTest.
TEST_F(FooTest, Bar) { ... }
TEST_F(FooTest, Baz) { ... }

... additional fixtures derived from BaseTest ...
```

--------------------------------

### Install FreeType and Fontconfig on Ubuntu

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Installs the FreeType and Fontconfig font engine development packages on Ubuntu using apt-get.

```sh
sudo apt-get install libfreetype6 libfreetype6-dev libfontconfig libfontconfig-dev
```

--------------------------------

### Build and Install wolfSSL Library

Source: https://github.com/weolar/miniblink49/blob/master/third_party/wolfssl/wolfcrypt/src/port/devcrypto/README.md

Compiles and installs the wolfSSL library after configuration, then runs the wolfcrypt test suite to verify functionality.

```bash
make
sudo make install
./wolfcrypt/test/testwolfcrypt
```

--------------------------------

### Build and Run Google Test Sample with Make

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gtest/README.md

These commands navigate to the Google Test `make` directory, build the library and a sample test using `make`, and then execute the `sample1_unittest`.

```Shell
cd ${GTEST_DIR}/make
make
./sample1_unittest
```

--------------------------------

### Google Test: Per-Test-Case Setup and Teardown Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/AdvancedGuide.md

This C++ example demonstrates how to implement per-test-case setup and teardown in Google Test using static `SetUpTestCase()` and `TearDownTestCase()` methods within a test fixture class. It shows how to manage a shared resource that is initialized once before the first test and cleaned up after the last test in the test case, improving efficiency for expensive resource setups.

```C++
class FooTest : public ::testing::Test {
 protected:
  // Per-test-case set-up.
  // Called before the first test in this test case.
  // Can be omitted if not needed.
  static void SetUpTestCase() {
    shared_resource_ = new ...;
  }

  // Per-test-case tear-down.
  // Called after the last test in this test case.
  // Can be omitted if not needed.
  static void TearDownTestCase() {
    delete shared_resource_;
    shared_resource_ = NULL;
  }

  // You can define per-test set-up and tear-down logic as usual.
  virtual void SetUp() { ... }
  virtual void TearDown() { ... }

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

T* FooTest::shared_resource_ = NULL;

TEST_F(FooTest, Test1) {
  ... you can refer to shared_resource here ...
}
TEST_F(FooTest, Test2) {
  ... you can refer to shared_resource here ...
}
```

--------------------------------

### Build and Run Google Mock Sample Test with Make

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gmock/README.md

These commands demonstrate how to use the provided Makefile in the `make/` directory to build the Google Mock library and a sample test. It changes to the `make` directory, runs `make`, and then executes the compiled sample test.

```bash
cd ${GMOCK_DIR}/make
make
./gmock_test
```

--------------------------------

### Google Test Per-Test-Case Setup and Teardown Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gtest/docs/AdvancedGuide.md

This C++ example demonstrates how to implement per-test-case setup and teardown in Google Test. By defining static void SetUpTestCase() and static void TearDownTestCase() methods within a ::testing::Test fixture, along with static member variables, resources can be initialized once before the first test and cleaned up after the last test in a test case, optimizing for expensive resource setup.

```C++
class FooTest : public ::testing::Test {
 protected:
  // Per-test-case set-up.
  // Called before the first test in this test case.
  // Can be omitted if not needed.
  static void SetUpTestCase() {
    shared_resource_ = new ...;
  }

  // Per-test-case tear-down.
  // Called after the last test in this test case.
  // Can be omitted if not needed.
  static void TearDownTestCase() {
    delete shared_resource_;
    shared_resource_ = NULL;
  }

  // You can define per-test set-up and tear-down logic as usual.
  virtual void SetUp() { ... }
  virtual void TearDown() { ... }

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

T* FooTest::shared_resource_ = NULL;

TEST_F(FooTest, Test1) {
  ... you can refer to shared_resource here ...
}
TEST_F(FooTest, Test2) {
  ... you can refer to shared_resource here ...
}
```

--------------------------------

### Configuring Source with Microsoft Visual C/C++

Source: https://github.com/weolar/miniblink49/blob/master/third_party/libxml/src/win32/Readme.txt

This example demonstrates configuring the build process to use Microsoft's compiler, install the library in c:\opt, use c:\opt\include and c:\opt\lib as additional search paths, and build executables with debug symbols. Note: Avoid path names containing spaces.

```Batch
cscript configure.js compiler=msvc prefix=c:\opt include=c:\opt\include lib=c:\opt\lib debug=yes
```

--------------------------------

### Google Test: Per-Test-Case Setup and Teardown Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gtest/docs/V1_6_AdvancedGuide.md

This C++ example demonstrates how to implement per-test-case setup and teardown in Google Test using static void SetUpTestCase() and static void TearDownTestCase() within a test fixture class. This approach allows tests to share expensive resources, which are initialized once before the first test and cleaned up after the last test in the test case. It includes a shared resource pointer and example test definitions.

```C++
class FooTest : public ::testing::Test {
 protected:
  // Per-test-case set-up.
  // Called before the first test in this test case.
  // Can be omitted if not needed.
  static void SetUpTestCase() {
    shared_resource_ = new ...;
  }

  // Per-test-case tear-down.
  // Called after the last test in this test case.
  // Can be omitted if not needed.
  static void TearDownTestCase() {
    delete shared_resource_;
    shared_resource_ = NULL;
  }

  // You can define per-test set-up and tear-down logic as usual.
  virtual void SetUp() { ... }
  virtual void TearDown() { ... }

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

T* FooTest::shared_resource_ = NULL;

TEST_F(FooTest, Test1) {
  ... you can refer to shared_resource here ...
}
TEST_F(FooTest, Test2) {
  ... you can refer to shared_resource here ...
}
```

--------------------------------

### Build and Run Performance Benchmarks (nanobench) via Command Line

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/windows.md

This sequence compiles the `nanobench` performance testbench in Release mode using `ninja`, as performance testing typically requires an optimized build. After successful compilation, the `nanobench` executable is run to collect performance metrics.

```Shell
ninja -C out\Release nanobench
out\Release\nanobench
```

--------------------------------

### Build and Run Google Test Sample with Make

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/README.md

Navigates to the Google Test `make` directory, builds the Google Test library and a sample test using GNU Make, and then executes the compiled sample unit test. This demonstrates a quick build and run process for verification.

```Shell
cd ${GTEST_DIR}/make
make
./sample1_unittest
```

--------------------------------

### Configure GClient for a new repository

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

Uses the `gclient config` command to create the initial `.gclient` configuration file, linking it to a remote Git repository. The `--name` flag specifies the local directory name for the checkout.

```Shell
$ gclient config --name=src https://bitbucket.org/dj2/usingskia.git
```

--------------------------------

### Defining multiple actions for a single expectation in Google Mock

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/docs/v1_6/FrequentlyAskedQuestions.md

This example demonstrates a concise way to specify multiple sequential actions for a single `EXPECT_CALL` in Google Mock. This approach ensures that the actions (e.g., different return values) are applied in the order they are listed for subsequent calls to the mock function, simplifying the test setup for repeated calls.

```C++
EXPECT_CALL(foo, Bar())
    .WillOnce(Return(1))
    .WillOnce(Return(2))
    .RetiresOnSaturation();
```

--------------------------------

### Correct Naming for Google Test SetUp/TearDown Functions

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/V1_6_FAQ.md

Highlights common case-sensitivity issues with Google Test fixture setup functions, specifically `SetUp()` and `SetUpTestCase()`. Incorrect capitalization (e.g., `Setup()`) will prevent these functions from being called.

--------------------------------

### Build Google Mock and Sample Test with GNU Make

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/README.md

These commands show how to use the provided Makefile in the 'make/' directory to build the Google Mock library and a sample test executable on systems with GNU Make. It demonstrates changing directory, running make, and executing the test.

```bash
cd ${GMOCK_DIR}/make
make
./gmock_test
```

--------------------------------

### GYP Configuration File for Skia Project

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

This GYP file defines the build configuration for the 'using_skia' executable. It specifies build targets, debug and release configurations, dependencies on the Skia library, necessary include directories, source files, and linker/compiler flags.

```GYP
{
  'targets': [
    {
      'configurations': {
        'Debug': { },
        'Release': { }
      },
      'target_name': 'using_skia',
      'type': 'executable',
      'dependencies': [
        'third_party/skia/gyp/skia_lib.gyp:skia_lib'
      ],
      'include_dirs': [
        'third_party/skia/include/config',
        'third_party/skia/include/core',
      ],
      'sources': [
        'app/main.cpp'
      ],
      'ldflags': [
        '-lskia', '-stdlib=libc++', '-std=c++11'
      ],
      'cflags': [
        '-Werror', '-W', '-Wall', '-Wextra', '-Wno-unused-parameter', '-g', '-O0'
      ]
    }
  ]
}
```

--------------------------------

### Google Test: Per-Test-Case Setup and Teardown Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gtest/docs/V1_5_AdvancedGuide.md

This C++ example demonstrates how to implement per-test-case setup and teardown logic within a Google Test fixture. By defining static SetUpTestCase() and TearDownTestCase() methods, shared resources can be initialized once before the first test and cleaned up after the last test in a test case, optimizing performance for expensive resource allocations. Tests can then access shared_resource_.

```C++
class FooTest : public ::testing::Test {
 protected:
  // Per-test-case set-up.
  // Called before the first test in this test case.
  // Can be omitted if not needed.
  static void SetUpTestCase() {
    shared_resource_ = new ...;
  }

  // Per-test-case tear-down.
  // Called after the last test in this test case.
  // Can be omitted if not needed.
  static void TearDownTestCase() {
    delete shared_resource_;
    shared_resource_ = NULL;
  }

  // You can define per-test set-up and tear-down logic as usual.
  virtual void SetUp() { ... }
  virtual void TearDown() { ... }

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

T* FooTest::shared_resource_ = NULL;

TEST_F(FooTest, Test1) {
  ... you can refer to shared_resource here ...
}
TEST_F(FooTest, Test2) {
  ... you can refer to shared_resource here ...
}
```

--------------------------------

### Initial GClient Configuration File (.gclient)

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

The `.gclient` file generated by `gclient config`, defining the main source repository and its properties. It specifies the repository URL, local name, and the DEPS file to be used.

```GClientConfig
solutions = [
  { "name"        : "src",
    "url"         : "https://bitbucket.org/dj2/usingskia.git",
    "deps_file"   : "DEPS",
    "managed"     : True,
    "custom_deps" : {
    },
    "safesync_url": "",
  },
]
cache_dir = None
```

--------------------------------

### Build and Run Google Test Sample via Makefile

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gtest/README.md

Navigates to the Google Test make directory, then executes the make command to build the Google Test library and a sample test. Finally, it runs the compiled sample1_unittest executable to verify the build.

```Shell
cd ${GTEST_DIR}/make
make
./sample1_unittest
```

--------------------------------

### Example: Diagnose Make Errors with Google Mock Doctor

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/docs/v1_7/FrequentlyAskedQuestions.md

A concrete example showing how to use the Google Mock Doctor with the `make` build command. The output of `make my_test` is redirected to `gmd` for error diagnosis.

```Shell
make my_test 2>&1 | gmd
```

--------------------------------

### Define Installation Rules for Google Mock

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/CMakeLists.txt

Specifies the installation rules for Google Mock. It installs the `gmock` and `gmock_main` libraries to the `lib` destination and the `gmock` header directory to the `include` destination, making them available for system-wide use or other projects.

```CMake
install(TARGETS gmock gmock_main
  DESTINATION lib)
install(DIRECTORY ${gmock_SOURCE_DIR}/include/gmock
  DESTINATION include)
```

--------------------------------

### Example: Using Google Mock Doctor with Make

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gmock/docs/v1_7/FrequentlyAskedQuestions.md

A practical example showing how to use the Google Mock Doctor tool with a `make` command. The output of `make my_test` is redirected to `gmd` for error analysis.

```Shell
make my_test 2>&1 | gmd
```

--------------------------------

### Example Google Test main() Function and Test Fixture

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gtest/docs/Primer.md

This C++ code provides a complete boilerplate for a Google Test executable. It demonstrates how to include necessary headers, define a test fixture class (FooTest) inheriting from ::testing::Test, and implement SetUp() and TearDown() methods for test setup and cleanup. It also shows examples of TEST_F macros for defining individual tests within the fixture and the standard main() function structure for initializing Google Test and executing all registered tests.

```C++
#include "this/package/foo.h"
#include "gtest/gtest.h"

namespace {

// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
 protected:
  // You can remove any or all of the following functions if its body
  // is empty.

  FooTest() {
    // You can do set-up work for each test here.
  }

  virtual ~FooTest() {
    // You can do clean-up work that doesn't throw exceptions here.
  }

  // If the constructor and destructor are not enough for setting up
  // and cleaning up each test, you can define the following methods:

  virtual void SetUp() {
    // Code here will be called immediately after the constructor (right
    // before each test).
  }

  virtual void TearDown() {
    // Code here will be called immediately after each test (right
    // before the destructor).
  }

  // Objects declared here can be used by all tests in the test case for Foo.
};

// Tests that the Foo::Bar() method does Abc.
TEST_F(FooTest, MethodBarDoesAbc) {
  const string input_filepath = "this/package/testdata/myinputfile.dat";
  const string output_filepath = "this/package/testdata/myoutputfile.dat";
  Foo f;
  EXPECT_EQ(0, f.Bar(input_filepath, output_filepath));
}

// Tests that Foo does Xyz.
TEST_F(FooTest, DoesXyz) {
  // Exercises the Xyz feature of Foo.
}

}  // namespace

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}
```

--------------------------------

### Example FIFO Queue Class Interface for Testing (C++)

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gtest/docs/V1_6_Primer.md

This code defines a generic FIFO queue class named `Queue`, intended as an example for demonstrating Google Test fixtures. It provides basic methods such as `Enqueue` to add elements, `Dequeue` to remove elements (returning `NULL` if empty), and `size` to get the current count of elements. This interface serves as the subject under test for the subsequent fixture examples.

```C++
template <typename E> // E is the element type.
class Queue {
 public:
  Queue();
  void Enqueue(const E& element);
  E* Dequeue(); // Returns NULL if the queue is empty.
  size_t size() const;
  ...
};
```

--------------------------------

### Build and Run Skia SampleApp

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Compiles the 'SampleApp' target using 'make' with multiple threads and then executes the graphical application from the Debug build directory.

```sh
make -j SampleApp
out/Debug/SampleApp
```

--------------------------------

### Install Google Mock Doctor Alias

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/docs/v1_7/FrequentlyAskedQuestions.md

This command creates a shell alias `gmd` for the Google Mock Doctor tool, making it easier to invoke from the command line. Users should replace `<path to googlemock>` with the actual path to their Google Mock installation.

```Shell
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
```

--------------------------------

### Python Wrapper Script for Running GYP

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

This Python script serves as a wrapper to invoke GYP, configuring it to generate Ninja build files. It sets up necessary environment variables and arguments, including paths to Skia's common GYP file and the project's main GYP configuration.

```Python
#!/usr/bin/python
import os
import sys

script_dir = os.path.dirname(__file__)
using_skia_src = os.path.abspath(os.path.join(script_dir, os.pardir))

sys.path.insert(0, os.path.join(using_skia_src, 'tools', 'gyp', 'pylib'))
import gyp

if __name__ == '__main__':
  args = sys.argv[1:]

  if not os.environ.get('GYP_GENERATORS'):
    os.environ['GYP_GENERATORS'] = 'ninja'

  args.append('--check')
  args.append('-I%s/third_party/skia/gyp/common.gypi' % using_skia_src)

  args.append(os.path.join(script_dir, '..', 'using_skia.gyp'))

  print 'Updating projects from gyp files...'
  sys.stdout.flush()

  sys.exit(gyp.main(args))
```

--------------------------------

### Install All Components

Source: https://github.com/weolar/miniblink49/blob/master/node/openssl/openssl/Makefile.org

A meta-target that orchestrates the full installation process. It ensures all components are built (`all`), documentation is installed (`install_docs`), and software binaries and libraries are installed (`install_sw`).

```Makefile
install: all install_docs install_sw
```

--------------------------------

### C++ Google Test: Per-Test-Case Setup and Teardown Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/V1_5_AdvancedGuide.md

Demonstrates how to implement per-test-case setup and teardown in Google Test using static SetUpTestCase() and static TearDownTestCase() methods within a test fixture class. This allows sharing expensive resources across tests in the same test case.

```C++
class FooTest : public ::testing::Test {
 protected:
  // Per-test-case set-up.
  // Called before the first test in this test case.
  // Can be omitted if not needed.
  static void SetUpTestCase() {
    shared_resource_ = new ...;
  }

  // Per-test-case tear-down.
  // Called after the last test in this test case.
  // Can be omitted if not needed.
  static void TearDownTestCase() {
    delete shared_resource_;
    shared_resource_ = NULL;
  }

  // You can define per-test set-up and tear-down logic as usual.
  virtual void SetUp() { ... }
  virtual void TearDown() { ... }

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

T* FooTest::shared_resource_ = NULL;

TEST_F(FooTest, Test1) {
  ... you can refer to shared_resource here ...
}
TEST_F(FooTest, Test2) {
  ... you can refer to shared_resource here ...
}
```

--------------------------------

### Modified GClient configuration to include Skia as a solution

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

Updated `.gclient` file with a second solution entry for Skia, ensuring its own dependencies are also pulled in by `gclient`. This is necessary because Skia itself has a DEPS file that needs to be processed.

```GClientConfig
solutions = [
  { "name"        : "src",
    "url"         : "https://bitbucket.org/dj2/usingskia.git",
    "deps_file"   : "DEPS",
    "managed"     : True,
    "custom_deps" : {
    },
    "safesync_url": "",
  },
  { "name"        : "src/third_party/skia",
    "url"         : "http://skia.googlecode.com/skia.git@a6a8f00a3977e71dbce9da50a32c5e9a51c49285",
    "deps_file"   : "DEPS",
    "managed"     : True,
    "custom_deps" : {
    },
    "safesync_url": "",
  },
]
cache_dir = None
```

--------------------------------

### Deriving Google Test Fixtures for Shared Setup and Teardown

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gtest/docs/V1_5_FAQ.md

This C++ example illustrates how to define a base test fixture and derive a new fixture from it in Google Test. It demonstrates the correct way to override `SetUp()` and `TearDown()` methods in the derived fixture, ensuring that the base fixture's setup and teardown logic is properly invoked. This pattern is useful for sharing common initialization and cleanup routines across multiple test cases.

```C++
// Defines a base test fixture.
class BaseTest : public ::testing::Test {
  protected:
   ...
};

// Derives a fixture FooTest from BaseTest.
class FooTest : public BaseTest {
  protected:
    virtual void SetUp() {
      BaseTest::SetUp();  // Sets up the base fixture first.
      ... additional set-up work ...
    }
    virtual void TearDown() {
      ... clean-up work for FooTest ...
      BaseTest::TearDown();  // Remember to tear down the base fixture
                             // after cleaning up FooTest!
    }
    ... functions and variables for FooTest ...
};

// Tests that use the fixture FooTest.
TEST_F(FooTest, Bar) { ... }
TEST_F(FooTest, Baz) { ... }

... additional fixtures derived from BaseTest ...
```

--------------------------------

### Run SampleApp with External Resources

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/sampleapp.md

Execute the SampleApp application, specifying the path to external resources required by some slides. Replace <skia-path> with the actual installation directory of Skia.

```Shell
<skia-path>/out/Release/SampleApp --resourcePath <skia-path>/resources
```

--------------------------------

### Install Google Mock Libraries and Headers

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gmock/CMakeLists.txt

This snippet defines the installation rules for the compiled `gmock` and `gmock_main` libraries, ensuring they are placed in the standard `lib` destination. It also installs the Google Mock public header directory (`include/gmock`) to the `include` destination, making it accessible for projects linking against Google Mock.

```CMake
install(TARGETS gmock gmock_main
  DESTINATION lib)
install(DIRECTORY ${gmock_SOURCE_DIR}/include/gmock
  DESTINATION include)
```

--------------------------------

### Example Usage of Google Mock Doctor (Shell)

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gmock/docs/v1_5/FrequentlyAskedQuestions.md

This is a concrete example of using the `gmd` alias with a `make` command. It shows how to redirect the standard error and standard output of `make my_test` to the `gmd` script for error analysis. This provides a practical illustration of the previous usage pattern.

```Shell
make my_test 2>&1 | gmd
```

--------------------------------

### Makefile Target: Install OpenSSL Man Pages

Source: https://github.com/weolar/miniblink49/blob/master/node/openssl/openssl/Makefile.org

This `install_docs` Makefile target orchestrates the complete installation of OpenSSL's manual pages. It first creates the necessary man page directories. It then dynamically determines the `pod2man` utility path and handles platform-specific file casing. The target iterates through `.pod` files in application, crypto, and SSL documentation directories, converting each POD file into a man page using `pod2man` and installing it. Finally, it generates cross-references for the installed man pages using `extract-names.pl` and `point.sh` to ensure proper linking within the man page system.

```Makefile
install_docs:
	@$(PERL) $(TOP)/util/mkdir-p.pl \
		$(INSTALL_PREFIX)$(MANDIR)/man1 \
		$(INSTALL_PREFIX)$(MANDIR)/man3 \
		$(INSTALL_PREFIX)$(MANDIR)/man5 \
		$(INSTALL_PREFIX)$(MANDIR)/man7
	@pod2man="`cd ./util; ./pod2mantest $(PERL)`"; \
	here="`pwd`"; \
	filecase=; \
	case "$(PLATFORM)" in DJGPP|Cygwin*|mingw*|darwin*-*-cc) \
		filecase=-i; \
	esac; \
	set -e; for i in doc/apps/*.pod; do \
		fn=`basename $$i .pod`; \
		sec=`$(PERL) util/extract-section.pl 1 < $$i`; \
		echo "installing man$$sec/$$fn.$${sec}$(MANSUFFIX)"; \
		(cd `$(PERL) util/dirname.pl $$i`; \
		sh -c "$$pod2man \
			--section=$$sec --center=OpenSSL \
			--release=$(VERSION) `basename $$i`") \
			>  $(INSTALL_PREFIX)$(MANDIR)/man$$sec/$$fn.$${sec}$(MANSUFFIX); \
		$(PERL) util/extract-names.pl < $$i | \
			(grep -v $$filecase "^$$fn\\$$"; true) | \
			(grep -v "[\t]"; true) | \
			(cd $(INSTALL_PREFIX)$(MANDIR)/man$$sec/; \
			 while read n; do \
				PLATFORM=$(PLATFORM) $$here/util/point.sh $$fn.$${sec}$(MANSUFFIX) "$$n".$${sec}$(MANSUFFIX); \
			 done); \
		done; \
	set -e; for i in doc/crypto/*.pod doc/ssl/*.pod; do \
		fn=`basename $$i .pod`; \
		sec=`$(PERL) util/extract-section.pl 3 < $$i`; \
		echo "installing man$$sec/$$fn.$${sec}$(MANSUFFIX)"; \
		(cd `$(PERL) util/dirname.pl $$i`; \
		sh -c "$$pod2man \
			--section=$$sec --center=OpenSSL \
			--release=$(VERSION) `basename $$i`") \
			>  $(INSTALL_PREFIX)$(MANDIR)/man$$sec/$$fn.$${sec}$(MANSUFFIX); \
		$(PERL) util/extract-names.pl < $$i | \
			(grep -v $$filecase "^$$fn\\$$"; true) | \
			(grep -v "[\t]"; true) | \
			(cd $(INSTALL_PREFIX)$(MANDIR)/man$$sec/; \
			 while read n; do \
				PLATFORM=$(PLATFORM) $$here/util/point.sh $$fn.$${sec}$(MANSUFFIX) "$$n".$${sec}$(MANSUFFIX); \
			 done); \
		done
```

--------------------------------

### FFmpeg Makefile Targets

Source: https://github.com/weolar/miniblink49/blob/master/third_party/ffmpeg/doc/build_system.txt

Lists and describes the various build targets available in the FFmpeg custom Makefile, including default builds, testing, installation, and examples.

```APIDOC
all: Default target, builds all the libraries and the executables.
fate: Run the fate test suite, note that you must have installed it.
fate-list: List all fate/regression test targets.
install: Install headers, libraries and programs.
examples: Build all examples located in doc/examples.
libavformat/output-example: Build the libavformat basic example.
libavcodec/api-example: Build the libavcodec basic example.
libswscale/swscale-test: Build the swscale self-test (useful also as an example).
config: Reconfigure the project with the current configuration.
```

--------------------------------

### Build and Run Skia Nanobench Performance Tests

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/linux.md

Compiles the 'nanobench' performance test target in Release mode using Ninja and then executes it, with an optional path for SKP files.

```sh
ninja -C out/Release nanobench
out/Release/nanobench [ --skps path/to/*.skp ]
```

--------------------------------

### Google Test ASSERT_DEATH Statement Argument Examples

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/V1_6_FAQ.md

Demonstrates various forms of the _statement_ argument that can be used with Google Test's ASSERT_DEATH macro, including simple function calls, complex expressions, usage within loops, and compound statements. These examples illustrate the flexibility of death assertions in C++ tests.

```C++
// A death test can be a simple function call.
TEST(MyDeathTest, FunctionCall) {
  ASSERT_DEATH(Xyz(5), "Xyz failed");
}
```

```C++
// Or a complex expression that references variables and functions.
TEST(MyDeathTest, ComplexExpression) {
  const bool c = Condition();
  ASSERT_DEATH((c ? Func1(0) : object2.Method("test")),
               "(Func1|Method) failed");
}
```

```C++
// Death assertions can be used any where in a function. In
// particular, they can be inside a loop.
TEST(MyDeathTest, InsideLoop) {
  // Verifies that Foo(0), Foo(1), ..., and Foo(4) all die.
  for (int i = 0; i < 5; i++) {
    EXPECT_DEATH_M(Foo(i), "Foo has \\d+ errors",
                   ::testing::Message() << "where i is " << i);
  }
}
```

```C++
// A death assertion can contain a compound statement.
TEST(MyDeathTest, CompoundStatement) {
  // Verifies that at lease one of Bar(0), Bar(1), ..., and
  // Bar(4) dies.
  ASSERT_DEATH({
    for (int i = 0; i < 5; i++) {
      Bar(i);
    }
  },
  "Bar has \\d+ errors");}
```

--------------------------------

### Google Test: Defining a Fixture Class for Queue Testing

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gtest/docs/V1_7_Primer.md

Example of a test fixture class `QueueTest` derived from `::testing::Test`. It demonstrates the use of the `protected` access specifier and the `SetUp()` virtual method to initialize multiple `Queue` objects (`q0_`, `q1_`, `q2_`) with predefined data before each test run. `TearDown()` is commented out as it's not needed for this example.

```C++
class QueueTest : public ::testing::Test {
 protected:
  virtual void SetUp() {
    q1_.Enqueue(1);
    q2_.Enqueue(2);
    q2_.Enqueue(3);
  }

  // virtual void TearDown() {}

  Queue<int> q0_;
  Queue<int> q1_;
  Queue<int> q2_;
};
```

--------------------------------

### Build and Run Tests for Google Mock

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gmock/README.md

Standard GNU-style build commands to compile Google Mock and then execute its comprehensive test suite to verify that all changes work as intended and existing functionality is preserved.

```Shell
make        # Standard makefile following GNU conventions
make check  # Builds and runs all tests - all should pass.
```

--------------------------------

### Executing the GYP Wrapper Script

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

This shell command executes the Python wrapper script 'gyp_using_skia'. Running this script generates the necessary Ninja build files based on the project's GYP configuration, preparing the project for compilation.

```Shell
./build/gyp_using_skia
```

--------------------------------

### Set ANDROID_SDK_ROOT Environment Variable

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/android.md

Defines the `ANDROID_SDK_ROOT` environment variable, pointing to the installation directory of the Android SDK. This variable is crucial for the build system to locate SDK tools.

```bash
export ANDROID_SDK_ROOT=/path/to/android/sdk
```

--------------------------------

### Sample C++ Application Using Skia

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/sample/building.md

A basic C++ application demonstrating fundamental Skia usage. It initializes an SkPaint object, sets its color, converts it to an SkString, and prints the string to standard output, serving as a verification of correct linking with the Skia library.

```C++
#include "SkPaint.h"
#include "SkString.h"

int main(int argc, char** argv) {
  SkPaint paint;
  paint.setColor(SK_ColorRED);

  SkString* str = new SkString();
  paint.toString(str);

  fprintf(stdout, "%s\n", str->c_str());

  return 0;
}
```

--------------------------------

### Google Test Per-Test-Case Setup and Teardown Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gtest/docs/V1_6_AdvancedGuide.md

This C++ snippet demonstrates how to implement per-test-case setup and tear-down within a Google Test fixture class. It uses static member variables for shared resources and defines static SetUpTestCase() and TearDownTestCase() methods to manage their lifecycle before the first test and after the last test in the test case, respectively.

```C++
class FooTest : public ::testing::Test {
 protected:
  // Per-test-case set-up.
  // Called before the first test in this test case.
  // Can be omitted if not needed.
  static void SetUpTestCase() {
    shared_resource_ = new ...;
  }

  // Per-test-case tear-down.
  // Called after the last test in this test case.
  // Can be omitted if not needed.
  static void TearDownTestCase() {
    delete shared_resource_;
    shared_resource_ = NULL;
  }

  // You can define per-test set-up and tear-down logic as usual.
  virtual void SetUp() { ... }
  virtual void TearDown() { ... }

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

T* FooTest::shared_resource_ = NULL;

TEST_F(FooTest, Test1) {
  ... you can refer to shared_resource here ...
}
TEST_F(FooTest, Test2) {
  ... you can refer to shared_resource here ...
}
```

--------------------------------

### Deriving Google Test Fixtures for Shared Logic

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gtest/docs/V1_7_FAQ.md

This C++ example demonstrates how to create a base test fixture and derive other fixtures from it to share common setup and teardown logic. It illustrates the use of `SetUp()` and `TearDown()` methods to manage resources, ensuring the base fixture's setup/teardown is called appropriately before and after tests.

```C++
// Defines a base test fixture.
class BaseTest : public ::testing::Test {
  protected:
   ...
};

// Derives a fixture FooTest from BaseTest.
class FooTest : public BaseTest {
  protected:
    virtual void SetUp() {
      BaseTest::SetUp();  // Sets up the base fixture first.
      ... additional set-up work ...
    }
    virtual void TearDown() {
      ... clean-up work for FooTest ...
      BaseTest::TearDown();  // Remember to tear down the base fixture
                             // after cleaning up FooTest!
    }
    ... functions and variables for FooTest ...
};

// Tests that use the fixture FooTest.
TEST_F(FooTest, Bar) { ... }
TEST_F(FooTest, Baz) { ... }

... additional fixtures derived from BaseTest ...
```

--------------------------------

### Prepare Google Mock Autotools Build System

Source: https://github.com/weolar/miniblink49/blob/master/v8_6_7/testing/gmock/README.md

This snippet shows the commands to prepare the GNU Autotools build system for Google Mock on Unix-like systems, enabling the generation of build configuration files.

```bash
cd googlemock
autoreconf -fvi
```

--------------------------------

### Install Google Mock Doctor Alias (Shell)

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gmock/docs/v1_5/FrequentlyAskedQuestions.md

This command defines a shell alias `gmd` for the Google Mock Doctor tool. This tool helps in diagnosing confusing GCC template error messages related to Google Mock. Users should replace `<path to googlemock>` with the actual path to their Google Mock installation.

```Shell
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
```

--------------------------------

### Bash Function to Build SampleApp for iOS with Xcode 3

Source: https://github.com/weolar/miniblink49/blob/master/third_party/skia/site/user/quick/ios.md

This bash function, `buildSampleApp`, automates the configuration of GYP_DEFINES and execution of `gyp_skia` for building SampleApp with Xcode 3. It supports building for iOS simulator ('sim'), iPhone device ('iphone'), or Mac ('mac'), adjusting SDK paths and versions accordingly. It also calls `setiossdk` to configure the Xcode project.

```Bash
function buildSampleApp()
{
  sdkVersion="4.3"
  if [[ "$1" == "sim" ]] ; then
    export GYP_DEFINES="skia_os='ios' skia_arch_type='x86' \
          ios_sdk_dir='/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator' \
          ios_sdk_version='$sdkVersion'"
  elif [[ "$1" == "iphone" ]] ; then
    export GYP_DEFINES="skia_os='ios' skia_arch_type='arm' armv7='1' arm_neon='0' \
          ios_sdk_dir='/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS' \
          ios_sdk_version='$sdkVersion'"
  elif [[ "$1" == "mac" ]] ; then
    export GYP_DEFINES=""
  else
    echo "buildSampleApp  expects 'sim', 'iphone', or 'mac'"
  fi
  if [[ "$1" == "sim" ]] || [[ "$1" == "iphone" ]] || [[ "$1" == "mac" ]] ; then
    save=`pwd`
    cd /chrome/nih/skia/trunk
    echo "$GYP_DEFINES ./gyp_skia gyp/SampleApp.gyp"
    ./gyp_skia gyp/SampleApp.gyp
    cd $save
  fi
  if [[ "$1" == "sim" ]] ; then
    setiossdk iphonesimulator$sdkVersion
  elif [[ "$1" == "iphone" ]] ; then
    setiossdk iphoneos$sdkVersion
  fi
}
```

--------------------------------

### Install and Use Google Mock Doctor for Error Diagnosis

Source: https://github.com/weolar/miniblink49/blob/master/v8_7_5/testing/gmock/docs/FrequentlyAskedQuestions.md

This section provides instructions on how to "install" and use the `gmock_doctor.py` tool. This utility helps in diagnosing confusing template compiler errors from GCC by scanning stdin for error messages and providing diagnoses. It's a valuable tool for troubleshooting complex compilation issues.

```Bash
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
```

```Bash
<your-favorite-build-command> <your-test> 2>&1 | gmd
```

```Bash
make my_test 2>&1 | gmd
```

--------------------------------

### Google Test Underscore Naming Conflict Example

Source: https://github.com/weolar/miniblink49/blob/master/v8_5_7/testing/gtest/docs/V1_6_FAQ.md

Demonstrates how two different `TEST` macros can generate the same internal class name when underscores are used, leading to conflicts.

```C++
TEST(Time, Flies_Like_An_Arrow) { ... }
TEST(Time_Flies, Like_An_Arrow) { ... }
```