Testing with IronPython

We all know that unit testing is important with software development. But the tests themselves are not always so black and white. IDEs like SharpDevelop or MonoDevelop have things like NUnit to help test a wide range of things like equality, identity, collection, and etc. These are great tools, but what happens when you don't know what the data being gathered/generated should be? How can we assert something when we don't know what it should be?

My situation was this, I wrote a C# library for work to pull customer information and create reports based on the customer's monthly fees. Since the fees vary between customers, it was difficult to make sure that the data being pulled was accurate. Since I have been losing time with this portion of the project, I decided it would be a good time to test the abilities of Iron Python.

Why use Iron Python? Couple of reasons. First, since this is a .NET project, Iron Python can load the library through the clr.AddReferenceToFile command. Second, it can be ran as a script rather than compiling a new C# project. This means that I can alter/update the script and rerun it when I need to. Nice convenience.

What I did was write a script to pull in the .dll library and call the various objects to display the information stored in them in an organized way. Like so...

import sys,clr

clr.AddReference("System")
from System import *

if __name__ == '__main__':

    dllPath = Environment.CurrentDirectory.ToString() + r'\bin\Debug'

    sys.path.append(dllPath)
    clr.AddReferenceToFile('nameOf.dll')

    from nameOfNamespace import *

    print "Start going through the objects..."

From here, I can create test objects from the dll and see if what data is being pulled and confirm it with external sources to make sure it is accurate. The first time I ran it, I found (and corrected) a few missteps on my part. Within the first 30 minutes of running it, I was able to fix problems that would have taken me much longer in the final product. Pretty cool.

Troubleshooting Hardware can be a pain in the a$$ (note the dollar signs)

Ever since I have tinkered with computers and machines from one type or another, hardware has always been my achilles heel. Not only is it difficult to troubleshoot but it can be expensive as well. There was this one time along time ago where I had a 500+mhz Pentium 3 machine that would lock up at random times and when I would escape to the BIOS, the BIOS would lock up also. How do you troubleshoot something like that? I remember calling up my dad to take a look at it and when he saw the BIOS freeze, he was as stumped as I was. I ended up replacing almost everything in that computer and it still ran like crap. To this day, I don't know the exact cause(s) of that machine's problem but that was years ago.

So what brought this on? About a week or two ago, my OpenBSD machine started displaying hard drive errors out of the blue. What was nice was the error message displayed was pretty specific which was easier to figure out but it meant that I would have to buy another hard drive. However, awhile after I removed the offending drive the error started appearing more frequently at different times for different drives. At that point I started thinking it may have a bad hd controller on the board. The board is an older DFI board that has been holding up for about 4+ years so it was plausible that the board was the issue. I was about to look into new mother boards when I thought about trying a new harddrive cable. So I pulled out an old hard drive ribbon cable and gave it a go and everything started working. I almost spent money on a new hard drive and motherboard when all I needed was a new hard drive cable. I should have known based on how that cable looked. I'm surprised it lasted as long as it did...

So learn something from this kids. Hard drive failures could be just bad cables.