Radio-friendly unit tester.

When everybody leaves on break and I find myself here with lots of time and space to myself, I tend to slip into left-brained introvert mode. Historically, this has meant either learning a new programming language, a coding spree, or both. This time around, it’s the latter. I’ve been dusting off my “Python”:http://www.python.org (which I taught myself over at HoneyRock over Thanksgiving Break, when it was just me, Julia’s cats, and the horses) and learning a new trick or two.

A long-term dream of mine has been to develop a science fiction development environment, with lots of tools for world-building. Every time I’ve taken a stab at it, I’ve always gotten bogged down in the same place–the data model for starsystems. Being a bit of an astrophysics geek, I want to be able to reasonably simulate real-life starsystems and do interesting things with them (like colonize them and then conquer them with my budding interstellar empire). The problem is, “real-life systems are complex”:http://www.stellar-database.com/Scripts/search_star.exe?Name=castor.

Now, at HoneyRock they have a saying: if something is worth doing, it’s worth doing poorly. That is, if something is important, do it, or it’ll never get done. I realized this is how I need to approach the problem. So, the other day I ran across an old link to “SpaceGear.org”:http://spacegear.org, which publishes a set of XML(eXtensible Markup Language) Schema for “modeling a virtual universe”:http://spacegear.org/about/ incorporating distributed virtual worlds. It’s a cool idea–not quite what I’m actually after, but close enough that it doesn’t matter, because it’s a data model that more-or-less describes what I want to do.

(Un)Fortunately for me, all the API(Application Programming Interface) work has been done in Java, a language which I don’t know very well and don’t care to learn more about. (I spent some time working with it last winter and just wasn’t thrilled.) So, I’m taking off in my own direction and developing my own API(Application Programming Interface) in the aforementioned Python, which I really enjoy working with.

An indirect result of this decision is that I get to work with a new programming practice I’ve been learning about–”unit-testing”:http://diveintopython.org/unit_testing/index.html and “test-first programming”:http://diveintopython.org/unit_testing/stage_1.html. That is, you write a set of test-cases which describe what you want the code to do. Then you actually write the code. As soon as your code passes all of your tests, you’re done. This is easy to do when writing an API(Application Programming Interface) for an XML(eXtensible Markup Language) Schema, because the “Schema descriptions”:http://spacegear.org/schemas/ are easily translated into a set of test cases.

For those of you who have no idea what I’m talking about, here’s a basic example (and my first completed project): an “AngularUnitType”:http://spacegear.org/schemas/BaseTypes/index.html, which is simply a number of degrees or radians, used in determining a star’s position relative to Earth (i.e. “Right Ascension”:http://www.answers.com/right+ascension&r=67). To implement this, I wanted to create a Python object that would store a number and the unit type (like, “180 degrees”) and convert to either degrees or radians, as necessary. So, I start off by writing a set of test cases. An AngularUnitType is described thusly:

bq. A simple type derived from xs:token that only allows the values rad or deg. For Radian and Degree. One Radian (rad) is 57.29577951 degrees. One Degree (deg) is 0.017453292 radians.

Therefore, my AngularUnitType class should do the following:

AngularUnitType should not mangle itself reporting value in native units.

AngularUnitType should give known value in radians for input in degrees.

AngularUnitType should give known value in degrees for input in radians.

AngularUnitType should not mangle its units.

AngularUnitType should always store value as a float.

AngularUnitType should not mangle its value (i.e. you should get back the same thing that you put in).

AngularUnitType should fail on bad units (i.e. anything but ‘deg’ or ‘rad’).

The code to test all of these cases is fairly simple and short. For instance, for the known values tests (2 and 3), I just pull out my unit converter and make a list of radian/degree equivalents for different values. For instance (and this is certainly more than you want to know):

|Radians|Degrees| |0.0|0.0| |1.0|57.29578| |1.5707963|90.0| |2.0|114.59156| |3.0|171.88734| |3.14|179.90875| |3.1415927|180.0| |4.0|229.18312| |4.712389|270.0| |5.0|286.4789| |6.2831853|360.0| |-1.0|-57.29578| |-1.5707963|-90.0| |-2.0|-114.59156| |-3.0|-171.88734| |-3.14|-179.90875| |-3.1415927|-180.0| |-4.0|-229.18312| |-4.712389|-270.0| |-5.0|-286.4789| |-6.2831853|-360.0|

Then, I just run through the list with a loop and create AngularUnitType objects for each value (say, in degrees), have each object convert to radians, and see if the results look anything like my independently-verified values. Python has an entire package interface that makes setting up these test cases a cinch.

Of course, if I run the test at this point, they all fail, because the AngularUnitType doesn’t actually do anything. Then I sit down and bash it out so that maybe it passes tests 5 and 6, which are fairly simple. I run the tests. Voila. Instant gratification. Before too long, I have code that passes all of the tests, and I can pat myself on the back. If this is starting to sound to you like a carrot and a stick, then, well, yes, a very astute observation on your part.

So, that’s a peek into my daily existence when nobody’s around and I’m at home with nothing to do.

Possibly related: