title: Effective testing in C++ with stubs and mocks? (possible?)
body: <p>I'm looking for some style advice for testing this piece of (Objective-)C++ code, I bracketed the <code>Objective</code> part, as I don't think it should have any bearing on this test.</p>
  
  <pre><code>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;
  }
  </code></pre>
  
  <p>As alluded to in the code, the behavior of this method is hung on an upstream environmental detail that I can't rely upon when running tests (which I haven't started to write yet.)</p>
  
  <p>How should one effectively test for these conditions, where you rely on a scripting bridge, or a com adapter, or an upstream API. For example, I want to make sure that another method <code>print_whats_playing()</code> prints nothing, if nothing is playing, or that some other condition is met, in a sane way.</p>
  
  <p>There's a second argument to this, which is to isolate (rather than for convenience) my test suite from <em>actually</em> needing to hit these system services, or APIs, perhaps the machine building is firewalled, and can't reach an API, or some other condition. Especially in this case, how to ensure that an API call (network, or local) fails so you can properly test an error condition in your code?</p>
  
  <p>In my home (Ruby-land) you would "stub" (see <a href="http://martinfowler.com/articles/mocksArentStubs.html" rel="nofollow">http://martinfowler.com/articles/mocksArentStubs.html</a> ) or "mock" the role, which in Ruby is easy, because you can simply redefine a test class. </p>
  
  <p>Also, in individual test cases, you can short-circuit methods, by something like <code>probe.expects(:playing).once.returns(false)</code>  - naturally it's not going to be that easy in C++, but maybe there's something on the way I can enjoy?</p>