Beech Bonanza

State Pattern using module extension

2008-11-19T19:30:00.000-08:00

I try to favour delegation over inheritance. But sometimes Replace Inheritance with Delegation can be difficult. It turns out that when you have an inheritance heirarchy, and state is used in both the superclass and subclasses, it can be difficult to remove the inheritance heirarchy and replace it with delegation. Let's look at an example. Here we're modeling bikes:

class Bicycle
  def wheel_circumference
     Math::PI * (@wheel_diameter + @tire_diameter)
  end
end

class FrontSuspensionMountainBike < Bicycle
  def off_road_ability
    @tire_diameter * TIRE_WIDTH_FACTOR + @front_fork_travel * FRONT_SUSPENSION_FACTOR
  end
end

class RigidMountainBike < Bicycle
  def off_road_ability
    @tire_diameter * TIRE_WIDTH_FACTOR
  end
end                                                        

class RoadBike < Bicycle
  def off_road_ability
    raise "You can't take a road bike off-road"
  end
end

In this heirarchy the @tire_diameter instance variable is used in both the superclass and subclass. You can imagine that if we were to try to have the Bicycle class delegate to a FrontSuspensionMountainBike object, we'd have to duplicate the @tire_diameter state. This becomes a bit awkward, particularly if @tire_diameter can change - you'd have to ensure that the the @tire_diameter in Bicycle is kept in synch with the one in FrontSuspensionMountainBike. I'd probably decide that it wasn't worth the effort, and keep the inheritance heirarchy.

But what if we wanted to change the type of bike at run-time? Perhaps we want to upgrade a RigidMountainBike (a bike with no suspension) to a FrontSuspensionMountainBike. Using the state pattern would be ideal, but the traditional state pattern uses delegation. With ruby modules we have a different option. Rather than represent the FrontSuspensionMountainBike and RigidMountainBike behaviour as subclasses of Bicycle, we could make them modules and extend Bicycle with the appropriate module for the behviour that we want:

mountain_bike = RigidMountainBike.new
front_suspension_bike = FrontSuspensionMountainBike.new

becomes

mountain_bike = Bicycle.new.extend(RigidMountainBike)
front_suspension_bike = Bicycle.new.extend(FrontSuspensionMountainBike)

class Bicycle
  def wheel_circumference
     Math::PI * (@wheel_diameter + @tire_width)
  end
end

module FrontSuspensionMountainBike
  def off_road_ability
    @tire_width * TIRE_WIDTH_FACTOR + @front_fork.travel * FRONT_SUSPENSION_FACTOR
  end
end

module RigidMountainBike
  def off_road_ability
    @tire_width * TIRE_WIDTH_FACTOR
  end
end

So we could conceivably upgrade our mountain bike at run-time to add a fork with front suspension:

bike = Bicycle.new.extend(RigidMountainBike)
...
bike.add_front_suspension(fork)

module RigidMountainBike...
  def add_front_suspension(fork)
    @front_fork = fork
    extend(FrontSuspensionMountainBike)
  end
end

So we now have the ability to change behaviour at run-time, and we haven't introduced any duplication - the state and behaviour is still shared between the Bicycle class and the modules. But there's a problem:

bike.kind_of?(FrontSuspensionMountainBike) => true    
bike.kind_of?(RigidMountainBike) => true

We were able to mix in the FrontSuspensionMountainBike behaviour, but the RigidMountainBike behaviour still exists on the bike object. It turns out that ruby doesn't provide the ability to unmix a module. But all is not lost - there's an open-source library called mixology that does exactly what we want.

require 'mixology'

module RigidMountainBike

  def add_front_suspension(fork)
    @front_fork = fork
    unmix(RigidMountainBike)
    mixin(FrontSuspensionMountainBike)
  end

end

It provides two methods: unmix (for removing a module from an object) and mixin, for adding a module to an object. Our bug is now fixed:

bike = Bicycle.new.extend(RigidMountainBike)
...
bike.add_front_suspension(fork)

bike.kind_of?(RigidMountainBike) => false

Bored with the rhetoric

2008-11-18T15:08:00.000-08:00

During election time, I often find myself contemplating argumentative techniques as I watch the politicians do battle for votes. But it's not electioneering that I'm sick of - when you don't have a TV, live in the mountains, and avoid USA Today, you can moderate your intake pretty easily. It's programmer rhetoric that's gotten me down. We're an opinionated bunch, we developers. I'd like to think there's some relationship between an enjoyment of discrete mathematics and a healthy passion for the subtleties of logical argument, but rationality doesn't always reign supreme. Here's a few examples that I've seen over the past year:

Using the phrases "I'm just being pragmatic", or "my solution is the simplest thing that works" to convince someone the merits of an idea.
If you respect the person you are arguing with, and you are both aiming for a pragmatic and simple solution (as we all should be), then these statements are not helping. You're trying to discredit the other person's argument by implying that they are not pragmatic, or their solution is too complex. If the two of you agree that one solution is simpler than the other, then focus on why the simpler solution is adequate.

"But that's not Agile"
I see a repeating pattern in software. Over time, we learn from our mistakes. Out of this learning, we come up with some high level goals (such as the four specified in the Agile manifesto). We then develop some set of practices to help guide people in achieving the goals. Then we follow the practices, refining them a bit to make sure the goals are met. But then, after time, we get caught up in the mechanics of the practices, and forget what the goals are all about. Practices are often much easier to understand. Often when I hear "but that's not Agile", it's to do with a practice. It might be "If a story is more than 3 lines long, we're not being Agile". But the manifesto goal is "Customer collaboration over contract negotiation". So long as we're not sacrificing customer collaboration with our 4th line on our story, then it shouldn't be a problem. And if you think we're hurting our customer collaboration, focus on that in the argument.

