Comment puis-je tester un appel est fait après un délai dans google test en utilisant un cadre moqueur

Question

J'essaie actuellement d'évaluer différents cadres de test. Lorsque vous utilisez des frameworks moqueurs (je penche pour FakeIt, mais google mock est bon aussi), je sais que vous pouvez tester vos propres performances en utilisant les appels du timer avant et après l'appel d'une fonction pour vérifier les performances de la fonction. Ce n'est pas ce que je cherche.

Ce que j'ai, ce sont des classes qui implémentent des délais sur les sorties pour certaines entrées. Par exemple:

• entrée 1 passe de bas à haut
• sortie 1 passe de bas à haut après 1,5 seconde.

Je voudrais pouvoir faire quelque chose où je précise une limite:

myMock.theInput(); 
EXPECT_CALL(myMock, theDelayedOutput()) 
    .Times(1) 
    .Before(1.6sec) 
    .After(1.4sec); 

Pour plus de précisions, les Before et After lignes ne sont pas pris en charge. Ceci est juste un exemple de ce que je préfère comme une syntaxe facile.

Est-il possible d'implémenter simplement une fonction "retard" dans les fenêtres entre faire l'appel d'entrée et avant de vérifier EXPECT_CALL?

Cela fait partie du processus - il me faudrait encore démarrer une minuterie propriétaire. Quelque chose comme ça?

myMock.theInput(); 
windowSleep(1.4); 
startTimer(); 
EXPECT_CALL(myMock, theDelayedOutput()) 
    .Times(1) 
endTimer(); 
ASSERT_TRUE(elapsedTime() <= 0.2); 

Answer 1

Je suis assez sûr que cette solution fonctionnera pour tout cadre sans modifier le cadre:

myMock.theInput(); 
startTimer(); 
EXPECT_CALL(myMock, theDelayedOutput()); 
endTimer(); 
ASSERT_TRUE(elapsedTime() >= 1.4); 
ASSERT_TRUE(elapsedTime() <= 1.6); 

Cela peut ensuite être enveloppé dans une macro:

#define EXPECT_CALL_DELAYED(theMock, expectCall, lowerBound, upperBound) {\ 
    startTimer();\ 
    EXPECT_CALL(theMock, expectCall);\ 
    endTimer();\ 
    ASSERT_TRUE(elapsedTime() >= lowerBound);\ 
    ASSERT_TRUE(elapsedTime() <= upperBound);\ 
} 

Le test final le code est alors:

myMock.theInput(); 
EXPECT_CALL_DELAYED(myMock, theDelayedOutput(), 1.4, 1.6); 

Alternativement, vous pouvez adhérer au principe DRY et pré-spécifier une "fenêtre" de chronométrage. Cela vous permet de tester, en spécifiant la synchronisation exacte, mais sans le désavantage de vous répéter en ayant à ajouter chaque fois un tampon de 0,1 seconde.

EXPECT_CALL_DELAYED_SET_WINDOW(0.1); 
myMock.theInput(); 
EXPECT_CALL_DELAYED(myMock, theDelayedOutput(), 1.5); 
myMock.theSecondInput(); 
EXPECT_CALL_DELAYED(myMock, theSecondDelayedOutput(), 3.1); 

Cependant, je n'ai pas testé tout cela. Je mettrai à jour plus tard et accepterai si cela fonctionne.

Answer 2

Depuis que vous avez étiqueté la question avec un test unitaire: Dans le test unitaire, vos tests ne doivent jamais dépendre du passage de l'heure physique. Cela a plusieurs raisons: Premièrement, vous voulez que vos tests soient exécutés le plus rapidement possible, donc vous ne voulez pas de retards. Une autre raison étant que le timing sur l'environnement de développement (où vos tests unitaires s'exécutent) peut être complètement différent de l'environnement cible, en raison de différents matériels, systèmes d'exploitation, charge du système, ...

l'écoulement du temps physique a du sens, mais ce sont des tests d'intégration sur le système cible (ou une simulation de celui-ci). En test unitaire, vous adopteriez une approche différente:

Vous feriez une simulation des fonctions/méthodes qui représentent votre horloge.Par exemple, si votre fonction FoncA définit une minuterie via SetTimer, fournissant un rappel à appeler lorsque le temps est écoulé:

• Dans certains de vos tests, vous moquer de la fonction SetTimer, appelez FoncA et, dans le cadre du le critère de réussite des tests, vérifiez que le setTimer simulé a été appelé avec les arguments que vous attendiez.
• Dans certains autres tests, vous appelez la fonction de rappel directement à partir du test pour voir si cette fonction se comporte correctement.

Dans ces deux cas de test unitaire, vous n'attendez pas l'expiration de l'heure physique. Cela dit, vous pouvez certainement utiliser les mêmes frameworks de test que ceux utilisés pour les tests unitaires pour les tests d'intégration (même si leurs noms, comme JUnit, semblent indiquer qu'ils ne sont utilisés que pour les tests unitaires). Et, si les tests d'intégration sont en fait le genre de tests que vous visez, les suggestions de Jeff Lamb seront certainement utiles.