Tests efficaces en C++ avec stubs et mocks? (possible?)

Question

Je cherche quelques conseils de style pour tester ce morceau de code (Objective-) C++, j'ai encadré la partie Objective, car je ne pense pas que cela devrait avoir une incidence sur ce test.

class Probe 
{ 
    public: 
    bool playing(); 
} 

bool Probe::playing() 
{ 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; 
    iTunesApplication *iTunes = [SBApplication applicationWithBundleIdentifier:@"com.apple.iTunes"]; 

    // Logic here to determine if iTunes is playing requires a running iTunes. 
    // The behavior can also differ depending if iTunes is playing a DVD, CD, 
    // Stream, a File, something from the iTunes store, and a bunch of other factors 

    [pool release]; 
    return 1; 
} 

Comme mentionné dans le code, le comportement de cette méthode est accroché sur un détail environnemental en amont que je ne peux pas compter sur lors des tests en cours d'exécution (que je ne l'ai pas encore commencé à écrire.)

Comment tester efficacement ces conditions, en utilisant un pont de script, un adaptateur com ou une API en amont. Par exemple, je veux m'assurer qu'une autre méthode print_whats_playing() n'imprime rien, si rien n'est joué, ou que d'autres conditions sont remplies, d'une manière saine.

Il y a un deuxième argument à ce qui est d'isoler (plutôt que par souci de commodité) ma suite de tests de fait avoir besoin de frapper ces services système, ou API, peut-être la construction de la machine est firewalled, et ne peut pas atteindre une API ou une autre condition. Surtout dans ce cas, comment vous assurer qu'un appel API (réseau ou local) échoue afin que vous puissiez tester correctement une condition d'erreur dans votre code?

Dans ma maison (Ruby-land) vous "stub" (voir http://martinfowler.com/articles/mocksArentStubs.html) ou "simulez" le rôle, qui dans Ruby est facile, car vous pouvez simplement redéfinir une classe de test. De plus, dans des cas de test individuels, vous pouvez court-circuiter les méthodes, par exemple probe.expects(:playing).once.returns(false). Naturellement, cela ne va pas être aussi facile en C++, mais peut-être y a-t-il quelque chose sur mon chemin?

Answer 1

Donc, j'ai trouvé ma solution, après avoir trébuché sur une liste remarquablement bien dotée à wikipedia de frameworks de test C++, je suis tombé sur GoogleTest et le Google C++ Mocking Framework. Ce qui répond à toutes mes exigences, alors qu'il est un peu plus délicat à utiliser que les homologues Ruby, il est également bien présenté. Une chose que je ne suis pas si heureux, ou certain à propos de stubbing appels système - il semble que je devrais les envelopper dans ma propre classe que je peux alors se moquer des réponses - je n'ai pas un fort Je ne me sens pas d'accord, mais cela ne me semble pas optimal, bien que cela me permette d'être clair sur les éléments de fonctionnalité du système qui sont utilisés.

Answer 2

Si vous êtes toujours à la recherche d'un vrai framework Mocking en C++, vous devriez vérifier Isolator++ de Typemock. Il peut se moquer de tout appel en C++, le seul inconvénient de votre point de vue qu'il ne fonctionne actuellement que dans Windows.