brad.folkens.com - Home

Test first, it's better than history.

2007-04-21T14:50:00Z

When I first began to adopt the Unit testing mindset, I looked at it as a chore. It’s pretty obvious how non-motivating the thought of going back to a project to write tests can be. So I eventually gave up on the idea of testing and just hack-tested as I went along programming, expecting the things I tested at the beginning of the project to just “work” as I went along. The flaw with this (obviously) is that once you get further into a project, you’ll inevitably make changes along the way that affect things you’ve already “tested,” and a series of breakages will occur that you’ll spend hours and hours debugging only to have that moment of “oh yeah” later. After several years of this nightmare, I decided to look at testing again – this time with a fresh look on when to test and what to test.

I’ve been using Ruby on Rails now for several years and it’s made me an infinitely happier programmer. Besides being built on a cool language like Ruby, which lets us Ruby programmers do all sorts of cool things, Rails has a plethora of built-in testing methods that make testing so easy “you’d be stupid for not doing it.” But that still leaves us with the same problem question when we’re done with a project: “well it’s done now, do I have to write tests?”

It dawned on me sometime back when I started “testing first” that this problem is much like the difference between Math class (which I enjoyed) and History/English class (which I abhored). The difference between the two was obvious to me (in my mind). In Math, you could easily know you had the right answer because you could check it. History? Good luck. (I once scored 4 out of 50 on a scan-tron history test – yeah, 4 out of 50). In fact, in History we were even allowed to argue with the teacher about the accuracy of the test (which, in the end only gained me 2-3 points on my miserable score).

Most programmers write code like it’s History.

Don’t believe me? What’s x in 5x = 15? Well, if we do the algebra we come up with 3 – but how can we be sure it’s 3? We test! If we put 3 in for x, we come up with 15. Great, so we got the answer right – and we know it’s right. (If I wanted to be really cute about this example, our test ”= 15” is already written for us.)

We can take this example a bit further to programming. Think about all the assumptions you make when you sit down to write code. In the process of programming a project, you’re likely to make thousands of assumptions each time you code. Things like “this will never be nil” or “this will always create a record.” All those little assumptions should first be written down in your tests so they fail. Not only does this help you keep track of your assumptions and make sure they are always valid, it also helps maintain a todo list for all those things you “plan to get to later” and never do. Interruptions have to be a major cause of bugs.

Not only are the assumptions fresh in your mind when you test first, all the cases are as well. It’s usually not so easy as 5x = 15, there’s usually a lot more scenarios you need to consider. Sure enough, when testing first it’s significantly easier to consider and record those cases (especially edge cases) as tests, then make sure they all pass now and forever.

So test first, it’s better than History.

Formatting data in Rails Models - Part 2

2006-11-11T18:29:00Z

More advanced topics regarding the model_formatter plugin for Rails.

In Part 1, we learned about setting up the model_formatter to format and un-format attributes as they came in and out of the model. We saw how you could use some simple methods formatted_weight and formatted_weight= to get and set the formatted attributes. In this article, I’ll show you how to use more of the generated methods for more advanced usage.

Update – r5826 changes the default names of the formatters to use the format attribute name. (article revised)

We already know we can do things like the following to our Widget instance:

>> widget.weight = 1000
=> 1000
>> widget.formatted_weight
=> 1,000
>> widget.formatted_weight = '1,100'
=> '1,100'
>> widget.weight
=> 1100

In working on the project this was extracted from, we typically need to do things which access the same formatters, but not necessarily through an instantiated object. When the format_column method accepts our :as => :integer option, it creates an instance of the integer formatter. If you’ve specified a Proc pair or a block, you still get the same benefits, since it will wrap your Procs or block and expose them in a similar way, using (in our :to and :from, or block custom example) a CustomFormatWeight class. With the block, you get the added benefit of optionally adding an initialize method. In any case, you can access this formatter class in the following way:

>> Widget.formatted_weight_formatter 1000
=> 1,000
>> Widget.formatted_weight_unformatter '1,100'
=> 1100

You can also access the options passed to the formatter directly, which can be very helpful to piggy-back meta attributes with an attribute. See the :display_size option:

