Testable Voice Activated Toaster

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 1st 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();



            LoadGrammarIntoSpeechRecognitionEngine(_speechRecognitionEngine, _choices);





        public static void CreateSpeechRecognitionEngine(SpeechRecognitionEngine speechRecognitionEngine)


            SpeechRecognitionEngine _speechRecognitionEngine = speechRecognitionEngine;


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



        public static void LoadGrammarIntoSpeechRecognitionEngine(SpeechRecognitionEngine speechRecognitionEngine, Choices choices)


            SpeechRecognitionEngine _speechRecognitionEngine = speechRecognitionEngine;


            Choices _choices = choices;



            Grammar grammar = new Grammar(_choices);





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 1st 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.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: