Aide-mémoire personnel Google Test / Mock

Aperçu

La dernière fois, j'ai créé un environnement Google Mock pour C que j'utilise pour mon travail, j'ai donc décidé d'étudier un peu plus. Il y a quelque chose comme "Google C ++ Mocking Framework Cheet Sheet", mais c'est difficile à comprendre et cela ne me vient pas à l'esprit simplement en le regardant. En lisant, j'ai décidé de faire quelque chose comme une feuille de triche pour moi-même. Nous le mettrons à jour un par un.

Résumé des macros

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

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

• Entrez les noms majeurs et mineurs du scénario de test.

• Il semble qu'il ne soit pas bon d'utiliser le trait de soulignement. Je peux utiliser quelque chose.
• S'il y a plusieurs tests, une erreur de construction se produira à moins que la combinaison du nom de l'élément principal et du nom de l'élément mineur ne soit dupliquée.

• Dans TEST_F, le premier argument est le nom de classe défini comme appareil de test.
• TEST_P est une technique avancée qui vous permet d'exécuter un test plusieurs fois avec différents paramètres.
  • 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

• Le premier argument est la valeur attendue et le deuxième argument est la valeur réelle. Il peut être utilisé pour vérifier la valeur de retour lorsque la fonction est exécutée.
• Il existe également des parents tels que ʻEXPECT_NE et ʻEXPECT_TRUE
• ʻASSERT_ * terminera immédiatement le test lorsque la situation ne correspond pas à ce que vous attendiez, et ʻEXPECT_ * continuera.

MOCK_METHOD*, MOCK_CONST_METHOD*

• Utilisé pour définir des méthodes simulées. La partie «*» est le nombre d'arguments.
• Si le nombre d'arguments dépasse 10, il mourra. Des mesures sont nécessaires pour les projets malheureux qui ont des fonctions avec de nombreux arguments.

EXPECT_CALL

