I got a basic Netduino over the weekend. I created the basic “Hello World” example (make the on-board LED blink found in the Getting Started Guide). I then tried to lift that code and load it into a test. I thought about using a unit tests project with Rhino Mocks for unit testing and then an integration tests project for hooking up to the actual board. To that end, I converted the Hello World Console Project into a Class Library Project. I then renamed Main into something better and removed the static keyword. I then added 2 test projects (one for unit, 1 for integration) and added a reference to the Netduino class project.
The working code looks like this:
public class BoardLight
{
public void LightBoardWhenButtonIsPressed(int interval)
{
OutputPort outputPort = new OutputPort(Pins.ONBOARD_LED, false);
while (true)
{
outputPort.Write(true);
Thread.Sleep(interval);
outputPort.Write(false);
Thread.Sleep(interval);
}
}
}
and the Integration Test looks like this (note the lack of an assert statement for the integration tests):
[TestClass]
public class BoardLightTests
{
[TestMethod]
public void LightBoardWhenButtonIsPressed_Success()
{
BoardLight boardLight = new BoardLight();
boardLight.LightBoardWhenButtonIsPressed(250);
}
}
I immediately got a warning like this:
Warning 1 The project ‘Tff.NetduinoExamples’ cannot be referenced. The referenced project is targeted to a different framework family (.NETMicroFramework)
A quick Bing search gives this post which is pretty close to the same problem. MSFT’s answer makes sense to me:
Posted by Microsoft on 5/25/2010 at 11:28 AM
This is because it is not guaranteed that there will be runtime failures – it depends on which frameworks are installed on the deployment machine. If the deployment machine has the right list of framework families then your application will run fine, else there will be runtime failures. We are merely trying to warn you of the possibility of runtime failures on the deployment machine so that you can take appropriate action.
Undaunted, I attempted to add a reference from my test project to the class library, however, the reference wouldn’t take:

And not suprisingly, when I pressed on and hit CTRL+R+T to see my test, it failed:
Test method Tff.NetduinoExamples.Tests.Unit.BoardLightTests.LightBoardWhenButtonIsPressed_Success threw exception:
System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.SPOT.Hardware, Version=4.1.2821.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Kinda intesting, looks like MSTest doesn’t “just work” when coupled with Microsoft Micro Framework. I posted this to the Netduino board here, no responses yet…
In the meantime, the entire project setup got me thinking – ok you have a project for unit tests where you can use a mocking framework and then a project for integration tests so you can actually hook up the board and run. Going back to the mocking framework – what actually are you testing? All of the examples show a light going on or nothing. How do you mock behavior and not post-action state? Do I build a testing rig that somehow evaluates that the method ran (some kind og diagnoatic trace?)
Turning to Osherove’s The Art Of Unit Testing, I checked out his section called “testing for event-related activities” on page 124. He recommends creating an inline anonymous delegate hooked into the event call (in this case, view.Load) with a tracking variable (in this case, loadFired). This smacks me of unit testing for unit testing sake. You can just run the event and see if there is an exception raised for the same kind validation.
What I realized is that the Netduino API needs some kind of pre and post variables and I use to verify state after I call a given method. Since I am a whole 24 hours into the API, my hope is that I have yet to discover those properties so I can check pre and post state….