Testable Phidgets – Follow up from last week

I have given up in creating a one-off interface for the Phidget kit and instead want to see if Rhino Mocks can support mocking concrete classes and give me what I want from an Unit Test.  I whipped up a quick test to see if the open method worked.  Note that I am not using the Assert keyword because I am doing interaction based testing, not state based testing.  I am doing interaction based testing because the method has no return value and the class has no other supporting property that I can use to verify that the method worked.

        [TestMethod()]
        public void OpenInterfaceKitTest()
        {
            MockRepository mockRepository = new MockRepository();
            InterfaceKit interfaceKit = mockRepository.DynamicMock<InterfaceKit>();
            mockRepository.ReplayAll();
            interfaceKit.open();
            mockRepository.VerifyAll();
        }

The test passed but 2 thoughts came to my mind:

·         Is this working right?

·         If so, what, in fact, am I actually testing?

Undaunted, I continued on to my next test – mocking the opening the actual Phidget channel.  I set up a unit test the same pattern:

        [TestMethod()]

        public void OpenOutputOnInterfaceKitTest()

        {

            MockRepository mockRepository = new MockRepository();

            InterfaceKit interfaceKit = mockRepository.DynamicMock<InterfaceKit>();

            mockRepository.ReplayAll();

            interfaceKit.outputs[0] = true;

            mockRepository.VerifyAll();

        }

When I ran the test, I got a nasty surprise:

Test method VoiceActivatedToaster.Tests.ProgramTest.OpenOutputOnInterfaceKitTest threw exception:

Phidgets.PhidgetException: PhidgetException 5 (Phidget not physically attached.)

This is odd – the mock is actually using the real Phidget board – not the mock one that I created.  I then went back to the Rhino Mock documentation and realized that I didn’t tell the mock what to do via an expect call.  I wonder if it is because I am using a concrete class on the left hand side of the equation, not an interface?

There seems to be 2 options in front of me.  Build a stub and inject that into the program class.  The stub is based on an interface and I could then control expectations to test my program completely.  Since the classes I am using don’t have any interfaces, I tried to build my own “wrapper” interface.  That turned out harder than I thought so I went to option #2.  Option #2 was to forget the stubs and use a mock that I could control behavior to test.  The examples on-line make sense, but I am having a tough time getting it to work.  I think part of the problem is that the API that I am mocking is not designed to be testable – the Open method does not return a value and there is not a corroborating property to verify and there is not a InterfaceKitDigitalOutput class that I can use – you can only turn the channel on/off via the index on the collection and setting its value to true/false.  The problem with option #2 is that I still can’t create a Mock without an abstract class or an interface.  Here is an example from my last attempt:

        [TestMethod()]

        public void OpenOutputOnInterfaceKitTest()

        {

            MockRepository mockRepository = new MockRepository();

            InterfaceKit interfaceKit = mockRepository.DynamicMock<InterfaceKit>();

            Expect.Call(interfaceKit.outputs.Count).Return(3);

            LastCall.IgnoreArguments();

            mockRepository.ReplayAll();

            int i = interfaceKit.outputs.Count;

            mockRepository.VerifyAll();

        }

I’ll keep reading up on Rhino Mocks – but it appears to be a limitation with the framework.

I wonder how much Phidgets would pay me to write a testable .NET wrapper class to their API?   There are 40 classes in it, prob 20 methods each.   If I only had weekends to work on this stuff…