Persönlicher Spickzettel von Google Test / Mock

Überblick

Letztes Mal habe ich eine Google Mock-Umgebung für C erstellt, die ich für meine Arbeit verwende, und mich daher entschlossen, etwas mehr zu studieren. Es gibt so etwas wie "Google C ++ Mocking Framework Cheet Sheet", aber es ist schwer zu verstehen und fällt mir nicht ein, wenn ich es mir nur ansehe. Beim Lesen habe ich beschlossen, mir so etwas wie einen Spickzettel zu machen. Wir werden es einzeln aktualisieren.

Zusammenfassung der Makros

TEST(), TEST_F(), TEST_P() https://github.com/google/googletest/blob/master/googletest/docs/primer.md#simple-tests

TEST(TestSuiteName, TestName) {
  ... test body ...
}

• Geben Sie die Haupt- und Nebennamen des Testfalls ein.

• Es scheint nicht gut zu sein, Unterstriche zu verwenden. Ich kann etwas benutzen.
• Wenn mehrere Tests durchgeführt werden, tritt ein Erstellungsfehler auf, sofern die Kombination aus dem Hauptelementnamen und dem Nebenelementnamen nicht dupliziert wird.

• In TEST_F ist das erste Argument der Klassenname, der als Testgerät definiert ist.
• TEST_P ist eine fortschrittliche Technik, mit der Sie einen Test mehrmals mit verschiedenen Parametern ausführen können.
  • http://opencv.jp/googletestdocs/advancedguide.html#adv-how-to-write-value-parameterized-tests

ASSERT_EQ, EXPECT_EQ http://opencv.jp/googletestdocs/primer.html#primer-binary-comparison

• Das erste Argument ist der erwartete Wert und das zweite Argument ist der tatsächliche Wert. Es kann verwendet werden, um den Rückgabewert zu überprüfen, wenn die Funktion ausgeführt wird.
• Es gibt auch Verwandte wie "EXPECT_NE" und "EXPECT_TRUE"
• ASSERT_ * beendet den Test sofort, wenn die Situation nicht Ihren Erwartungen entspricht, und EXPECT_ * wird fortgesetzt.

MOCK_METHOD*, MOCK_CONST_METHOD*

• Wird verwendet, um Scheinmethoden zu definieren. Der * Teil ist die Anzahl der Argumente.
• Wenn die Anzahl der Argumente 10 überschreitet, stirbt es. Für unglückliche Projekte mit Funktionen mit vielen Argumenten sind Maßnahmen erforderlich.

EXPECT_CALL

• Erklärt, dass die Methoden von Mock aufgerufen werden. Das erste Argument ist eine Instanz der Mocked-Klasse (tatsächlich, kein Zeiger), und das zweite Argument ist der Methodenname.
• Der Methodenname gibt eine Reihe von Argumenten an. Wenn ein Aufruf erfolgt, der nicht mit den Argumenten übereinstimmt, bedeutet dies, dass er nicht aufgerufen wurde.
• Sie können die Argumentprüfung unter Verwendung der später beschriebenen :: testing :: _ weglassen.
• Wenn es sich nicht um NiceMock handelt, wird ein nicht erwarteter Mock-Methodenaufruf gewarnt. (Der Test wird erfolgreich sein). Der Test schlägt fehl, wenn keine ERWARTETEN Anrufe vorliegen.

::testing::_ https://github.com/google/googletest/blob/master/googlemock/docs/cheat_sheet.md#wildcard

