Several years ago, when I was a heads-down C++/ATL developer, I was working on a large project. I was one of about five developers on the team. My daily routine had consisted of writing some rather complex C++ code, then I would hit F5 in Visual Studio to run the entire product, then use the feature I was working on to see if my code worked. It was a long cycle – code, build, run, test. If I had a bug, I had to start the whole thing again. Honestly, most of us didn’t test our code that much, because we knew we had a testing team that would test it anyway.

Then, a small shaft of golden light broke through the darkness. Someone emailed me a url to an article about “extreme programming”. I didn’t understand most of it. Then about two weeks later the concept of writing tests for my code hit my like a ton of bricks. We had a testing team that had QA software in which they could write some horrible macros for trying to automate the GUI and read the screen for expected results. Agile development was telling me that I could write tests for my own code so I could make sure I was bug-free before the testing team even got my code.

It was hard figuring out how to write tests, and it was even harder figuring out how to run them consistently. I finally figured out a way to write tests in C++ in the same solution (it was called a “workspace” back then, in VC6), and even how to run them every time I compiled, with the results of the tests showing up in the Output window right after the build results.

Here it is about five years later, I’m using C#, and I do TDD regularly. But you know what, it is STILL big pain to do TDD in C#. And ASP.NET projects are even harder. VS2005 is supposed to make that easier, and I haven’t had the time to find out. Because I’ve had too much fun doing TDD with Ruby and with Rails.

Yes, I said the three-letter word: FUN. It is FUN knowing that my code works. It is FUN knowing that whatever work I did today didn’t break anything else. It really is, and if you haven’t tried writing tests for you code yet, you should.

Ruby has unit testing built-in, and Rails embraces it. Ruby’s Test::Unit module makes dirt simple to write tests:

# mytests.rb

require 'test\unit'
require 'myclass'

def test_something
  assert_equal 1, MyClass.One
end

def test_something_else
  assert_equal 2, MyClass.Two
end

Now I run ruby mytests.rb and my tests are run, and the results displayed on my console window.

That’s right. No NUnit to fire up. No separate .dll to hold my tests. No custom attributes to remember to put on my test functions. Nothing new to learn, aside from require 'test\unit' and then making sure my test functions start with the word “test”. It’s awesome.

Rails encourages test-driven development. Rake tasks are prewritten for you to run your tests. The environment.rb has placeholders for your test database environment. Heck, rake clone_structure_to_test will generate your schema for you in your test database based on whatever your development schema is. Rails “fixtures” let you specify your test data in simple text format without ever having to fire up your database engine.

But wait, it gets even better in Rails. Controller tests are setup for you when you generate a controller. You can easily simulate get and post requests, check for redirects, and even easily scan the resulting html for tags and content you expect from your web pages. All without needing to get populate your database tables manually, and you don’t even need an internet connection. With all the unit testing infrastructure built into Ruby and Rails, you will know that your website works before you upload it to your production server.

Maybe someone will comment to this post and tell me how much better ASP.NET 2.0 is than 1.1. Maybe someone will explain how ASP.NET is a better environment for testing their code than is Ruby on Rails. Because maybe there’s something new in VS 2005 that I’m not aware of that makes testing ASP.NET sites as easy as it is in Rails, and just as fun.

But somehow, I doubt it.