Friday, April 24, 2009

Unit tests as design documentation?

First, one thing I forgot to mention yesterday: the video card in my computer died, which is part of the reason why I wasn't blogging. The computer would have an acid-trip of sorts after a while and become unusable. I just got it replaced today with a $16 Nvidia card and it's working quite nicely. The main reason I got this card, besides the fact it was cheap, was that it uses passive cooling. God, this thing is so much quieter now...

Now, back to the main topic. After doing a bit more D coding yesterday and a little earlier today, I had an interesting thought after a couple of us talked about self-documenting code: could unit tests be used as design documentation? Think about it: if you design everything properly, your tests pass. Your tests should reflect the expected results of your methods/functions/whatever. I my case, since I'm trying to build an FSM, each test essentially documented the new state the FSM would enter based on the current state and any other inputs.

Granted, not all of your design is reflected in just unit tests, but a good portion could be. Combine this with some good documentation comments, and you've essentially provided design documentation in your code.

This is definitely something to think about because I'm thinking that the better way to document your software is in your software. If nothing else, your design is where your code is, so you have everything you need all in one place. Unfortunately, I don't know how to embed pretty diagrams in source code :-)

Labels: ,

Thursday, April 23, 2009

Update and New Direction

Wow, it's been a long time since I last posted.

Anyway, as for my Erlang project, it's working! Not finished, but it does work for small test cases. I still have to work on a couple things, primarily on distributing the application and getting the data on disk, but I'm happy with the results. It handles Ands (+keyword), Ors (keyword), and Nots (-keyword). It may not be the best algorithm, but it does appear to work well. The key thing was the use of mnesia to store and inverted index to store the keywords/document IDs.

Now, since it does work, I decided to start working on learning D for a while. I've also been itching to start since pure functions are now working and I've been wanting to try out threading in it as well. Remember that Perl script I wrote a while ago? I've been wanting to rewrite it in something more efficient and D looked to be the best choice. It handles regular expressions, threads, associative arrays, etc. all build into the language. Also, I really wanted to try out some of the other cool features, such as design by contract and unit testing. I haven't gotten too far, but I'm definitely enjoying it.

The interesting thing I discovered is that creating the unit test caused me to do more design work. You see, I'm going to create a finite state machine to parse a CSV file. Well, the functions for each state will be deterministic and lend themselves to being unit tested very nicely, so I began setting up all of the different states/inputs that I'll be dealing with. During this, I discovered that my initial design was flawed, however instead of going back to the drawing board, I decided to just continue creating the tests. I think it'll work out better because I think about what I'm doing more while working with code.

You know, the more I develop using D and learn about it, the more I like it. I'm really excited about getting to try out threading. So far, I haven't created much functionality, but I'm leveraging D's debugging capabilities, unit testing, pure/nothrow functions, and documentation comments. Having all of this as part of a language instead of add-ons is pretty nice.

Now, as an added incentive for me to get this stuff done, I plan on using this for a goal at work. Hopefully I'll be able to show off what can be done in both languages because they're both pretty damn cool. That, and I'm not a fan of the trend towards becoming a Java/.NET shop. :-(

Labels: , , , , ,