• Die genaue Definition ist Matchers Platzhalter, der, wie der Name schon sagt, beliebige Argumente zulässt.
• Auf der obigen Seite befinden sich verschiedene Matcher. Wenn Sie sich diese ansehen, können Sie möglicherweise etwas verwenden.
• Es scheint [logische Berechnung] zu geben (http://opencv.jp/googlemockdocs/cheatsheet.html#cheatsheet-composite-matchers).

Times http://opencv.jp/googlemockdocs/fordummies.html#cardinalities

• Sie können die Anzahl der Anrufe angeben, indem Sie sie wie ein Mitglied von "EXPECT_CALL" verwenden. Es heißt Kardinalität.
• Sie können die Zählprüfung mit :: testing :: AtLeast (n) lösen (n ist eine ganze Zahl größer oder gleich 0).
• Der Test schlägt fehl, wenn nicht die angegebene Anzahl von Malen aufgerufen wird
• Sie können deklarieren, dass die Methode nicht aufgerufen wird, indem Sie sie auf "Times (0)" setzen
• "Zeiten (1)" kann weggelassen werden.

WillOnce, WillRepeatedly http://opencv.jp/googlemockdocs/fordummies.html#fordummies-general-syntax

• Kann wie ein Mitglied von EXPECT_CALL verwendet werden, um die Aktion beim Aufruf zu definieren
• Ich denke, dass die Aktion hauptsächlich den Rückgabewert angibt. Sie können dies nicht mit einer Methode tun, die keinen Rückgabewert hat.
• Will ** muss nach Times geschrieben werden.
• Sie können mehrere WillOnce-Werte verwenden und die Aktion für jeden Rückgabewert ändern.

using ::testing::Return;...
EXPECT_CALL(turtle, GetX())
    .Times(5)
    .WillOnce(Return(100))
    .WillOnce(Return(150))
    .WillRepeatedly(Return(200));

::testing::Return https://github.com/google/googletest/blob/master/googlemock/docs/cheat_sheet.md#actions-actionlist

• Es funktioniert, um den Wert als die oben erwähnte Aktion von "Will **" zurückzugeben.
• Es scheint, dass es verschiedene Arten von Aktionen gibt, wie auf der obigen Seite gezeigt. Ich bin mir nicht sicher, wo ich es verwenden soll ...

RetiresOnSaturation http://opencv.jp/googlemockdocs/fordummies.html#expectation-sticky

• Sie können es wie ein Mitglied von "EXPECT_CALL" verwenden, um anzugeben, dass Sie EXPECT_CALL nicht mehr betrachten sollen, wenn die Rolle von EXPECT_CALL beendet ist.

Google Mock Expectation zeigt standardmäßig "klebrig" an

• Ich denke, dass Sie verschiedene Tests durchführen und mit Ihrer Haut lernen müssen, was genau klebrig ist.

::testing::Invoke http://opencv.jp/googlemockdocs/cheatsheet.html#cheatsheet-using-afunction-or-functor

• Sie können eine Funktion wie unten gezeigt als Aktion definieren. Es wird wie Fälschung anstelle von Schein verwendet.

double Distance(Unused, double x, double y) { return sqrt(x*x + y*y); }
...
EXPECT_CALL(mock, Foo("Hi", _, _)).WillOnce(Invoke(Distance));

• Die mit Invoke in action registrierte Funktion muss dieselbe Funktionsform (oder kompatible Form wie void *) wie die Mock-Methode haben.
• Nicht verwendete Argumente können nicht verwendet werden. Es wird auch im obigen Beispiel verwendet.
• Es scheint "InvokeWithoutArgs" usw. zu geben. Es scheint, dass Sie alle Argumente ignorieren können, anstatt keine Argumente zu verwenden.
• Es gibt auch Aktion definieren, aber ...

NiceMock<> http://opencv.jp/googlemockdocs/cookbook.html#nice-strict

• Der damit deklarierte Mock gibt keinen Assert usw. aus, selbst wenn die Mock-Methode aufgerufen wird, bevor sie mit "EXPECT_CALL" gesetzt wird.
• "Geben Sie zunächst EXPECT_CALL und das Verhalten des Mocks an."
• "Sehr vorsichtig verwenden" "Fehler können ohne Vorwarnung übersehen werden"
• Ich empfehle es auch nur für Klassen zu verwenden, die keine Rolle spielen
• Ich habe auch einen Verwandten, Strict Mock.

Grammatisch

Prüfvorrichtung

https://github.com/google/googletest/blob/master/googletest/docs/primer.md#test-fixtures-using-the-same-data-configuration-for-multiple-tests

• Sie können eine von :: testing :: Test abgeleitete Klasse definieren, um ein Fixture zu erstellen (es gibt kein gültiges Japanisch, aber ich denke, es hat Nuancen wie Klassiker und grundlegende Konzepte).
• Insbesondere können Sie die vom Gerät erstellte Instanz für Testfälle freigeben. ,

RUN_ALL_TESTS und Hauptfunktion

http://opencv.jp/googletestdocs/primer.html#primer-invoking-the-tests http://opencv.jp/googlemockdocs/fordummies.html#fordummies-using-mocks-in-tests

• Bei Verwendung von Fixtures und Mock scheint main () erforderlich zu sein, um sie zu initialisieren.
• Wenn main () vorbereitet ist, scheint es besser, RUN_ALL_TESTS () mit der Rückgabe von main () auszuführen.

• Führen Sie alle Tests mit RUN_ALL_TESTS aus. Beachten Sie, dass Setup () und TearDown () dann für jeden Test ausgeführt werden.

::testing::InitGoogleMock

• Es scheint bei Verwendung von Mock zu initialisieren. Ich bin mir über die Details nicht sicher ... Es ist ein magischer Zustand.

Mehrere Ausnahmen (EXPECT_CALL)

http://opencv.jp/googlemockdocs/fordummies.html#fordummies-using-multiple-expectations

• Sie können EXPECT_CALL für mehrere Matcher (Matchbedingungen) im Voraus schreiben.

EXPECT_CALL(turtle, Forward(_));  // #1
EXPECT_CALL(turtle, Forward(10))  // #2
    .Times(2);

• Mehrere Ausnahmen verhalten sich jedoch eindeutig und können schwierig zu testen sein:
• Das Match-Urteil scheint in der Reihenfolge des zuletzt definierten zu sein
• Wenn Sie mehrere EXPECT_CALL für denselben Matcher schreiben, wird dieser durch den zuletzt deklarierten überschrieben.
• Wenn Sie mehrere Aktionen unter derselben Übereinstimmungsbedingung ausführen möchten, fügen Sie mehrere Will Once hinzu oder verwenden Sie :: testing :: Invoke.

InSequence http://opencv.jp/googlemockdocs/fordummies.html#fordummies-ordered-vs-unordered

• Sie können die aufrufende Reihenfolge der Methoden überprüfen
• Ich benutze es nicht so oft, deshalb kann ich es nicht im Detail erklären. Die Situation, in der Sie die Anrufreihenfolge testen müssen, ist bereits vorbei ... aber wenn Sie sie gut verwenden, ist der Testcode dann leichter zu erkennen?
• Es fühlt sich wie eine Zwischentechnik an, wenn es um diesen Bereich geht.
• Ein weiteres Beispiel beschreibt auch das Definieren einer Sequenz durch Anhängen an EXPECT_CALL.
• Es gibt Nach im Zusammenhang mit der Bestellung.

ON_CALL und Standardaktion

http://opencv.jp/googlemockdocs/cheatsheet.html#action

• Es scheint, dass ON_CALL die Standardaktion der Methode angibt
• Sie können dasselbe mit Will Repeatedly without Times tun, aber die Verwendung von ON_CALL kann die ursprüngliche Prozedur sein.
• Es scheint "DefaultValue :: Set (Wert)" zu geben.

Den habe ich nicht verstanden

• MOCK_METHOD_1_WITH_CALLTYPE
• :: testing :: Mock :: VerifyAndClearExpectations + sein Begleiter
• Können Sie die Zerstörung überprüfen?