Jamie Dixon's Home

I learned something new about tests this morning.  Methods that are called from a test that have an Assert in them will be treated as a test.  For example:

        InterfaceKit interfaceKit = null;
 
        [TestMethod()]
        public void InterfaceKitAttachedTest_ReturnsTrue()
        {
            interfaceKit = new InterfaceKit();
            interfaceKit.Attach += new Events.AttachEventHandler(interfaceKit_Attach);
            interfaceKit.open();
        }
 
        void interfaceKit_Attach(object sender, Events.AttachEventArgs e)
        {
            bool expected = true;
            bool actual = interfaceKit.Attached;
            Assert.AreEqual(expected, actual);
            interfaceKit.close();
        }

 

Thinking about it, that makes sense – b/c the called method is sharing the stack so the Assert will be called and inspected.

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…

In following up to last week’s voice activated toaster, I wanted to work on making my solution more testable.  To that end, I re-read The Art Of Unit Testing:

 I still find his explanation of Mocks versus Stubs confusing.  In any event, I dove right in and added a test project to my solution.  I first realized that Rhino Mocks works either with Interfaces or Abstract Classes – the Phidget API had neither.  I read Brownfield Application Development In .NET:

 and realized that I needed to add an anti-corruption layer to the Phidget API and use an Adapter Pattern to wrap the existing API.

Moving to my code, the 1^st stumbling block is that the SpeechRecognitionEngine and Choices classes do not have a defined interface.  I refactored the CreateSpeechRecognitionEngine method to a more testable chunks of code:

 

        public static void SetupSpeechRecognition()

        {

            SpeechRecognitionEngine _speechRecognitionEngine = new SpeechRecognitionEngine();

            Choices _choices = new Choices();

 

            CreateSpeechRecognitionEngine(_speechRecognitionEngine);

            LoadGrammarIntoSpeechRecognitionEngine(_speechRecognitionEngine, _choices);

            _speechRecognitionEngine.RecognizeAsync(RecognizeMode.Multiple);

 

        }

 

        public static void CreateSpeechRecognitionEngine(SpeechRecognitionEngine speechRecognitionEngine)

        {

            SpeechRecognitionEngine _speechRecognitionEngine = speechRecognitionEngine;

            _speechRecognitionEngine.SetInputToDefaultAudioDevice();

            _speechRecognitionEngine.SpeechRecognized += new EventHandler<SpeechRecognizedEventArgs>(speechRecognitionEngine_SpeechRecognized);

        }

 

        public static void LoadGrammarIntoSpeechRecognitionEngine(SpeechRecognitionEngine speechRecognitionEngine, Choices choices)

        {

            SpeechRecognitionEngine _speechRecognitionEngine = speechRecognitionEngine;

 

            Choices _choices = choices;

            _choices.Add("Toast");

            _choices.Add("Stop");

            Grammar grammar = new Grammar(_choices);

 

            _speechRecognitionEngine.LoadGrammar(grammar);

        }

 

I then used the adapter pattern to make a testable Phidget API.  I created interfaces for a Phidget, Interface Kit, and a PhidgetException.  I then created Phidget, Interface, and PhidgetException classes that implemented the interface.   I also split out the all of the enums that the API uses into their own class – the values are the same thanks to Reflector.  My solution looked like this:

 

 

I then had some supporting classes to take care of the rest of the API.  The first was the event handlers.  For the sake of keeping the class count down, I put all of the event handers into one class:

 

namespace Com.Tff.VoiceActivatedToaster.Phidget.Events

{

    //Phidgit Events

    public delegate void AttachEventHandler(object sender, AttachEventArgs e);

    public delegate void DetachEventHandler(object sender, DetachEventArgs e);

    public delegate void ErrorEventHandler(object sender, ErrorEventArgs e);

    public delegate void ServerConnectEventHandler(object sender, ServerConnectEventArgs e);

    public delegate void ServerDisconnectEventHandler(object sender, ServerDisconnectEventArgs e);

 

    //Interface Kit Events

    public delegate void OutputChangeEventHandler(object sender, OutputChangeEventArgs e);

    public delegate void SensorChangeEventHandler(object sender, SensorChangeEventArgs e);

}

 

I then added individual classes for each event args.  The Event Subdirectory looked like so:

 

 

Hooking up the events to the Phidget API, I made some good progress.  I then had 3 public fields (sigh) on the Interface Kit: Inputs, Outputs, and Sensors.  My 1^st thought was to create interfaces and wrapper classes like I have done so far – but I immediately got a frying pan to the face:

 

 

 

Crap – the constructors are marked internal.  I could not wrap the classes.  I then went to plan B – use Reflector and implement the same code they used.  I then got a frying pan to the back of the head with Plan B when I looked at their code:

 

 

 

They were wrapping their unmanged code so they have these pointers and references all over the place.  I took a deep breath (“OK, I can do this”) and tried to implement.  I tried to reference the unmanaged assembly and got this:

 

 

Plan B is officially dead.  I then went to Plan C – use the Phidget API in my API.  I hated to do it, but I did it.  Here is the relevant code snippet:

 

    public class InterfaceKit : Phidget, IInterfaceKit

    {

        Phidgets.InterfaceKit _interfaceKit = null;

 

        //Have to use the Pdigit API b/c the Constructors are marked as internal

        public Phidgets.InterfaceKitDigitalInputCollection inputs;

        public Phidgets.InterfaceKitDigitalOutputCollection outputs;

        public Phidgets.InterfaceKitAnalogSensorCollection sensors;

 

        public InterfaceKit()

        {

            _interfaceKit = new Phidgets.InterfaceKit();

        }

 

 

I then hooked up my console application to the API and got nothing:

 

 

I then ran out of time: 5 hours of coding for Unit Test – and I have yet to write a single test.  I am just refactoring a poorly-written API to make the classes testable.

 

I’ll keep plugging away.