ASP.NET vs Ruby on Rails : Round 2 (Agility)

Previous score : ASP.NET 1, Ruby 1

Personally, I'm a pretty huge fan of Agile programming. For a very long time, one of my mottos has been this:

If hindsight is always 20/20, then build hindsight into your development plan. Plan to build something that you can look back on and refactor, modify, or completely throw away.

What I mean by that is when building software the "Agile" way, I often try and produce small units of testable functionality. I want to ensure ensure that not only is the code stable, but that the unit of code is meeting the demands of use cases from a business point of view (validation taking place, business rules are tested and working, etc). Once I'm satisfied with that small, discrete, fixed target of code, I can move on and go from there. That's one small aspect of Agile programming. The other aspect of making my application Agile is that it is flexible, easy to change, and easy to maintain. Having been programming for over 20 years (that's right, I'm so old that I will soon be subjecting you all to my crotchety curmudgeonry!) I know that no matter how good your design is, you are going to have to stop coding in the middle of the process and make a change. I'm not talking about refactoring for pretty or more efficient code (which you shouldn't be doing until the end of the process, if you're behaving and being a good little programmer), I'm talking about hitting Refresh on that requirements document and seeing three bullet items dissappear and two new ones appear in their place.

One of the biggest pieces of Agile programming (for me, personally) is Test-Driven Development (TDD). What this basically means is that you start out with a bunch of use case scenarios that have been properly built and agreed upon by all concerned parties (hopefully one of those parties is a good interaction designer). You then map the use case scenarios to tests. These tests can be run against your model, your view, and your controller separately or together. Some sample tests might be:

• Create a new instance of the Product model, set its title to "Bob". Save the product in the database. Fetch that product from the database, assert that the title is still "Bob"
• Ensure that when the controller is tasked with only displaying products  with an activity date of today's date or earlier, that each product displayed has that date
• Ensure that when a product is rendered, the style of containing div tag is "product-item"
• Assert that when you attempt to insert a product into the database with a price that is less than .01 (no value), an exception is thrown
• etc

This is all really good stuff, and I'm sure you'll find that rules and test cases like this exist regardless of whether you're using ASP.NET, Java, Rails, Cold Fusion, Cobol, or anything hideous like Visual Basic (sorry, had to throw that in there... no offense to you VB folks) :) What we see here is a divergence in integrated support for this process between ASP.NET and Rails.

Here's how testing is supported by and integrated with Rails:

• Ruby stub scripts are automatically generated for you when you use the generator script to build models, controllers, etc
• Rails supports the notion of multiple environments for data - test, production, development being the "out of the box" environments. You can add more. This allows testing to take place in an isolated data environment.
• Rails comes with support for fixtures. Fixtures essentially allow you to use YAML files to define what your test data looks like, either by manually entering records (that could have been serialized from a copy of live data), or by using Embedded Ruby to dynamically generate records (often used for performance tests)***
• Rails supports the notion of  supplying separate tests for models, views, controllers, and even for performance.
• Rails creates detailed logs of statistics of tests performed.
• Within test scripts, you have direct access to attributes of the models, views, and controllers being tested
• Rails has special testing methods that allow you to make assertions based on the rendered HTML output to ensure compliance with a given UI spec
• Rails encourages Test-Driven Development by allowing you to create tests that act as a detailed spec on how your model, view, or controller should work
• I shouldn't have to explain the benefits here. Code written using TDD has less bugs, less design misunderstandings, and needs to be refactored less than code written "traditionally". There is a plethora of reference material available on TDD, including multiple books.

Now let's take a look at what you can do with ASP.NET as far as TDD and integrated testing:

• If you have a Team version of Visual Studio, you get integrated Unit Tests for business logic code and Load Tests for ASP.NET applications.
• caveat: If you aren't using proper MVC separation, you won't be able to test pieces of your code individually. For example, using common programming practices in ASP.NET, you may find that when you create a unit test, you won't be able to tell whether the failure was in your model or your controller if you've mashed all your code into the code-behind of an .aspx page.
• Absolutely no support for automatically wiping and reconstituting test data environments
• ASP.NET has no concept of fixtures
• Unit Test and Load Test results can be logged centrally to a Team Foundation Server, provided you're using a Team SKU and connected to a Team Foundation Server.
• When testing ASP.NET code, you rarely, if ever, have any access to members of code-behind classes. For example, you cannot write an external test that examines whether or not the code-behind file has set a member variable called myCounter without writing your own complex ASP.NET testing harness system, whereas its just part of the package in Rails.
• There is nothing to indicate that ASP.NET encourages Test Driven Development, as there is also very little within ASP.NET to encourage the true separation of model and controller. Again, its possible to do this, but it isn't as if ASP.NET sticks a big sign in your face telling you to do it now , whereas Rails forces this separation intrinsicially.
• While ASP.NET has a configuration file that can be used to allow your code to run in multiple environments... my experience has been that you need to involve the efforts of a dedicated configuration manager to take your code from development, to build, to stage, to production. The process seems more clean and smooth in Rails with the native support for an infinite number of build and test environments.

My conclusion for this Round:

Round 2 (Agility) goes to Ruby.

Current Score: ASP.NET 1, Ruby 2.

Stay tuned for Round 3 where I compare Object-Relational Modeling and data access. 

tags: web  net  agile  framework  ruby  rails  aspnet  asp  tdd  adonet  test  

links: digg this    del.icio.us    technorati    reddit