• Déclare que les méthodes de Mock seront appelées. Le premier argument est une instance de la classe Mocked (réelle plutôt qu'un pointeur), et le deuxième argument est le nom de la méthode
• Le nom de la méthode spécifie un ensemble d'arguments. Si un appel ne correspond pas aux arguments, cela signifie qu'il n'a pas été appelé.
• Vous pouvez omettre la vérification des arguments en utilisant :: testing :: _ décrit plus loin.
• S'il ne s'agit pas du NiceMock décrit ci-dessous, un appel de méthode Mock non exporté sera averti. (Le test réussira). Le test échouera s'il n'y a pas d'appels ATTENDUS.

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

• La définition exacte est le caractère générique de Matcher, qui, comme son nom l'indique, autorise des arguments arbitraires.
• Il y a différents Matchers sur la page ci-dessus, donc si vous les regardez, il y a peut-être quelque chose que vous pouvez utiliser.
• Il semble y avoir calcul logique.

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

• Vous pouvez spécifier le nombre d'appels en l'utilisant comme un membre de ʻEXPECT_CALL`. Cela s'appelle la cardinalité.
• Vous pouvez desserrer le contrôle de nombre avec :: testing :: AtLeast (n) (n est un entier supérieur ou égal à 0)
• Le test échouera s'il n'est pas appelé le nombre de fois spécifié
• Vous pouvez déclarer que la méthode ne sera pas appelée en la définissant sur Times (0)
• Times (1) peut être omis.

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

• Peut être utilisé comme un membre de ʻEXPECT_CALL` pour définir l'action lors de l'appel
• Je pense que cette action spécifie principalement la valeur de retour. Vous ne pouvez pas faire cela avec une méthode qui n'a pas de valeur de retour.
• «Will **» doit être écrit après «Times».
• Vous pouvez utiliser plusieurs WillOnces, et vous pouvez changer l'action pour chaque valeur de retour.

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

• Cela fonctionne pour renvoyer la valeur comme l'action de Will ** mentionnée ci-dessus.
• Il semble qu'il existe plusieurs types d'actions comme indiqué sur la page ci-dessus. Je ne sais pas trop où l'utiliser ...

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

• Vous pouvez l'utiliser comme un membre de ʻEXPECT_CALL` pour spécifier que vous ne devriez plus regarder EXPECT_CALL lorsque le rôle de EXPECT_CALL est terminé.

Google Mock Expectation indique "collant" par défaut

• Je pense que vous devez faire divers tests et apprendre avec votre peau ce qu'est exactement collant.

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

• Vous pouvez définir une fonction comme une action comme indiqué ci-dessous. Il sera utilisé comme faux au lieu de simuler.

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

• La fonction enregistrée avec Invoke in action doit être dans la même forme de fonction (ou une forme compatible telle que void *) que la méthode Mock.
• Les arguments inutilisés peuvent être inutilisés. Il est également utilisé dans l'exemple ci-dessus.
• Il semble y avoir ʻInvokeWithoutArgs` etc. Il semble que vous pouvez ignorer tous les arguments au lieu de ne prendre aucun argument.
• Il y a aussi Define Action, mais ...

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

• Le Mock déclaré avec ceci n'émettra pas d'Assert etc. même si la méthode de Mock est appelée avant d'être définie avec ʻEXPECT_CALL`.
• "D'abord, spécifions EXPECT_CALL et spécifions le comportement du simulacre."
• "Utiliser très soigneusement" "Les bogues peuvent être ignorés sans avertissement"
• Je recommande également de l'utiliser uniquement pour les classes peu importantes
• J'ai aussi un parent, Strict Mock.

Grammatique

Appareil d'essai

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

• Vous pouvez définir une classe dérivée de :: testing :: Test pour créer un appareil (il n'y a pas de japonais valide, mais je pense qu'il a des nuances telles que les classiques et les concepts de base).
• Plus précisément, vous pouvez partager l'instance créée par le projecteur entre les cas de test. ,

RUN_ALL_TESTS et fonction principale

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

• Lors de l'utilisation de fixtures et de mock, il semble que main () soit nécessaire pour les initialiser.
• Si main () est préparé, il semble préférable d'exécuter RUN_ALL_TESTS () avec le retour de main ().

• Exécutez tous les tests avec RUN_ALL_TESTS. Notez que Setup () et TearDown () sont ensuite exécutés pour chaque test.

::testing::InitGoogleMock

• Il semble s'initialiser lors de l'utilisation de Mock. Je ne suis pas sûr des détails ... C'est un état magique.

Exceptions multiples (ʻEXPECT_CALL`)

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

• Vous pouvez écrire EXPECT_CALL pour plusieurs correspondants (conditions de correspondance) à l'avance.

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

• Cependant, plusieurs exceptions se comportent de manière unique et peuvent être difficiles à tester:
• Le jugement de match semble être dans l'ordre par rapport au dernier défini
• Si vous écrivez plusieurs EXPECT_CALL pour le même matcher, il sera écrasé par le dernier déclaré.
• Si vous voulez avoir plusieurs actions sous la même condition de correspondance, ajoutez plusieurs Will Once ou utilisez :: testing :: Invoke.

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

• Vous pouvez vérifier l'ordre d'appel des méthodes
• Je ne l'utilise pas tellement, donc je ne peux pas l'expliquer en détail. La situation où vous devez tester l'ordre d'appel est déjà terminée ... mais si vous l'utilisez bien, le code de test sera-t-il plus facile à voir?
• Cela ressemble à une technique intermédiaire dans ce domaine.
• Un autre exemple décrit également comment définir une séquence en l'attachant à EXPECT_CALL.
• Il y a After lié à la commande.

ʻON_CALL` et action par défaut

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

• ʻON_CALL` semble spécifier l'action par défaut de la méthode
• Vous pouvez faire la même chose avec Will à plusieurs reprises sans fois, mais l'utilisation de ON_CALL peut être la procédure d'origine.
• Il semble y avoir DefaultValue <T> :: Set (value).

Celui que je n'ai pas compris

• MOCK_METHOD_1_WITH_CALLTYPE
• :: testing :: Mock :: VerifyAndClearExpectations + son compagnon
• Pouvez-vous vérifier la destruction?