The Logical Fallacy
"see, that's why we need continuous integration"
This quote comes from me. I said it. I use programmer rhetoric too :( But I'm trying to get better... Anyway, I was arguing with my project manager about our need for continuous integration. We were developing on macs, and deploying to linux. We had a problem that was only exposed on linux. I had been advocating for a linux machine to run Cruise Control. So I jumped on the chance to further my argument. "See, that's why we need continuous integration". But my project manager called me out on it. He's a smart guy. And he said "So are you telling me that you would have had a test that exposed this problem?". I had to admit that no, I wouldn't have. I'd used a logical fallacy. Yes, continuous integration helps expose bugs. Yes, we had a bug. Both of those statements are logically correct. But it does not follow that continuous integration would have exposed this bug. Shame on me...

As Steven Levitt says in Freakonmics, professionals tend to take advantage of their specialised knowledge to better themselves. He's talking specifically about realtors in one chapter, but programmers aren't above this behaviour. The skills and knowledge that we have gained in order to do our jobs is pretty rare, and we're privileged to be in the position we're in. But all too often I see developers taking advantage of their specialised knowledge during an argument and misleading their opponent by talking about something that the opponent doesn't understand. If you want to win the argument, explain your reasoning in a language that your adversary understands.

And yes, I do understand the irony of using rhetoric to describe my frustration with rhetoric. But I swear it's for good, not evil.

Discount for Voices That Matter Ruby Conference

2008-09-24T17:18:00.001-07:00

I'll be speaking at the Voices That Matter Professional Ruby Conference. You can get a discount of $200 if you book using this code: PRDPKRL.

soylent green is people. so is software

2008-09-24T16:46:00.000-07:00

I did a presentation on pair programming at a client a while back and it caused me to reflect a bit on the virtues of pairing. During my research, as is often the case for me, I found someone that articulated the benefits (and concerns) far better than I could. He may not have had pair programming in mind, but it is amazingly apt:

"Only if the various principles - names, definitions, intimations and perceptions - are laboriously tested and rubbed one against the other in a reconciliatory tone, without ill will during the discussion, only then will insight and reason radiate forth in each case, and achieve what is for man the highest possible force..." - Plato

Despite the somewhat sexist use of the word 'man' as a synonym the human race, Plato has done a good job here of describing the process of argument and some of the things to watch out for. The section that resonated most with me was the notion of perceptions being "laboriously tested and rubbed one against the other". This is where the true advantage of pair programming comes to the fore. By rubbing one idea against another, new ideas are born... is there a euphemism there? Anyway, the point is that you may start out with a couple of different ideas, but the process of discussion will often modify these ideas, combine them, or spawn completely new ideas. I've even had misunderstandings inspire orthogonal solutions. One participant will explain an idea, and the second participant will misunderstand, but try to build on their (mis) understanding, sometimes even coming up with a superior design.

But you don't need to take my word for it. A study undertaken by Alistair Cockburn and Laurie Williams highlighted the benefits of pair programming. During their research, they found that pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills through knowledge transfer and improves team communication. It costs about 15% more in development time (not double, as one might intuit). The cost in extra development time is more then compensated for (by at least an order of magnitude) with savings in reduced defects.

Pair programming was also considered a more enjoyable method of development by the participants in this study. I certainly find it more enjoyable, though I can understand that some software developers don't. If you're a personality who doesn't enjoy constant communication and collaboration then pairing can be tiresome. But, as my friend z once wrote "Soylent Green is people. So is software". Many difficulties associated with the software development process stem from poor communication, and pair programming can go a long way to addressing these problems.

Refactoring: Ruby Edition is now available on Safari

2008-09-24T16:39:00.000-07:00

Refactoring: Ruby Edition is now available on Safari as a Rough Cut. It's also available for pre-order on Amazon

The evolution of a Domain in rails: Part 2 Separate Query From Modifier

2008-01-27T20:18:00.000-08:00

When working on Refactoring, Ruby Edition, I realised that Separate Query From Modifier was one of my favourite refactorings. I'd been doing it for a while without realising that it had a formal name. I probably hadn't realised the full benefits of it either. From Refactoring, Ruby Edition: "When you have a function that gives you a value and has no observable side effects, you have a very valuable thing. You can call this function as often as you like. You can move the call to other places in the method. In short, you have a lot less to worry about." If you do not separate the querying code from the modifying code, code becomes difficult to understand and re-use. When I'm trying to track down a bug, I'm looking for two things: 1. The code that triggers the offending code (the query), and 2. the offending code itself (the modifier). If I have to search through a method that makes a query, then does some modification, then does another query, and some more modification, then my head starts to hurt. Which query returns the result that triggers the bug? And which modification is the bad modification? If we can separate the querying code from the modifying code, we can often achieve a better abstraction of our business rules and promote re-use. As a project evolves, we often have to introduce new trigger points for state changes. And in an agile environment, I often see the story cards evolve like this:

Story 1: Under condition 'X', 'A' should change such that...
Story 2: Under condition 'X', warn the user before making the change to 'A'

As Agile developers, we like this kind of story breakdown. After completing story 1, we can demonstrate to the user that we understand condition 'X' and the changes that should be made to 'A'. If we get it wrong, then we can fix it. Story 2 is the icing on the cake. It provides some nicer usability around the feature. It might also be a lower priority, and we might be able to release the code without Story 2 and gain some real business value before we polish it later. So the separation of the stories could be important. But if we mix query and modifier, it can become very difficult to introduce the warning, or introduce new trigger points for the desired state change.

But I've realised that Separate Query From Modifier is not always as easy as extracting conditional logic to one method, and having the modifying logic in another method. In my last post I said that in Rails, it can sometimes be difficult to re-wire multiple ActiveRecord objects of different type together according to some set of business rules without using the database as a storage mechanism, and without the validations getting in your way. We've often ended up with complex service methods that perform a query, do some modification (saving to the database), perform another query, do some more modification, and so on. You might end up with 5 or 6 queries that have to be performed in sequence. Later queries might depend on modifications that have been performed as a result of earlier queries. And the code is ugly, and difficult to re-use.

One way that we've solved this problem is to create a results object that represents the new relationships to be created. It's just a plain old Ruby object with some attributes. Let's say we're trying to build a new 'A' object, with relationships to B and C. Let's say A has_many B, and A has_one C. I'd create a results object called NewA, with an array attribute for the Bs and an attribute for the C. As I go through my algorithm, I can add my Bs and my C to the results object - without actually changing any underlying associations. (I now have a query without the modifier). Toward the end of the algorithm, I can present my results object to the user for confirmation, and if they confirm the change, then I can grab my results object and make the actual associations in the database (the modifier). I might even find that I can move some behaviour to this results object, and it will cease being a dumb data object. But even if I don't get to move any behaviour, the separation of query and modifier is worth the effort.

The evolution of a Domain in rails: Part 1

2008-01-25T08:44:00.000-08:00

I've been at my current client for about 15 months now, and during that time we've been working in fairly complex domains. Whilst our application started out very CRUD-like, it gradually moved away from CRUD in its simplest form (resources with simple attributes) to quite complex domain models. We now have quite a few functions that cause the interaction of 10-plus domain objects and often require the re-wiring of these objects according to a change in state triggered by a user. I was recently asked by a colleague to explain the limitations of ActiveRecord and some ways that we've overcome those issues. His concern was that Rails' tight coupling to the database would lead to anaemic domain objects that are effectively just DTO's, with all of the business logic creeping up into the view.

We've never ended up with business logic in the view, but we have made mistakes such that this behaviour has ended up in non-ideal parts of the application. Our first mistake was to place too much business logic in the controllers. This came about when we were trying to orchestrate the interactions between (say) three domain objects of different type. We asked ourselves "This behaviour doesn't belong on any one of the three domain objects, so where should it go?". Rails makes a clear distinction between Model, View, and Controller, and most of the examples only show "model" objects as being those that inherit from ActiveRecord::Base (and are therefore stored in a database). So given that we didn't want this business logic in the view, and it didn't belong on any of the "model" objects that we already had, the only place left was the controller. So our controllers got fat. And they were hard to test. And hard to change. And the business logic was very hard to re-use. And our model objects were thin (you might even say anaemic). Boo.

Fresh from reading Domain Driven Design, our teammate Pat Sarnacke came to the rescue, saying "We need services". And it's interesting to note that we were not alone in this discovery. So we extracted the business logic from our complex controller actions into Service objects. (From Domain Driven Deisgn, service objects are objects "with no state of their own nor any meaning in the domain beyond the operation they host"). We got quite a bit of re-use of this logic by doing so. It was definitely a step in the right direction. But then our Services started to grow. They became large and complex, and although they displayed the positive trait of having low coupling (with perhaps only one public method), they weren't very cohesive. We extracted private methods that were cohesive within themselves, but the collection of private methods made no sense together, other than the fact that they were part of the "procedure" of the service. And so the service became hard to understand in isolation, and not particularly amenable to re-use. If you wanted to re-use the service as a whole, then you were in good shape (much better than when the logic was in the controller). But if you wanted to re-use one of the private methods, it wasn't so easy (and not simply because they were private).

It turns out that, in some cases, it can be difficult to re-wire multiple ActiveRecord objects of different type together according to some set of business rules without using the database as a temporary storage mechanism. We would often end up with service classes that would first associate model A to model B, save model A, and then query model B for some further modifications to be performed. We'd have to reload model B in order to make this query (because it depended on the relationship to A). And so our services ended up being a sprinkling of save!s and reloads. And this was not because it was impossible to perform this logic in any other way, but because it was much easier to make the association, save it, and then go on our merry way through the rest of the algorithm.

And this worked for a little while. But any sub-section of the service was almost impossible to re-use. The order of association became very fragile because of our validations - you'd have to disassociate C from A before associating B to A because A couldn't have both B and C. And perhaps C needed a replacement for A to be valid, so you'd have to find C a new 'A' before you could save C. And so not only was the service procedural, but it was strictly procedural - you had to perform each step in a defined order. This made re-use very difficult. And what we really wanted to do was to move some of the logic onto domain objects, but with all the saving and reloading that was going on, it seemed almost impossible to extract logic that made any sense outside of the context of our complex algorithm.

And the killer came when we were asked to warn the user before we made this complex change, and give them information about the change that was about to be made so that they could decide whether or not to proceed. In order to know whether the change was going to be made, and what the change would look like, we'd have to traverse the entire algorithm, by which time the change would have been made. In short, we couldn't separate the querying code from the modifying code (see Separate Query from Modifier in Refactoring). This was the reason we couldn't fulfill the feature, and the reason that we couldn't move cohesive logic to the domain objects.

It took us two steps to solve these two problems (fragility and Separate Query From Modifier). I'll describe the solution to the fragility here, and the solution to Separate Query from Modifier in the next post.

Fragility

Our validations started to dictate the order in which our objects had to be saved (and therefore the order of the steps in our algorithm), which made re-use of code very difficult. So we decided that we needed a way to save without triggering the validations, but ensure that only valid objects were left in the database after the algorithm had finished. ActiveRecord provides a method called save_without_validation that takes care of our first requirement. And if we called save_without_validation within a transaction, and then raised an Exception if any of the objects were invalid at the end of the algorithm, then the transaction would roll back, and we wouldn't have invalid records in the database.

So we added a method called save_and_record_without_validation to ActiveRecord::Base which calls save_without_validation on the object, and stores the object in the Thread.current hash so that we can go back at the end of the algorithm and ensure that it is valid. We have a method called validate_recorded_records! which takes a block that contains the calls to save_and_record_without_validation, and then validates after the block has been executed. The calling code might look something like this:

    1 old_parent = Parent.find_by_name("oldie")
    2 new_parent = Parent.find_by_name("newbie")
    3 new_child = Child.find(5)
    4 old_child = old_parent.child
    5 old_child.parent = new_parent
    6 old_parent.child = new_child
    7 
    8 Parent.transaction do  
    9   validate_recorded_records! do    
   10     old_child.save_and_record_without_validation
   11     old_parent.save_and_record_without_validation  
   12   end
   13 end
   14 
   15

And if line 10 causes an invalid object until line 11 is executed, then it doesn't matter, because the validation only gets performed after the validate_recorded_records! block has been executed. The source code for our RecordingHelper can be found here and the tests here

So this solved our fragility problem - the order of execution of the statements no longer mattered as much, which enabled us to extract methods that could be re-used. But it still doesn't separate query from modifer - we'll tackle that in the next post.

Textmate command for running a focused unit test from a module

2007-10-27T08:32:00.000-07:00

Ricky Lui and I wrote a textmate command to run a focused unit test from a module. We sometimes extract common tests to a module and include the module in multiple places. It's nice to be able to select one unit test from the module file, and have it run the test from each of the files in which the module is included. Ricky explains it here , and the actual commands can be found here.

Testing of jruby JMS vs MRI activemessaging in production mode

2007-10-13T12:47:00.000-07:00

My previous performance tests of jruby JMS vs MRI activemessaging were flawed - I wasn't running in production mode, and my classes were being reloaded every time a message was processed. Rookie mistake. Anyway, here are my latest performance results running in production mode:

It turns out that MRI and activemessaging is faster. Not sure what causes the strange profile in the MRI test (perhaps garbage collection?), but I ran the test twice and came up with very similar profiles.

Thanks very much to my friend and colleague Joe Poon for pointing this out to me. Apologies to anyone who was inconvenienced by this.

Making Constructors Protected in Ruby

2007-08-22T16:52:00.000-07:00

I'm working on Refactoring: Ruby Edition with Jay Fields and Martin Fowler. One of the Java examples requires making the constructor protected, which is easy enough to do in Java. I'd never done it before in Ruby, so I thought I'd give it a shot. Lets say I have this scenario:

I don't want anyone constructing a Party object on its own, so I want to make the constructor protected. I basically want these tests to pass:

def test_new_raises_no_method_error
 assert_raise(NoMethodError) { Party.new("some name") }
end

def test_department_initialize
 d = Department.new("name")
 assert_equal "name", d.name
end

def test_employee_initialize
 e = Employee.new("name", 5, 12)
 assert_equal "name", e.name
end

I first tried this:

class Party
 attr_reader :name
 def initialize(name)
   @name = name
 end

 protected :initialize
end

But the initialize method can happily be called when constructing Party directly, so the first test fails. I then tried this:

class Party
 attr_reader :name
 def initialize(name)
   @name = name
 end

 class << self
   protected :new
 end
end

class Employee < Party
 def initialize(name, id, annual_cost)
   super(name)
   @id, @annual_cost = id, annual_cost   
 end
end

class Department < Party
 def initialize(name)
   super
 end  
end

which does prevent me from constructing Party directly. Unfortunately, I can't construct the concrete classes without getting a NoMethodError because I'm calling the protected method :new, so this isn't much good to me. But then Andy Kotlinski showed me that if I implement :new on both of the concrete classes to simply call super:

class Employee < Party
  def initialize(name, id, annual_cost)
    super(name)
    @id, @annual_cost = id, annual_cost    
  end
  
  def self.new(name, id, annual_cost); super; end
end

class Department < Party
  def initialize(name)
    super
  end

  def self.new(name); super; end
end

And now all of the tests pass, and my superclass constructor is protected.

Now, if you don't want to jump through all of those hoops, you can include a module like this:

module MakeConstructorProtected
 def self.included(klass)
   klass.module_eval do
      class << self 
       protected :new

       def inherited(klass)
         klass.module_eval do
            def self.new(*args); super; end
         end
       end
     end
   end
 end
end

class Party
  include MakeConstructorProtected
  attr_reader :name
  def initialize(name)
    @name = name
  end
end

And you don't need to modify any of your subclasses. Because the inclusion of the module documents the intention far better than the obscure code, I quite like this solution. It still feels a little un-ruby-like, but it does document that Party wasn't written with the intention of being constructed on its own, and I quite like that. If anyone has an easier way to do this, then I'd love to hear it.

Moist Tests: Production Code Needs to be DRY, But Tests Don't

2007-07-26T16:31:00.000-07:00

I've spoken a bit about this before when discussing our standard_params notation. I think we've taken the DRY principle too far. And I think this happens a lot in the software industry. We latch onto a good principle, and our meticulous (some would say anal) natures lead us to want to apply it everywhere. And we do it with DRY. Don't Repeat Yourself. Removing duplication in code removes bugs. Re-use promotes efficient development. It's a fantastic principle, first outlined by Dave Thomas and Andy Hunt in The Pragmatic Programmer. It's probably still underused in most code bases. But one area where I see it abused is in tests. Tests don't need to by DRY, they can be Moist*. Take these two tests for example:


def test_formatted_telephone_number
  telephone_number = TelephoneNumber.new(:area_code => "123", :telephone_number_base => "5556811")
  assert_equal "(123) 555-6811", telephone_number.formatted
end

def test_unformatted_telephone_number
  telephone_number = TelephoneNumber.new(:area_code => "123", :telephone_number_base => "5556811")
  assert_equal "1235556811", telephone_number.unformatted  
end

DRY would see the duplicate creation of the same TelephoneNumber object, and say "Extract Method" to remove the duplication. Or perhaps we could stick an instance variable in our setup, and assign the TelephoneNumber object to it there:



def setup
  @telephone_number = TelephoneNumber.new(:area_code => "123", :telephone_number_base => "5556811")
end

def test_unformatted_telephone_number
  assert_equal "1235556811", @telephone_number.unformatted  
end

And if this wasn't a test (if it was actual code that will be executed in production), I would definitely agree. If you remove the duplication, you only have one place to change the code when that time arises, and bugs are less likely to result. But in tests it is different. When a test fails, I want to fix it quickly. And when I have to search around a large test class for extracted methods, or instance variables that may be modified throughout the class, this costs me time. And I'm willing to accept the risk of the duplication causing a bug (after all, it is only test code) if I reduce the time wasted.

So for me, private methods in test are a smell. So too are setup methods. The only time I use them is when I can get the abstraction such that I very very rarely have to look at what is happening beneath the abstraction. A good example is rails' Controller tests. They have a setup which initializes the controller, and a request and response object. I think I can count on one hand the number of times that I've had to care about these variables, so in that case, it's ok.

*I believe zak came up with this term, though I'm not sure. It may have been Jay Fields. Either way, I'm certainly not taking credit.

Performance of the JRuby JMS messaging solution

2007-07-05T17:13:00.000-07:00

Please note: This performance testing method was flawed as it was undertaken in the 'development' environment. There are more accurate results here.

Now that we have a JRuby JMS implementation, how does it perform? I did a quick test to compare the ActiveMessaging solution with the JRuby JMS messaging solution. The Customer application, Orders application, ActiveMQ server and the message handler (ActiveMessaging poller/JRuby JMS process) were all running on my laptop. As such, the absolute timings presented here are not relevant, but the comparison between the two solutions is relevant, and somewhat interesting.

Testing Method

I sent 100 messages from the Customer application and measured the elapsed time between when the message was sent, and when processing had finished in the Orders application. With each solution, I captured the current time immediately before the message was sent in the Customer application, and captured the current time immediately after it was processed in the Orders application. These were the results:

As you can see, the elapsed time increases at a constant rate for the ActiveMessaging solution, as the 100 messages pile up in the queue. The last message took just under 14 seconds to be processed (with a significant amount of that time being spent in the queue). Contrast this with the Java JMS solution, where the 100th message took only 2.5 seconds to be processed. Even more interesting than the difference between the two times is the flattening of the Java JMS curve. The elapsed time does start to grow as the messages pile up in the queue, but after around the 60th message, the elapsed time remains relatively constant. This represents a great advantage when trying to ensure predictable performance of your messaging solution.

Conclusion

We are going to look seriously at using JRuby and JMS on our current project in place of ActiveMessaging. I mentioned in my last post that although I deployed the Orders application using JRuby, you can actually leave the web-app itself in MRI (Matz Ruby Implementation) and just deploy the message handler in JRuby. The message handler is running as a separate process to the web application. It needs to load the rails application to have access to the Customer model so that it can save the message contents to the database, but that's it. The web requests can still be handled by an MRI-deployed rails app. So that's probably what we will end up doing. Thoughtworks Studios recently released a project management tool called Mingle that is deployed on JRuby, so it's definitely possible to deploy the whole web-app in JRuby, but as an interim step we will probably stick with MRI.

JRuby JMS as a replacement for ActiveMessaging

2007-07-05T16:56:00.000-07:00

I was talking to JRuby committer Ola Bini at RailsConf a few weeks ago about our ActiveMessaging solution, and he suggested we try using JRuby and JMS instead. By using JMS, we can eliminate the poller and have a truly "Event Driven" solution. So I've been playing around with JRuby and JMS in my spare time, with some really interesting results. In JRuby, we can implement the Java JMS interface MessageListener:

require "java"

include_class "org.apache.activemq.ActiveMQConnectionFactory"
include_class "org.apache.activemq.util.ByteSequence"
include_class "org.apache.activemq.command.ActiveMQBytesMessage"
include_class "javax.jms.MessageListener"

ENV['RAILS_ENV'] = 'development'
RAILS_ROOT=File.expand_path(File.join(File.dirname(__FILE__), '..','..'))
load File.join(RAILS_ROOT, 'config', 'environment.rb')

class MessageHandler
  include javax.jms.MessageListener
  
  def onMessage(serialized_message)
    message_body = serialized_messageed_message.get_content.get_data.inject("") { |body, byte| body << byte }
    customer_payload = YAML.load(message_body)
    customer = Customer.new(:name => customer_payload.name)
    customer.id = customer_payload.id
    customer.save!
  end
    
  def run
    factory = ActiveMQConnectionFactory.new("tcp://localhost:61616")
    connection = factory.create_connection();
    session = connection.create_session(false, Session::AUTO_ACKNOWLEDGE);
    queue = session.create_queue("Customer");
    
    consumer = session.create_consumer(queue);
    consumer.set_message_listener(self);
    
    connection.start();
    puts "Listening..."
  end
end

handler = MessageHandler.new
handler.run

Contrast this with similar Java code:

import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.util.ByteSequence;
import org.apache.activemq.command.ActiveMQBytesMessage;

import javax.jms.*;


public class MessageHandler implements MessageListener {

    private Connection connection;
    private Session session;
    private Queue queue;

    public void onMessage(Message serializedMessage) {
        String message = "";
        ActiveMQBytesMessage bytes_message = (ActiveMQBytesMessage)serializedMessage;
        ByteSequence sequence = bytes_message.getContent();

        for(int i=0; i < sequence.getData().length; i++) {
            message += (char)sequence.getData()[i];
        }

        // Here is where you would use the message to create the Customer object
        // For now I will just print the YAML

        System.out.println(message);
    }

    public static void main(String[] args) throws JMSException {
        MessageHandler handler = new MessageHandler();
        handler.run();
    }

    private void run() throws JMSException {
        ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");
        connection = factory.createConnection();
        session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        queue = session.createQueue("Customer");

        MessageConsumer consumer = session.createConsumer(queue);
        consumer.setMessageListener(this);

        connection.start();
        System.out.println("Listening...");
    }
}

You'll notice that the 'run' methods are identical, save for the "rubyisation" of the Java code (underscores and the like). Java requires you to implement the onMessage method when inheriting from the MessageListener class, so we have done that in JRuby.

The Java class definition:

public class MessageHandler implements MessageListener

is replaced with the JRuby equivalent:

class MessageHandler
  include javax.jms.MessageListener

The rest of the JRuby code is very similar to its Java equivalent, though it was tough going back to the type-safety gymnastics of Java, I must admit.

I was surprised that with the version of JRuby I am running (ruby 1.8.5 (2007-06-02 rev 3812) [i386-jruby1.0.0RC3]), I had to use camel case for the onMessage method definition rather then ruby-like underscores, but it's no big deal.

We'll save this file under the processors directory of our Orders application as message_handler.rb

Then we can deploy the Orders application in JRuby. Note that this isn't strictly necessary (but more on that later).

From the instructions on the JRuby wiki:

Install the Goldspike plugin:
~/orders]>script/plugin install svn://rubyforge.org/var/svn/jruby-extras/trunk/rails-integration/plugins/goldspike