>> Widget.formatted_weight_formatting_options
=> {:to=>nil, :from=>nil, :options=>{},
:prefix=>"formatted_", :as=>:integer, :display_size => '12pt',
:formatter=>#<Formatters::FormatInteger:0x2601110 @delimiter=",">,
:formatted_attr=>"formatted_weight", :attr=>"weight"}

Hope some of this helps getting the feet wet with the formatter. This has been very useful for me in projects I’m working on – so hopefully you’ll feel the same way too. As always, critque away ;)

Formatting data in Rails Models - Part 1

2006-11-10T22:20:00Z

How to get up and running with the model_formatter plugin for Rails.

I’m in the middle of a very large project which I can’t talk too much about until it’s done, suffice to say we’ve got lots of database columns that need to be formatted/un-formatted. View helpers are great for formatting things on the way out, but what happens when users need to enter that data in the same format, or in an auto-detected format?

Updated 07/25/2008 – New repository on github

To begin, take our Widget example, with a column called weight. Weight is just an integer and we want it formatted all pretty, so we use a helper. But later we decide the user needs to enter data using the same format, so the controller accepts the input and can strip it, or we can throw that in the model too. Eventually though, we end up with a lot of the same code, un-formatting things in a model or controller that we’ve formatted already in the view. Seems a little un DRY to me…

Ideally, we’d have this code formatting stuff on the way into and out of a model, as with something like the code below:


class Widget < ActiveRecord::Base
  include ActionView::Helpers::NumberHelper

  def formatted_weight
    number_with_delimiter weight
  end

  def formatted_weight=(value)
    weight = value.nil? ? nil : value.gsub(/,/, '').to_i
  end
end

Ok, not so bad – we’ve got some basic stuff in place to format an attribute in the model and then something to accept formatted text, un-format it and set the weight attribute. But this is ruby, so we should be able to simplify this even further.

First, install the model_formatter:


script/plugin install \
  git://github.com/bfolkens/model-formatter.git

Then we can change our Widget to the following:


class Widget < ActiveRecord::Base
  format_column :weight, :as => :integer
end

Cool, so we’re on our way to getting a much simpler way to stack up formats on all these columns in our Widget. Now, what happens when we want to change the way weight is formatted? Let’s pass some options.


format_column :weight, :as => :integer, :delimiter => '.'

Now, instead of formatting our weight with something like 1,425,321 we return 1.425.321. You can pass options like this to all the formatters (and custom formatters too, as you’ll see further down). For example, the :decimal formatter takes :precision and the :currency formatter just passes options on the number_to_currency – so all your freedom is preserved.

Each formatter is just a small class which extends Formatters::Format. The super class contains a very simple set of methods: initialize, from, and to. It names the formatters, by default, with the ‘formatted_’ prefix, but we can change that to something much shorter – like ‘fmt_’.


format_column :weight, :as => :integer, :prefix => 'fmt_'

Now we’ve got a fmt_weight reader and a fmt_weight= writer.

So far, all we’ve used are the included formatters in the Formatters module, which are conveniently resolved with the symbolized shortcuts. So for example, :as => :integer expands to Formatters::FormatInteger. Fortunately, we can provide any Formatters::Format code to model_formatter in the same way as the shortcuts:


format_column :weight,
  :as => Formatters::FormatInteger.new(:delimiter => '.')

So there it is, the simple way to format things coming out of and going back into the model. We can customize the model_formatter even more though. What if we wanted to provide our own formatting functionality? Easy – we can do this several different ways. Either provide a class like the above, or you can provide a Proc directly:


format_column :weight,
  :from => Proc.new {|value, options| number_with_delimiter(value) + 'lbs.'},
  :to => Proc.new {|str, option| str.gsub(/,/, '')}

Of course, we can always do the same thing with a block.


format_column :weight do
  def from(value, options = {})
    number_to_delimiter value
  end
  def to(str, options = {})
    str.gsub(/,/, '')
  end
end

This is only the start though – there are a few more methods that are generated from the methods above (besides the accessors) that can be of great help when accessing attributes.