Replace "yes" with self.Responder.Next(). Pass in a class instance (depending on your language), Responder to your mocker's constructor. The trivial implementation of Next is return "yes"; but you can also have it return other stuff, depending on how it was constructed. The actual details of this technique will vary based on what language the mocker is written in.
Don't mock devices. I once mocked my toaster and it tried to set my house on fire. It's not worth the risk, man.
Heck yeah. I think that this is a perfect place for a mocking framework. Just create an interface layer that separates the hardware (or hardware api) from the code that controls it... IProjector, ISoundProcessor, etc.
Once you have separated the hardware from the software and you are not directly dependent upon the hardware, you can use a mocking framework to write mocks or stubs that pretend like IProjector is real hardware. If you know that HardwareX responds to a certain method with a particular value, capture it and return it with your mocking framework.
Note that a mocking framework, per se, is not required. You could always create a fake like you are suggesting, but sometimes that fake gets too complicated because they are used by too many tests, and you get bugs in your fake. In that case, the mocking framework comes in and you can define only the behavior that you need in that particular test...
As Brian Genisio suggests this sounds like a perfect candidate for mocks, and his arguments for mocks versus fakes are very compelling. I haven't used mocks to test interactions with hardware but I have used them to test interfacing with 3rd party native APIs provided by vendors, which is a very similar use case. The general pattern is: - have an interface which vends out an object representing the input produced by the native API (or hardware device in your case) - mock it to produce the input you require for your test case - assert that your code handles this input in the right way
That way you can test your functionality without having to use the actual hardware (or vendor api, or other code, etc. etc.). Mock objects aren't just applicable to testing interactions with hardware or 3rd party apis - they can be used for all sorts of testing. Once you start using mocks, you'll wonder how you wrote code without using them.
I code in Java, using JUnit for my testing framework and have used EasyMock (http://easymock.org) and JMock (http://www.jmock.org). I prefer (and currently use) JMock, but it's worth trying both as their philosophies are rather different. I've also heard that Mockito (http://mockito.org) is very good, but haven't really used it in anger.
A company called Atomic Object has some nice reports about their using Mock Objects in C when working with embedded devices. See the papers at http://www.atomicobject.com/pages/Papers