Install the ActiveRecord-JDBC gem:
~/orders]>gem install activerecord-jdbc --no-rdoc --no-ri

The plugin provides the following rake task:
war:standalone:create - which packages up a web archive containing your application along with JRuby and the rails libraries

Run the task, and deploy the war to your app server (I'm using Tomcat)

We can then make the apache-activemq-4.1.1.jar available to our script for the jms-related code by setting the CLASSPATH environment variable:

export CLASSPATH=/path_to_jar/apache-activemqvemq-4.1.1.jar:$CLASSPATH

Then all we need to do is run the JRuby code with the following command:

jruby /path_to_tomcat/webapps/orders/processors/message_handler.rb

And that's it. Now we can process Customer messages using our JRuby JMS implementation.

Asynchronous Messaging with Rails

2007-06-25T12:35:00.001-07:00

When asked how to integrate with other applications, the vast majority of Rails developers would answer "REST". And when they answer REST, they almost always mean synchronously. Now I have nothing against REST per se, but I will always favour asynchronous communication over synchronous. An asynchronous messaging solution such as JMS has well-documented advantages such as:

The message producer can "fire and forget", sending the message and then moving on to more important work.

The mechanisms required for reliability are relatively simple in the producer and consumer, and the more difficult tasks (such as persistence) can be handled in the message broker.

It is easy to add redundancy into the messaging infrastructure

Name

Address

Telephone Number, etc.

The Order Management application needs to associate Orders with Customers, so that even when the Customer application is down for scheduled maintenance, orders can still be taken. The Orders app has a simple view of a Customer, with just a name and an id.

We will make the Customer application responsible for creating, updating and deleting Customers. Whenever any of these actions are performed, the Customer application notifies the Orders application with a message. The message indicates the type of action performed (create, update, or delete), and the id of the customer, so that the two 'views' of the Customer object (in the two different applications) can be kept in sync. The Orders application then creates, updates, or deletes its view of the customer according to the type of message that is sent.

First, we will need to setup an ActiveMQ Server. I've set it up locally on my machine using these instructions (I used the Linux instructions for my Macbook Pro):

http://activemq.apache.org/getting-started.html

In both of our Rails applications we will need to install the ActiveMessaging plugin:

script/plugin install http://activemessaging.googlecode.com/svn/trunk/plugins/activemessaging

ActiveMessaging provides the ability to send and receive messages. Our Customer application will send messages, and our Orders application will receive them.

For the purposes of this discussion, I will only show the 'create' messages, though the process would be very similar for 'update' and 'delete'.

Customer application

Our Customer application has a Customer object that inherits from ActiveRecord::Base:

class Customer < ActiveRecord::Base
end

It has the following fields:

:name, :string
:address, :string
:telephone_number, :string
:created_at, :date_time
:updated_at, :date_time

Our message will be a YAML serialized message of the following simple data object:

class CustomerPayload
  attr_accessor :id, :name
  
  def initialize(params)
    @id = params[:id]
    @name = params[:name]
  end
end

We use a rails observer to observe the 'create' event of the Customer object, construct a CustomerPayload object, serialize it, and send it via ActiveMessaging:

require 'activemessaging/processor'
class CustomerObserver < ActiveRecord::Observer  
  include ActiveMessaging::MessageSender
  observe Customer
  
  publishes_to :customer_queue
  
  def after_create(customer)
    payload = YAML.dump(CustomerPayload.new(:id => customer.id, :name => customer.name))
    publish :customer_queue, payload
  end
end

To configure connection to the ActiveMQ server, I'll need the following configuration files in both of my rails applications:

#config/broker.yml
development:
    adapter: stomp
    login: ""
    passcode: ""
    host: localhost
    port: 61613
    reliable: false

#config/messaging.rb
ActiveMessaging::Gateway.define do |s|  
  s.queue :customer_queue, '/queue/Customer'
end

And to get the observer to work, I'll need this line in environment.rb

# Activate observers that should always be running
config.active_record.observers = :customer_observer

Orders application

For consuming messages, ActiveMessaging provides a directory under app called 'processors'. In this directory of my Orders application I place my CustomerMessageProcessor:

#customer_message_processor.rb
require 'processors/application'
class CustomerMessageProcessor < ApplicationProcessor

  subscribes_to :customer_queue

  def on_message(serialized_message)
    customer_payload = YAML.load(serialized_message)
    customer = Customer.new(:name => customer_payload.name)
    customer.id = customer_payload.id
    customer.save!
  end
  
end

This class will need access to the same CustomerPayload object as the Customers application for deserialization.

In ActiveMessaging, a poller is used to poll the queue and trigger the on_message method shown above. We'll need to start the poller in the Orders application using the following command:

script/poller run

And that's it. If both the Orders and Customer applications are running, and have access to the ActiveMQ server, then when we create a Customer in the Customer application, it should show up in the Orders application a few moments later.

Asynchronous Messaging with Rails

2007-06-25T12:35:00.000-07:00

The message producer can "fire and forget", sending the message and then moving on to more important work.

The mechanisms required for reliability are relatively simple in the producer and consumer, and the more difficult tasks (such as persistence) can be handled in the message broker.

It is easy to add redundancy into the messaging infrastructure

For further reference, a good book on the topic is Gregor Hohpe's Enterprise Integration Patterns

On a number of occasions I've started out with synchronous messaging, only to say to myself "I really want this to be reliable". So I fire off an http request and wait for a 200. If I don't receive a 200 after a certain amount of time, then I try again. I'll repeat this for a few times, then I'll give up, and log the failure somewhere.

Then I say to myself "It would be really nice to have this re-trying out-of-process". So I add another process that receives a request for a message to be sent, sends the message, and performs any re-trying that is required. And all of a sudden, I have asynchronous messaging. Now, there's nothing about REST that prevents asynchronous messaging, but I rarely see anyone from the Rails community talking about anything but synchronous messaging. So I thought I'd talk about how we've solved the problem on our project. We've used the ActiveMessaging plugin, originally written by some people from Thoughtworks. I'll demonstrate ActiveMessaging here, and then over the next week or two I'll contrast it with a JMS JRuby solution I've been playing around with.

Let's say we have two Rails applications - a Customer Management application and an Order Management application. The Customer application is responsible for managing all things to do with Customers - their personal details, any communications between our business and the customers, and the customer's user preferences. The Customer Management app has a rich view of a customer with fields such as:

Name
Address
Phone Number
Social Security Number
etc.

The Order Management application needs to associate Orders with Customers, so that even when the Customer application is down for scheduled maintenance, orders can still be taken. The Orders app has a simple view of a Customer, with just a name and an id.

We will make the Customer application responsible for creating, updating and deleting Customers. Whenever any of these actions are performed, the Customer application notifies the Orders application with a message. The message indicates the type of action performed (create, update, or delete), and the id of the customer, so that the two 'views' of the Customer object (in the two different applications) can be kept in sync. The Orders application then creates, updates, or deletes its view of the customer according to the type of message that is sent.

First, we will need to setup an ActiveMQ Server. I've set it up locally on my machine using these instructions (I used the Linux instructions for my Macbook Pro):

http://activemq.apache.org/getting-started.html

In both of our Rails applications we will need to install the ActiveMessaging plugin:

script/plugin install http://activemessaging.googlecode.com/svn/trunk/plugins/activemessaging

ActiveMessaging provides the ability to send and receive messages. Our Customer application will send messages, and our Orders application will receive them.

For the purposes of this discussion, I will only show the 'create' messages, though the process would be very similar for 'update' and 'delete'.

Customer application
Our Customer application has a Customer object that inherits from ActiveRecord::Base:


class Customer < ActiveRecord::Base
end

It has the following fields:

:name, :string
:address, :string
:telephone_number, :string
:created_at, :date_time
:updated_at, :date_time

Our message will be a YAML serialized message of the following simple data object:


class CustomerPayload
  attr_accessor :id, :name
  
  def initialize(params)
    @id = params[:id]
    @name = params[:name]
  end
end

We use a rails observer to observe the 'create' event of the Customer object, construct a CustomerPayload object, serialize it, and send it via ActiveMessaging:


require 'activemessaging/processor'
class CustomerObserver < ActiveRecord::Observer  
  include ActiveMessaging::MessageSender
  observe Customer
  
  publishes_to :customer_queue
  
  def after_create(customer)
    payload = YAML.dump(CustomerPayload.new(:id => customer.id, :name => customer.name))
    publish :customer_queue, payload
  end
end

To configure connection to the ActiveMQ server, I'll need the following configuration files in both of my rails applications:


#config/broker.yml
development:
    adapter: stomp
    login: ""
    passcode: ""
    host: localhost
    port: 61613
    reliable: false

#config/messaging.rb
ActiveMessaging::Gateway.define do |s|  
  s.queue :customer_queue, '/queue/Customer'
end

And to get the observer to work, I'll need this line in environment.rb


# Activate observers that should always be running
config.active_record.observers = :customer_observer

For consuming messages, ActiveMessaging provides a directory under app call 'processors'. In this directory of my Orders application I place my CustomerMessageProcessor:


#customer_message_processor.rb
require 'processors/application'
class CustomerMessageProcessor < ApplicationProcessor

  subscribes_to :customer_queue

  def on_message(serialized_message)
    customer_payload = YAML.load(serialized_message)
    customer = Customer.new(:name => customer_payload.name)
    customer.id = customer_payload.id
    customer.save!
  end
  
end

This class will need access to the same CustomerPayload object as the Customers application when it deserializes it.

In ActiveMessaging, a poller is used to poll the queue and trigger the on_message method shown above. We'll need to start the poller in the Orders application using the following command:

script/poller run

And that's it. If both the Orders and Customer applications are running, and have access to the ActiveMQ server, then when we create a Customer in the Customer application, it should show up in the Orders application a few moments later.

New notation for standard_params

2007-05-09T14:43:00.000-07:00

Andy Kotlinski came up with this new notation for standard_params. We found that over time, the use of standard_params became the default way to set up ActiveRecord objects in our test code, so Andy created a "new" and "create!" method, each of which take a class (or a symbol of the class name) as their first parameter. Since our standard_params methods are named using the convention of [class_name]_standard_params, we simply create an object of the passed-in class, passing in the hash returned by the appropriate standard_params method. We exclude any attributes that are passed in via the :without array, and merge any attributes that are passed in using the :merge hash.

Using a class name:


aeroplane = create! Aeroplane, 
                    :without => [:capacity, :safety_rating],
                   :merge => {:model_number => "567890"}

Using a symbol of the class name:


aeroplane = create! :aeroplane, 
                    :without => [:capacity, :safety_rating],
                   :merge => {:model_number => "567890"}

Both of these versions will construct an Aeroplane object using the hash of parameters returned by the conventionally named method:


def aeroplane_standard_params  
  { 
    :model_number => "123456", 
    :name => "A630", 
    :manufacturer => "Airbus", 
    :safety_rating => "5", 
    :capacity => "200"
  }
end

removing any attributes specified in the :without Array, and merging any attributes specified in the
:merge Hash.

We also added a :quantity attribute, which causes an Array of objects to be returned containing the number of objects specified. For example, :quantity => 2 would cause two Aeroplane objects to be returned:

                   
plane1, plane2 = new :aeroplane, :quantity => 2

The "new" and "create!" methods look like this:


def new(klass, options={})
  new_or_create(:new, klass, options)
end

def create!(sym, options={})
  new_or_create(:create!, sym, options)
end

def new_or_create(operation, sym, options={})
  raise ApplicationError.new("Option keys must be one of: [:without, :merge, :quantity]") /
    unless options.without(:without, :merge, :quantity).empty?
  
  klass, underscored = Class === sym ? [sym, sym.to_s.underscore] : [sym.to_s.camelize, sym]
  src = <<-EOS
    #{klass}.#{operation}(#{underscored}_standard_params.without(options[:without]).merge(options[:merge]||{}))      
  EOS
  
  return eval(src) if options[:quantity].blank?
  results = []
  options[:quantity].times do
    results << (eval src)
  end
  results 
end

The notation also works well with nested objects. A pilot object can be merged in, using the pilot_standard_params for construction:


 plane_with_pilot = new :aeroplane, 
                        :merge => {
                          :model_number => "12345",
                          :pilot => new(:pilot)
                        }

One must be careful using Extract Method in tests. If you hide away important setup information or assertion code, then failing tests can sometimes be more difficult to fix. I make an exception in cases such as this, where unimportant information to the test is hidden away, thus making the important information more obvious to the reader.

Thoughtworks is hiring ruby developers

2007-03-29T09:33:00.000-07:00

Thoughtworks is looking for a Ruby Specialist and Ruby Developers. In fact, we're pretty much hiring for all positions at the moment (Java, .NET and and Buisness Analysts). Send me an email at sharvie@thoughtworks.com if you have any questions, and mention my blog if you decide to apply.

modifying constants in a class to aid testing

2007-03-24T14:56:00.000-07:00

We needed a way to test pagination and sorting of lists across different pages in Rails controllers without having to create enough records to cross to the second page. So we created a method to alter the value of a constant in a class that we are testing.

It enables us to test pagination and sorting (amongst other things) like this:


class CarsController...

  PER_PAGE = 20

  def index
    @pages, @cars = paginate :cars, :per_page => PER_PAGE, :order => "make, model" 
  end

class CarsControllerTest < Test::Unit::TestCase...

  def test_index_sorts_by_make_and_then_model_for_page_1
    car1 = Car.create!(standard_params.merge(:make => "Fiat", :model => "Uno"))  
    car2 = Car.create!(standard_params.merge(:make => "Fiat", :model => "Bravo"))
    car3 = Car.create!(standard_params.merge(:make => "Citroen", :model => "C2"))  

    with_constants CarsController, :PER_PAGE => 2 do
      get :index
    end
    
    assert_equal [car3, car2], assigns(:assets)
  end
  
  def test_index_sorts_by_make_and_then_model_for_page_2
    car1 = Car.create!(standard_params.merge(:make => "Fiat", :model => "Uno"))  
    car2 = Car.create!(standard_params.merge(:make => "Fiat", :model => "Bravo"))
    car3 = Car.create!(standard_params.merge(:make => "Citroen", :model => "C2"))  

    with_constants CarsController, :PER_PAGE => 2 do
      get :index, :page => 2
    end
    
    assert_equal_arrays [car1], assigns(:assets)
  end

with_constants takes a class name and a hash of constant => value pairs, and yields to a block which is the code you want to call with the altered constants:


def with_constants(klass, constants_hash)
  begin
    old_constants = {}
    constants_hash.each_pair do |name, value|
      old_constants[name] = klass.send(:remove_const, name)
      klass.const_set(name, value)
    end
    yield      
  ensure
    constants_hash.each_pair do |name, value|
      klass.send(:remove_const, name)
      klass.const_set(name, old_constants[name])
    end
  end
end

wrapping stubba in stub_object method

2007-03-22T15:42:00.000-07:00

The stub method in stubba gives me a warning when you stub :id ("Object#id will be deprecated; use Object#object_id"), which we seem to do fairly often with ActiveRecord objects. So we use a simple method called stub_object (which we wrote originally because we didn't know "stub" existed):


def stub_object(params)
  object = Object.new
  params.each do |attr, value|
    object.stubs(attr).returns(value)
  end
  object
end

It gives us syntax like this:


manufacturer = stub_object(:id => 5, :name => "Ford", :telephone_number => "555-888-999")
Car.any_instance.expects(:manufacturer).returns(manufacturer)

And our manufacturer object will respond to any calls to :id, :name, or :telephone_number, without the warning for :id.

cruisecontrol.rb released

2007-03-17T08:56:00.000-07:00

Thoughtworks has released cruisecontrol.rb 1.0. You can download it here. I know of a lot of rails projects that were rolling their own continuous integration, which lead Thoughtworks to put some resources into developing cruisecontrol.rb. It takes about 10 minutes to set up, following rails' goal of convention over configuration.

table_for erb template

2007-03-05T20:38:00.000-08:00

Background:

Rails provides a form_for method which can be used in a view to generate an html form. When this is used, there is no need to specify the <form> tags and, when combined with the convenience methods such as text_field, select and radio_button, very little html needs to be handwritten.

At my current project we create a lot of CRUD interfaces. We found that we were often creating simple tables displaying attribute name-value pairs for a given object in the 'Read' view. Inspired by the Rails Recipes 'tabular_form_for' template, my coding pair and I decided to create a table_for template.

For example:

Let's say an Aeroplane object has two attributes:


   :name, :string
   :model_number, :string

An rhtml view for displaying the Aeroplane object might look like this:


<table>
   <tr>
      <th>Aeroplane Name</th> <td><%=h @aeroplane.name %></td>
   </tr>
   <tr>
      <th>Model Number</th> <td><%=h @aeroplane.model_number %></td>
   </tr>
</table>

<%= link_to 'Edit', :action => 'edit', :id => @aeroplane %> |
<%= link_to 'Back', :action => 'list' %>

We want to remove as much of that html code as possible. A syntax like this would be nice:

     
<% table_for @aeroplane do |t| %>
   <%= t.print :name %>
   <%= t.print :model_number %>                
   <%  t.link_to 'Edit', url_for(:action => 'edit', :id => @aeroplane) %>
   <%  t.link_to 'Back', url_for(:action => 'list') %>        
<% end %>

We put the 'table_for' method in application_helper.rb, so that it is available to all templates. It creates a TableForContext object to perform all the work for us, yields this object back to the caller, and wraps any output generated in 'table' tags.


def table_for(object, &block)
   concat('<table>', block.binding)
   context = TableForContext.new(object, block.binding)
   yield context
   concat(context.links + '</table>', block.binding)
   end

The 'print' method in TableForContext is straight-forward:


def print(field)
   "<tr>" + "<th>" + field.to_s.humanize + "</th>" + "<td>#{@object.send(field)}</td></tr>"          
end

We want the links to be side-by-side in a separate row at the bottom. You'll notice in the view that the result of the 'print' method is output directly (it is wrapped in <%= %> tags), whereas the 'link_to' method is not (it is wrapped in <% %> tags). The links are concatenated together to be output at the end:


def link_to(link_name, url)
   @links << ' ' unless @links.empty?
   @links << class =""> 'button')", @view_binding)
end

All that is left is some customization options. The ones we have required at so far are:

- custom wrapping of the attribute value in other html (eg making the value link to another page).
- custom headers (ie not just the attribute name humanized)
- custom css classes on the table headers

Let's say that an aeroplane has an associated Manufacturer object. We add a manufacturer_id attribute to aeroplane (and associated belongs_to and has_many declarations).

Let's say that the associated Manufacturer object has two attributes:


   :name, :string
   :address, :string

And that in the Aeroplane view we want to display the aeroplane's manufacturer name as a link to the manufacturer 'Show' view. Let's also say that we want a custom label on our Aeroplane 'name' attribute, and a class called "header" on all of our table headers.

With some changes to our 'table_for' and 'print' methods we should be able to accommodate the following syntax:


<% table_for @aeroplane, :header_class => "header" do |t| %>
   <%= t.print :name, :label => 'Super Happy Aeroplane Name:' %>
   <%= t.print :manufacturer do |manufacturer, aeroplane|
      link_to manufacturer.name, manufacturer_url(:id => @aeroplane.manufacturer_id)
   end %>
   <%= t.print :model_number %>                
   <%  t.link_to 'Edit', edit_aeroplane_url(:id => @aeroplane) %>
   <%  t.link_to 'Back', aeroplanes_url %>        
 <% end %>

The 'table_for' method now looks like this:


def table_for(object, options={}, &block)
   concat('<table>', block.binding)

   context = TableForContext.new(object, block.binding, options)
   yield context

   concat(context.links + '</table>', block.binding)
end

The constructor for TableForContext becomes:


def initialize(object, view_binding, options={})
   @object = object
   @view_binding = view_binding
   @links = ''
   @options = options
end

And the 'print' method now looks like:


def print(field, options={})
   label = options[:label].nil? ? field.to_s.humanize : options[:label]
   if block_given?
      content = yield @object.send(field), @object
   else
      content = @object.send(field)
   end
   "<tr>" + th(label) + "<td>#{content}</td></tr>"
end

We have added a private method 'th' which adds the header class, if specified:


def th(content)
   html = '<th'
   if @options[:header_class]
      html << " class=\"#{@options[:header_class]}\""
   end
   html << ">#{content}</th>"
end

standard_params to improve readability of tests

2007-02-08T13:00:00.000-08:00

I beleive this came from the Pragmatic Programmers.

For each of our ActiveRecord model objects, we have a private test method within the test class called "standard_params". It returns a Hash containing parameters which, if passed to the constructor of the ActiveRecord object, will result in the construction of a valid object.

The benefits of this method are two-fold:

1. It improves the readability of tests. If the ActiveRecord object has a long list of attributes, and you are testing behaviour which is dependent only on one or two of these attributes, you do not have to explicitly specify all of the parameters - you simply merge in the ones that you really care about.

For example:

Let's say an Aeroplane object is invalid unless it has a 6 digit :model_number. It also has a list of required attributes, such as :name, :manufacturer, :safety_rating and :capacity. It would be invalid without any of these attributes.

Without the standard_params method, our test for invalidity without a six-digit model number would look like this:


def test_invalid_without_six_digit_model_number
   aeroplane = Aeroplane.new(:model_number => "12345", :name => "A630", :manufacturer => "Airbus", :safety_rating => "5", :capacity => "200")
   assert_equal false, aeroplane.valid?
   assert_equal false, aeroplane.errors.invalid?(:model_number)
end

With standard_params it would change to:


def test_invalid_without_six_digit_model_number
   aeroplane = Aeroplane.new(standard_params.merge(:model_number => "12345"))
   assert_equal false, aeroplane.valid?
   assert_equal false, aeroplane.errors.invalid?(:model_number)
end

private

def standard_params
   {
       :model_number => "123456",
       :name => "A630",
       :manufacturer => "Airbus",
       :safety_rating => "5",
       :capacity => "200")
   }
end

:model_number is the only attribute explicitly specified in the test, thus removing a lot of "noise" in the test setup data - something which aids readability.

The second benefit is:

2. Tests are DRY-er (in a good way). I'm a firm believer that tests do not necessarily need to be DRY - readability is far more important. "Extract method" in tests can often be your worst enemy if done in a naive way. I think it is acceptable in this case because the part of the setup data that is extracted is not important to the test - that which *is* important is merged explicitly into the Hash in the test method itself. And so the usual benefits of DRY-ness result - when another attribute is added to the model object which itself has associated validations, the test methods that require construction of valid objects do not have to change - only the standard_params method needs to change.

We also added a "without" method to Hash, which removes elements specified in the parameters:


module HashExtension
 def without(*keys)
   clone = self.dup
   keys.each { |key| clone.delete(key) }
   clone
 end 
end
Hash.send :include, HashExtension

We use this in combination with standard_params to test for validates_presence_of clauses. Eg


def test_invalid_without_name
   aeroplane = Aeroplane.new(standard_params.without(:name))
   assert_equal false, aeroplane.valid?
   assert_equal false, aeroplane.errors.invalid?(:name)   
end