TDD, NUnit, Rhino Mocks, CAN, ISO and more...

It's been a while since my last post, I would like to post with more frequency but I dont really have much to show from the last few weeks. I've written a lot more code for the digital gauge cluster which i've aptly named 'Digital Gauge', yes very exciting :-) There just isn't too much to show thats all.

Menus
I've developed a flexible fully functional multi-tier menu system that can be displayed in variety of ways depending on the displayed gauge theme (currently only a S2000 style display). This allows me to change between gauge styles, color schemes, data providers (e.g. a debugging provider returning random values for things or my OBDLink data provider for real data). I can also change a variety of settings for the application and gauges in general (e.g. redline, speed alert, audible warnings etc...) I've included some pictures of the menu in action for the S2000 style cluster below.

Indicator Lamps
You might also notice the hazard lights, I've now got a fully functional set of indicator lamps for things like the indicators/hazard lights, ABS, TCS, Engine Check, Battery etc... These can only really be powered by CAN data and not OBD data as most of these things are not accessible via OBD requests (Except for the engine check).

Unit Testing
I had been debating in my mind as to the importance and need of unit testing for a project developed by a single programmer. For small applications it isn't really needed but my application is growing at an alarming rate. At last count (two weeks ago) I had 100 individual class files each performing separate logic. With that much code there is bound to be bugs and things I've missed... So after a few discussions with some colleges at work I decided that it's worth the effort and would probably save me time in the long run by writing tests for all of my code.

Unit testing can be difficult when things are not developed to be easily testable, using techniques such as  TDD / Test Driven Development greatly simplify things. However the idea with TDD is to write the test BEFORE you write your code! So quite a bit of code missed the boat. I've also been using the MVP / Model View Presenter design pattern which lends itself well to being easily tested. The idea here is that the display, processing and data storage responsibilities are separated into their own classes. This for one makes it very easy to have multiple cluster styles as all that is required is a new view (which is based on an interface anyways).

So for new code I will use TDD where possible and for testing the existing code I've been using a combination of NUinit and Rhino Mocks. Both free testing frameworks that work in very different ways. NUinit allows is a framework that allows the creation of standardised classes for testing, because it is so widely used there are lots of free tools that allow you to execute tests from directly in the visual studio IDE. Tests can also be run from continuous integration servers (a server that constantly compiles a projects code based and executes the tests on that code when changes are detected). With NUinit tests you basically write a method that checks and compares values against expected values. Rather simple but when used correctly very effective.


Rhino Mocks on the other hand is a framework that allows classes to be mocked and stubbed. Instead of having to write stubbed implementations of class dependencies you can actually stub individual methods on mocks of those classes. So for instance if you want a method on a class dependency to return a certain value maybe from a database without having to hit the database you can simple stub that method and test the code your specifically targeting.

Sounds like a lot of work? Well it is and it isn't. It's very time consuming but it's much easier to write a test for a specific scenario than it is to find an issue on a production system with a very limited user input system (e.g. a digital instrument cluster with four buttons to drive an entire OS). So the three to four weeks of writing tests spent now should mean less head aches down the road!

Other Stuff (CAN Standards and Chassis Arrival)
I've been in contact with a few sources over the last month who have provided me with some valuable details on how CAN systems are meant to talk to each other and identifiers of standard CAN components. Once I've collated all of these details into a neat package I will make another post in regards to this as it really warrants it's own post.

My shipping agent has contacted me and my Westfield SEiw chassis has arrived at the docks. I'm still going through the customs process so it will probably be later this week when I receive the chassis. There will definitely be some photos up here when I do!

I've also had some interest in me posting some source code for the program I wrote to reverse engineer CAN messages (original post). I will make another post over the next few days with some of the code used for this program.