C++ Tests unitaires, des objets moqueurs

Question

Je cherche actuellement à certains librarys de tests unitaires en C++ et ont quelques questions:

1. il semble y avoir aucune installation de moquerie dans boost.test mais je peux à peine penser à faire des tests unitaires sans créer d'objets/fonctions fictifs. Comment le feriez-vous dans boost.test, le faites-vous manuellement (comment? Je veux dire, il y a plusieurs façons de penser, rien de tout cela ne vous semble sympa) ou faites-vous simplement sans faux objets? Googletest et googlemock ressemble à de jolies librairies avec un mockingsupport, mais il faut que chaque objet qui doit être raillé soit virtuel. Je n'aime pas vraiment ça, ce n'est pas que je m'inquiète de la performance (je pourrais définir une macro pour la sortir du code de production quand même) mais je trouve cela très intrusif. Je me demande s'il existe une autre solution qui ne nécessite pas beaucoup de changement au code existant? (Clojure d'amour là-bas)

Answer 1

1. Boost :: test ne dispose pas d'un cadre moqueur ou d'une bibliothèque. Si vous voulez des simulacres, vous devez le faire vous-même, ou utiliser quelque chose comme GMock. Bien sûr, vous pouvez utiliser google mock avec Boost :: Test sans problèmes.

2. Sinon, comment voulez-vous que quelque chose soit raillé? Voilà comment cela fonctionne dans tous les autres langages de programmation! (D'accord, pas taper de canard, mais qui porte plus généraux que les méthodes virtuelles) Si vous êtes préoccupé par la performance:

   1. mettons tout en œuvre en termes de virtuals comme indiqué dans les documents Google général simulacres.
   3. Remplacez ces sections profilées (ou plutôt, le segment de votre code qui indique que la performance est un problème) avec high-perf dependency injection à la place.
   4. Ne remplacez pas tout avec DI haute perf, car cela enverrait des temps de compilation à travers le toit.

   En toute gravité cependant, je ne pense pas que les appels virtuels vont faire des différences énormes dans les performances. Le seul cas où les virtual sont mauvais est où ils sont situés à l'intérieur des boucles internes (comme dans la bibliothèque iostream où ils sont appelés éventuellement pour chaque caractère d'entrée ou de sortie), et même seulement dans le code sensible à la performance.

EDIT: I Missed le mot très important pas dans la question ci-dessus # 2 - que vous êtes pas inquiet au sujet des performances. Si c'est le cas, ma réponse est que vous êtes effectivement foutu. Un appel simple de fonction ou de méthode en C++ génère un appel de méthode simple, et il n'y a pas d'opprotunité à modifier lorsque cet appel pointe. Dans la plupart des cas, cela ne nécessite pas beaucoup de changement de code, car le code C++ correct utilise des références dans la mesure du possible, ce qui n'aura pas besoin d'être modifié malgré le fait que les virtual sont utilisés. Vous devrez cependant faire attention à toute personne utilisant la sémantique des valeurs, car elle sera sujette au problème de tranchage.

Answer 2

Turtle a été conçu pour être utilisé avec Boost.Test et a l'air très sympa avec moi.

Answer 3

Clause de non-responsabilité Je travaille chez Typemock.

Typemock Isolator++ peut se moquer de tout !! Vous n'avez pas besoin virtuel - tout est mockable

Voir explanation here

Ainsi, vous pouvez publique faux, privé, abstrait (sans réellement créer une classe concrète), non virtuelle, des arguments, par exemple en direct etc ... Et ... Elle modifie tout récursive

class MyClass 
{ 
    int GetResult() { return -1; } 
} 

Nous allons utiliser le code suivant

MyClass* fakeMyClass = FAKE<MyClass>(); // every call to fakeMyClass will be faked 
WHEN_CALLED(fakeMyClass->GetResult()).Return(10);