reveal.js

GUnit.GMock allows you to use GoogleMock features without manually writing and maintaining mock classes. It works by wrapping an abstract interface in a GMock<T> template.

Key Features

• Automatic Mocking: No need to define MOCK_METHOD for every interface.
• Compatibility: Works alongside traditional GoogleMock mocks.
• Mock Types: Supports NaggyGMock (default), StrictGMock, and NiceGMock.
• Syntax Note: When using EXPECT_CALL or ON_CALL with GUnit.GMock, you must wrap the function name in additional parentheses to handle the macro expansion correctly.

Supported Macros

• EXPECT_CALL(mock, (function)(args))
• ON_CALL(mock, (function)(args))
• EXPECT_INVOKE(mock, function, args) (Universal syntax that works with both GoogleMock and GUnit.GMock)

// GoogleMock style
EXPECT_CALL(mock, function(42)).WillOnce(Return(true));

// GUnit.GMock style (requires extra parens)
EXPECT_CALL(mock, (function)(42)).WillOnce(Return(true));

// Universal GUnit.GMock style
EXPECT_INVOKE(mock, function, 42); // Works for both

// ON_CALL style
ON_CALL(mock, (function)()).WillByDefault(Return(true));

The speaker notes plugin allows you to present per-slide notes in a separate browser window (opened via the »S« key).

Defining Notes:

1. HTML <aside> element: Append an <aside class="notes"> inside a <section>. You can use the data-markdown attribute on the aside to write notes in Markdown.
2. data-notes attribute: Add notes directly to the section: <section data-notes="Your notes here"></section>.
3. Markdown delimiter: If using the external Markdown plugin, use a special delimiter (e.g., Note:) defined in your data-separator-notes configuration.

Configuration & Sharing:

• showNotes: Set to true in the configuration to make notes visible to everyone at the bottom of the presentation. This also includes them in PDF exports.
• showNotes: "separate-page": When exporting to PDF, this prints notes on a separate page following the slide instead of in a semi-transparent box on top of the slide.
• Pacing Timer: To enable a pacing timer in the speaker view, configure the defaultTiming parameter in the Reveal configuration block (value in seconds). You can also set per-slide timing using the data-timing attribute on a <section>.

<section>
	<h2>Some Slide</h2>

	<aside class="notes">
		Oh hey, these are some notes. They'll be hidden in your presentation, but you can see them if you open the speaker notes window (hit »S« on your keyboard).
	</aside>
</section>

If you need to test private or protected members of a class using GUnit, you can use the friend keyword to grant the test class access. There are three primary ways to achieve this:

1. Using the class name directly: If your test is defined as GTEST(SomeTest), you can declare the test as a friend using the template syntax friend struct GTEST<SomeTest, testing::detail::string<> >;.
2. Using string literals (cumbersome): You can declare friendship using the string-based test name, but this requires manually expanding the string into a testing::detail::string type.
3. Using the FRIEND_GTEST macro: This is the recommended way to grant friendship using a string name. It uses GUnit's internal preprocessor magic to map the string name to the correct GTEST type.

Note: Avoid the practice of using #define private public before including production headers, as it is considered bad practice.

#include <GUnit/Detail/Preprocessor.h>
#include <GUnit/Detail/StringUtils.h>

#define FRIEND_GTEST(name) \
struct __GUNIT_CAT(GTEST_STRING_, __LINE__) { static constexpr const char* chrs = #name; }; \
friend struct GTEST<decltype(::make_string<__GUNIT_CAT(GTEST_STRING_, __LINE__), sizeof(#name)>::type()), ::string<>>;

class SomeClass {
    FRIEND_GTEST("SomeTest")
};

GTEST("SomeTest") { ... }

Instead of defining multiple TEST_F macros, you can use a single GTEST block with a fixture and define multiple sub-tests using the SHOULD macro. This is particularly useful when testing multiple scenarios for the same System Under Test (SUT) and Mocks.

Note: When using SHOULD, the fixture's SetUp() and TearDown() methods are called separately for each SHOULD block.

Filtering sub-tests: To run a specific SHOULD test case via the command line, use a colon (:) in the --gtest_filter flag.

• FooTest*:Do A : Runs FooTest where the SHOULD clause matches "Do A".
• FooTest*:Do* : Runs all SHOULD clauses in FooTest starting with "Do".
• FooTest.:Do* : Alternative syntax for matching SHOULD clauses.

struct FooTest : testing::Test {
  void SetUp() override { /* setup logic */ }
  void TearDown() override { /* teardown logic */ }
};

GTEST(FooTest) {
  // This is sub-test 1
  SHOULD("call foo") {
    // ...
  }

  // This is sub-test 2
  SHOULD("call foo and return 0") {
    // ...
  }
}