Talk Like A Duck: Category best_practices

Best Practice Patterns, Accessors and Encapsulation

Rick DeNatale — Fri, 15 Feb 2008 08:29:00 -0500

One of the classics in the Smalltalk literature, which has also had a big influence on the Ruby community is Kent Beck’s “Smalltalk Best Practice Patterns”, which captures the best practices for designing and coding Smalltalk programs. Back when it was published, I used to see Kent a few times a year, and happened to be in the Bay area when he made an author appearance at the Computer Literacy Bookstore in San Jose, where I got my copy, and the autograph shown here.

The Ruby language has many similarities with Smalltalk, so much of Kent’s advice applies to Ruby. I frequently hear prominent Rubyists mention the book.

On the other hand, Ruby is not exactly Smalltalk, so Kent’s book isn’t an exact fit to Ruby. I’ve been wanting to start writing about adapting some of these patterns to Ruby for a while, so this article will hopefully be the first in a series.

The Motivation For This Article

Recently on the ruby-talk forum a thread discussing accessor methods vs. direct instance variable access came up. This was a hot debate topic in the Smalltalk community back in the 90s, and Kent addressed it in two competing patterns in the book, one of which Ryan Davis (a.k.a ZenSpider) brought up in the conversation.

Patterns Are Decisions, Not Prescriptions.

In their best form, patterns represent a network of decisions made during the creation of something, in this case software. A good pattern should describe the forces which affect the decision whether or not to adopt the particular solution it offers.

There can often be a tension between competing patterns, different patterns optimize different desirable characteristics, such as readability vs. flexibility.

The forces, or their relative strength, can be affected by technical factors such as the language, and features of the editor or IDE being used. To varying degrees many or all of Kent’s Smalltalk patterns have forces affected by the capabilities of the Smalltalk IDE. One of Kent’s main goals is readable code, so writing code to maximize the utility of the code exploration features of the Smalltalk browsers, inspectors, and debugger figures into the book.

A Tale of Two Patterns

Now to the specifics of the article at hand. The book has two patterns described in sequence,starting on page 89, “Direct Variable Access”, and “Indirect Variable Access”. Both address the same problem “How do you get and set an instance variable’s value?” and give two opposing solutions, along with a good discussion of the tensions.

The first pattern, as the name implies, advocates referring to an instance variable directly by name, so in Ruby, within a method, you’d just write @x, instead of using accessor methods, the second pattern.

As Kent points out in the discussion of the first pattern, direct vs. indirect access was a hotly debated topic in the Smalltalk community, although indirect access got to be popular since it was advocated by several Smalltalk training companies.

Tension Number One: Readability

In his argument for direct variable access, Kent explains that whenever he ran into an accessor method invocation, which in Smalltalk looks like this:

a = self x

He found himself pausing to remind himself that x was “just” accessing an instance variable, but that he would read the direct form:

a = x

without breaking his stride.

I might point out that Ruby is subtly different here. First, direct instance variable access is clearly marked with the ”@” sigil. On the other hand, a read accessor invocation in Ruby can be written without the explicit self receiver:

a = x

So it’s not as clear that this is a method invocation as opposed to a local variable access, although we know that it isn’t a direct instance variable access. Write accessor invocation usually requires an explicit receiver:

self.x = a

to disambiguate between a write accessor call and simply assigning to a local variable, at least the first time x appears in a particular lexical scope.

Tension Number Two: Subclassablity

Although direct instance variable is more readable, it does have a drawback in that it makes certain subclassing patterns harder to implement.

If a class uses indirect variable access consistently, then a subclass can leverage this by overriding the accessor. For example, lets say we want a subclass which audits changes to an instance variable. By overriding the setter accessor it can do things like logging changes very simply. Otherwise any methods which access the instance variable in the superclass need to be overridden.

Kent’s example is defining a PolarPoint subclass of Point which has radius and theta instance variables, and overrides Point’s accessors for x and y. One interesting aspect of the Ruby/Smalltalk comparison when you look at this example a little more deeply relates to my recent article about instance variables. In Smalltalk since the Point class has x and y instance variables, it’s subclass PolarPoint would have x, y, radius and theta instance variables, although the x and y variables would be vestigial and unused. In Ruby a PolarPoint instance wouldn’t acquire the unneeded x and y instance variables.

The Encapsulation Tension

One of the reasons why there was/is such a debate between proponents of direct vs. indirect instance variable access is the effect providing setter and getter accessors has on the apparent encapsulation of the object’s state.

First, in either Ruby or Smalltalk, the mere absence of accessor methods doesn’t prevent encapsulation intrusions. Ruby has the instance_variable_get and instance_variable_set methods, and Smalltalk has instVarAt: and instVarAt:put:, but these methods are ‘marked’ as slightly evil and reserved for dastardly deeds.

An accessor method on the other hand seems much more like any other normal method. In Smalltalk, convention is used to mark methods as private, although this is very weak consisting simply of putting private methods in a particular category in the browser, with no runtime check. Ruby does provide runtime checking of both private and protected methods, although even this protection can be circumvented, using send.

Summing Up

So in the end, the existence of and the tension between these two patterns demonstrates some key points:

Patterns present choices, and the best patterns provide enough information to make an informed decision on a case-by-case basis.
The languages and the tools we use have an effect on the patterns and the decisions they engender.

Validating RSS Feeds with RSpec

Rick DeNatale — Fri, 08 Feb 2008 10:38:00 -0500

One of my current Rails projects involves generating an RSS feed. While I was working on this the other night, it seemed to be working, so I deployed it to the staging server. Everything looked fine. If I fetched it with Firefox, the browser offered to let me subscribe to the feed with Google Reader, and if I used Safari I'd see a nice view of the feed just like I expected.

So I sent a note via our campfire to check it out, and a colleague replied that his Safari was saying that it was in an invalid format.

So I went to the W3 RSS Feed Validation Service and worked through the validation issues, after which his browser was as happy as mine.

Of course, having been through that, I wanted to make sure that RSS validation was covered in the specs for the project.

I went looking for an existing RSpec matcher, and found a matcher to validate XHTML but nothing for RSS.

I then found the feedvalidator gem which provides a Ruby interface to the SOAP interface to the W3 feed validator. You would think that W3 would be providing a REST interface! The gem already provides assertions for use with Test::Unit, so I just built an RSpec matcher.

class BeValidFeed
  require 'feed_validator'
  require 'tmpdir'
  require 'md5'

  def matches?(response)
    return true if validity_checks_disabled?
    v = W3C::FeedValidator.new()
    fragment = response.body
    filename = File.join Dir::tmpdir, 'feed.' + MD5.md5(fragment).to_s
    begin
      response = File.open filename do |f| Marshal.load(f) end
      v.parse(response)
  	rescue   
      unless v.validate_data(fragment)
        @failure = " could not access w3 validator to validate the feed."
        return false
      end
      File.open filename, 'w+' do |f| Marshal.dump v.response, f end
  	end
    v.valid?   
  end

  def description
    "be valid xhtml"
  end

  def failure_message
   @failure || " expected xhtml to be valid, but validation produced these errors:\n #{@message}"
  end

  def negative_failure_message
    " expected to not be valid, but was (missing validation?)"
  end

  private
    def validity_checks_disabled?
      ENV["NONET"] == 'true'
    end
end

def be_valid_feed
  BeValidFeed.new
end

I saved this as spec/be_valid_feed.rb

And in a view or controller spec, I can include this file, and test a response with:

response.should be_valid_feed

If you use this in a controller spec, you will need to tell RSpec to integrate_views, or you won't have much of a feed to check. If you use nested example groups, integrate_views needs to be inside the inner group.

Chicken Typing Isn't Duck Typing

Rick DeNatale — Mon, 22 Oct 2007 10:43:00 -0400

Stress
© David Friel

Trans just posted a question on ruby-talk.

It seems that he uncovered a conflict between the facet's library and the Ruby standard open_uri library. Open-uri defines a module called Meta which it uses to extend certain StringIo instances. The Meta module adds several methods including one called meta, which returns a hash of meta information. In two places in open_uri, the message "respond_to? :meta" is used to test whether a particular StringIO instance has been extended.

The problem is that Facets also defines a method in either Object or Kernel called meta which provides a clever way to access the singleton class of an object. So the respond_to? in open_uri was getting false positives.

Trans asked "So where lies the fault in this conflict? Are extensions the bad guy, or is respond_to? really not a good oop concept? Or..?"

David Black replied that he thinks "this is just the age-old issue about adding methods to existing classes and hitting conflicts. #respond_to? is relatively dumb; it can't tell you what the method actually does. I think of it as an important tool for "soft" duck typing, in contrast with "hard" duck typing where you just send the object the message. "

Reading this made me realize that a much better name than "soft" duck typing, for using kind_of?/is_a?, respond_to?, or other such "sniff first" techniques, is Chicken Typing

Chicken Typing Isn't The Dynamic Equivalent of Static Typing

From what I've observed chicken typing is a "safety blanket" technique used by programmers experienced in statically typed languages, who seem uncomfortable with making the paradigm shift needed to really make dynamically typed languages work.

But because Ruby is dynamically typed, such techniques work imperfectly at best. Here are some of the problems:

Checking with respond_to? can give false positives like this because just because an object has a method with the name you are looking for, doesn't mean that the method has the semantics you expect
Similarly respond_to? can give false negatives when methods are implemented dynamically via method_missing. Chicken typers try to enforce conventions which require overriding respond_to? to get around this, but in general this is difficult, expensive, or impossible to do perfectly.
Checking with kind_of?/is_a? is unnecessarily constraining. In Ruby you don't need the the equivalent to Java Interfaces or Abstract Classes, and once you've really made the paradigm shift from chicken typing to duck typing, you realize that you don't want them.

What's OpenURI Doing?

Because of Trans' question, I decided to look at how OpenURI was using respond_to? in this case. Here's the code in question:

First the beginnings of the OpenURI::Meta module

module OpenURI
 module Meta
   def Meta.init(obj, src=nil) # :nodoc:
     obj.extend Meta
     obj.instance_eval {
       @base_uri = nil
       @meta = {}
     }
     if src
       obj.status = src.status
       obj.base_uri = src.base_uri
       src.meta.each {|name, value|
         obj.meta_add_field(name, value)
       }
     end
   end

   attr_accessor :status
   attr_accessor :base_uri

   # returns a Hash which represents header fields.
   # The Hash keys are downcased for canonicalization.
   attr_reader :meta

   # MORE STUFF....
end

Meta.init causes the object passed as the first parameter to extend Meta, if a second parameter is passed, it's presumably also a Meta, and it's meta attributes are copied to obj.

Now here's the use of chicken typing:

module OpenURI
   #...
  class Buffer # :nodoc:
    def initialize
      @io = StringIO.new
      @size = 0
    end
    attr_reader :size

    StringMax = 10240
    def <<(str)
      @io << str
      @size += str.length
      if StringIO === @io && StringMax < @size
        require 'tempfile'
        io = Tempfile.new('open-uri')
        io.binmode
        Meta.init io, @io if @io.respond_to? :meta
        io << @io.string
        @io = io
      end
    end

    def io
      Meta.init @io unless @io.respond_to? :meta
      @io
    end
  end

A few observations:

The variable which is being chicken typed, in both cases, is an instance variable which is set by the initialize method and never rebound. So there's no concern about checking an object which was handed in, e.g. through a parameter. We might be concerned that someone outside the class might somehow access it and change it to extend Meta without the Buffer knowing about it, but...
The instance variable will always extend Meta after the accessor is called, so the above concern is moot.
In the io accessor method, respond_to? is used to prevent re-extending Meta. This could be avoided by either extending the object referred to by @io in the initialize method, or, if there's a legitimate reason to defer the extension, either adding a state instance variable to indicate that the extension has been done, or just change "unless @io.respond_to? :meta" to "unless @io.kind_of?(Meta)". This is one case where kind_of? is really useful since we're really just checking if code under our control has extended an object under our control, with a particular Module.
Finally, a minor point, but I find this code unnecessarily hard to read because of the choice of name 'io for the temporary in the <.<. method. Look at the line "io.binmode". Which io are we talking about? Is it the io we just assigned, or the result of the io accessor method. Now it happens to be the former, but knowing that requires knowing that the assignment above is what causes the Ruby parser to treat it as a temporary rather than a method send.

Better a Duck Than a Chicken

So in my opinion, it's better to be a bold Duck than a timid Chicken. Chicken typing is weak, and it really doesn't provide much more than the "warm fuzzies". Duck type, and build your specs/tests as you code to provide long-term robustness in dynamically typed languages.

You Can't Judge a Book... Some Mental Traps in Learning Ruby

Rick DeNatale — Wed, 17 Oct 2007 13:01:00 -0400

Bo Diddley, Hoyer
© Andy Field

Quick, in the Ruby expression:

a[10]

What's the class of a?

Many beginning, and intermediate, rubyists whould instinctively say Array! The real answer is that given just this code, you don't know.

Recently, on the rails-talk mailing list there was a discussion of this idea from Jamis Buck. Jamis uses alias_method in ActiveRecord::Base so that he can use shortcuts like:

Person[1]

as a shortcut for:

Person.find(1)

This is particularly nice when playing with ActiveRecord in the rails console, but many seem to think that this should be made part of Rails core, and I don't see a real objection.

Now one objection raised by the folks who answer Array to the opening question is that, since ActiveRecord rows can be deleted, Person[2] might fail even though Person[1], and Person[3] work. The reasoning is that the [] makes it "look like an array" and arrays don't act like that.

To me this is a case of judging a book by looking at it's cover. Something which I strongly suggest needs to be resisted in order to achieve ruby mastery.

Let's have a look at a couple of "can't see past the cover" traps in Ruby.

Trap Number 1: Confusing Calling Interface with Class

Seeing a[2] and thinking Array is an example of this. Just because 99% of the time when you see something "indexed" by an integer, that thing doesn't have to be an Array. It might be an Array, but it could be a Hash, or an ActiveRecord class, or anything which implemented some form of [] method. This is looking at the method invocation as a 'cover.'

Ruby method signatures are quite a bit more flexible or at least different from those of other languages, something which can trip up someone trying to see Ruby from the perspective of their 'native' language. Consider the varieties of parameters which can be passed to Array#[], or String#[], rather than just a indexing methods these can slice and dice the receiver in various ways

Although different classes might all implement a [] method, and while there are likely similarities or common subsets of functionality, each has it's own quirks. This can drive folks expecting type signatures nuts, but it's actually one of the things which gives Ruby it's power, and efficiency of expression.

Some folks go to great efforts trying to pin-down Ruby and make it 'behave' like other languages, but that's a fools errand which works against Rubys strengths. I'd recommend that these folks redirect their efforts towards improving their testing skills.

Trap Number 2: Ignoring the Contents

For better or worse, many Ruby classes provide functions which may not work for all instances. For example, the Range (1..10) is enumerable while (1.0..10.0) is not. This is because some of the methods in range expect the beginning and ending values of the range to implement methods such as #succ in order to determine the next value. Further they implicitly expect that applying #succ successively will get to the end value.

So does this mean that making the range (1.0..10.0) is ilicit or bad? Not if you don't need to enumerate it and only want to do things like check whether or not a value is included in the range.

Some folks on ruby-talk have expressed the opinion that the documentation for Range implies that (1.0-10.0) is not a valid range, because the scope of the requirement for elements to implement #succ is ambiguous. Pragmatically I find the ability to construct enumeration challenged ranges useful.

Further if you take the philosophy which leads to restricting ranges to elements which make the ranges enumerable consider these things:

%w(Now is the time).sort      # Works fine
[:fee, :fie, :foe, :fum].sort # Fails 
['fred', 42].sort             # Fails

Now do we really want to outlaw arrays of symbols, or heterogeneous arrays from Ruby usage because they don't sort?

What do you think?

Refactoring With Continuous Testing - a Guided Tour

Rick DeNatale — Thu, 11 Oct 2007 06:47:00 -0400

Refrigerator Censorship
©

Today on Ruby Fleebie, Frank poses some ruby code to be "rubyized." I took this as an opportunity to do a little exposition of re-factoring under the watchful eye of autotest.

So I've taken Frank's code and run it through the re-factoring machine several times. A word to the 'squeamish' because of the use case, there are a few words in the code which some folks, and spam filters might find mildly offensive, but we're all adults here right?

Now I've got to admit that I really came up with the final solution pretty quickly after seeing the blog post, but then I went back and eased up to it for pedagogical purposes. So if you're in the mood, sit down and lets re-factor some ruby!

The Original Code

Here's Frank's original code:

def remove_insults(input)
  ctr = 0
  input.each do |word|
    word = word.downcase
    if word == "stupid" || word == "moron" || 
       word == "dumbass" || word == "retard"
      i=0
      word.length.times do
        input[ctr][i,1] = "*"
        i+=1
      end
    end
    ctr += 1
  end
  puts input.join(" ").to_s 
end
remove_insults "you truly are a moron sir!".split(" ")

I've split one line (the long if statement) to try to keep the horizontal scrolling down when viewed here.

Getting Ready for Autotest

My first step was to setup a local subversion repository, so that I could go back over my work and tell you about it. Then I set up a project directory structure and imported it.

Autotest want's a particular directory structure, so I set up a project directory with a lib subdirectory to hold the code, and a test directory to hold the testcase. The code also needs to be structured as a class, so I changed the code a bit and put it in lib/civilizer.rb

class Civilizer

  def self.remove_insults(input)
    puts civilize(input)
  end

  def self.civilize(input)
    ctr = 0
    input.each do |word|
      word = word.downcase
      if word == "stupid" || word == "moron" || word == "dumbass" || word == "retard"
        i=0
        word.length.times do
          input[ctr][i,1] = "*"
          i+=1
        end
      end
      ctr += 1
    end
    input.join(" ").to_s 
  end    
end

Civilizer.remove_insults "you truly are a moron sir!".split(" ")

Note that I also set this class up so that it has two methods, remove_insults prints the bowdlerized input, while civilize returns it as a string. This change makes the code testable

Now we need a test case, that goes in test/test_civilizer.rb:

require "test/unit"

require "civilizer"

class TestCivilizer < Test::Unit::TestCase
  def test_case_name
    assert false    
  end
end

More autotest conventions here, we're testing the class Civilizer which lives in lib/civilizer.rb so that autotest can find it, the test case class needs to be TestCivilizer (i.e. the class under test suffixed by Test).

This initial test case is designed to fail, at this stage I'm just verifying that autotest is happy with my setup, and runs the test when either the code under test or the test case changes.

A Real Test Case

The next step is to test the actual code. So I changed the test_case_name method (that clever name was generated by the textmate tc snippet by the way, and I didn't change it) to:

  def test_basic_operation
    assert_equal "you truly are a ***** sir!" , Civilizer.civilize("you truly are a moron sir!".split(" "))  
  end

When I save this, autotest runs the test and it passes. Okay, now that we've got a baseline to refactor against, lets start changing code.

Our First Change

Let's make use of Ruby's Array#include? method and get rid of that if statement with the long chain of ||s:

class Civilizer

  def self.remove_insults(input)
    puts civilize(input)
  end

  def self.civilize(input)
    ctr = 0
    input.each do |word|
      word = word.downcase
      if %w[stupid moron dumbass retard].include?(word)
        i=0
        word.length.times do
          input[ctr][i,1] = "*"
          i+=1
        end
      end
      ctr += 1
    end
    input.join(" ").to_s 
  end    
end

Civilizer.remove_insults "you truly are a moron sir!".split(" ")

Once again, I save this, and autotest automatically confirms that my change didn't break anything.

Let's Throw out a Loop or Two

That loop to generate the replacement string, seems unwieldy and error prone, let's get rid of it. Here's the new code. I'm focusing on just the method here, the rest of the file hasn't changed:

def self.civilize(input)
  ctr = 0
  input.each do |word|
    word = word.downcase
    if %w[stupid moron dumbass retard].include?(word)
      input[ctr] = "*" * word.length
    end
    ctr += 1
  end
  input.join(" ").to_s 
end

Once again we've successfully cleaned up the code a bit, and the test success shows we haven't broken anything.

While we're looking at loops, how about the one which steps through the words. We're initializing a counter before the loop and incrementing it at the bottom of the loop. Smells too much like C if you ask me!

def self.civilize(input)
  input.each_with_index do |word, ctr|
    word = word.downcase
    if %w[stupid moron dumbass retard].include?(word)
      input[ctr] = "*" * word.length
    end
  end
  input.join(" ").to_s 
end

Now this looks more rubyish, but looking at it in retrospect, a better move here would have been to use input.map here with a block which returned either the original nice, or blotted out naughty word, but I didn't think of that at the time. Of course with my tests I could go back and do that, but I'll leave that as an exercise for the interested reader.

Anyway, that if statement in the middle is taking up more than it's share of vertical space, let's fix that by using a statement modifier:

def self.civilize(input)
  input.each_with_index do |word, ctr|
    word = word.downcase
    input[ctr] = "*" * word.length if %w[stupid moron dumbass retard].include?(word)
  end
  input.join(" ").to_s 
end

This code is getting shorter and tidier as we go, although not as short and tidy as that idea of using map, oh well, but keep with me, it's going to end up real short.

def self.civilize(input)
  input.each_with_index do |word, ctr|
    input[ctr] = "*" * word.length if %w[stupid moron dumbass retard].include?(word.downcase)
  end
  input.join(" ").to_s 
end

I don't see any need for a separate assignment statement to downcase the input, so I moved that to the argument of include?, still shorter, but hang on.

Time For Some More Tests, and a Shift in Strategy

We've gotten to this point without changing any testcase code. I've been using the testcase to ensure that I haven't changed the code in a way that would make it fail to meet the original 'specification.

Let's revisit the testcase now. It's a pretty simple test case, how about some variations. Here's a new test method I added to test/test_civilizer.rb:

def test_should_find_multiple_words
  assert_equal  "With all due respect, you must be a ******, you *****!", 
         Civilizer.civilize(
                "With all due respect, you must be a retard, you moron!".split(" "))
end

I've reformatted this a bit to try to keep it narrower for the blog presentation.

Finally, when I save this, autotest informs me that the test has failed, a little debugging reveals that the problem is those pesky punctuation characters. That String#split method is limiting us to splitting words on spaces.

Now one way to fix that would be to use a regexp instead of a string as the argument to String#split, but why not just use a regexp to implement the Civilizer, here's the new sleek version of the civilize method:

def self.civilize(input)
  input.join(" ").gsub(/\b(stupid|moron|dumbass|retard)\b/) {|match| '*' * match.length}
end

We've gotten the body of the method down to a one liner, and we now properly handle punctuation!

The Value of [TB]DD

Let's add another test:

def test_should_ignore_case
  assert_equal "*******!", Civilizer.civilize("Dumbass!")
end

Oops! this test fails. Our original tests didn't exercise the use of lowercase in the original code.

This just shows that even test infected developers are human. Actually if we had developed the original code in a test driven style, we wouldn't have invoked lowercase until we'd written a test case to motivate it.

Another useful tool to talk about putting in the arsenal is a coverage tool like rcov which profiles your running tests to show how much of the code under test is being exercised, although in this case, it wouldn't have shown the problem

Anyway, let's fix the problem, we just make the regexp case insensitive:

input.join(" ").gsub(/\b(stupid|moron|dumbass|retard)\b/i) {|match| '*' * match.length}

All it took was one little 'i' to fix this bug. Now autotest is once again showing us the green light.

Is the Specification Right?

I've been ignoring it all along, but having the caller split the input before giving it to the Civilizer has been bothering me even way before I changed the implementation to using gsub with a regexp, and since then, that code to 'unsplit' it has been sticking out like a sore thumb. So, after switching from my consultant hat to my client hat and having a quick conference, "we've" agreed to change the interface so that the parameter is a simple string.

Having agreed to this specification change, let's change the specification. What do we change? The testcase code of course, this is the point of test-driven design (or behavior driven design for you Sapir–Whorf adherents), whether you call them tests or something else, they are really specifications.

Without further ado, here's the new spec:

require "test/unit"

require "civilizer"

class TestCivilizer < Test::Unit::TestCase
  def test_should_find_one_word
    assert_equal             "you truly are a ***** sir!" , 
          Civilizer.civilize("you truly are a moron sir!")  
  end
  
  def test_should_find_multiple_words
    assert_equal              "With all due respect, you must be a ******, you *****!", 
           Civilizer.civilize("With all due respect, you must be a retard, you moron!")
  end
  
  def test_should_ignore_case
    assert_equal           "*******!", 
        Civilizer.civilize("Dumbass!")
  end
end

I've used slightly unusual formatting here too, which makes it easy to visually compare the expectation with the input.

In good TDD style, we save this test before we change the code to meet the new specification. As we expected, autotest shows us a red light. This is an indication that our changed tests are good. Now let's change the code:

class Civilizer

  def self.remove_insults(input)
    puts civilize(input)
  end

  def self.civilize(input)
    input.gsub(/\b(stupid|moron|dumbass|retard)\b/i) {|match| '*' * match.length}
  end    
end

Civilizer.remove_insults "you truly are a moron sir!"

Meeting the new spec just required getting rid of the join in civilize, and the split in the final statement which gets executed when we run this code for 'real' as opposed to testing it. Once again, the feedback from autotest goes green.

Test Code Deserves to Be Beautiful Too

At this point I stepped back and tidied up the test code. I wanted to make it DRYer, so I introduced a private method to move the repeated code out of each test case:

require "test/unit"

require "civilizer"

class TestCivilizer < Test::Unit::TestCase
  def test_should_find_one_word
    assert_civilizes "you truly are a moron sir!", 
                     "you truly are a ***** sir!" 
            
  end
  
  def test_should_find_multiple_words
    assert_civilizes "With all due respect, you must be a retard, you moron!",
                     "With all due respect, you must be a ******, you *****!"
  end
  
  def test_should_ignore_case
    assert_civilizes "Dumbass!",
                     "*******!"
  end 
  
  private
  def assert_civilizes(input, expected)
    assert_equal expected, Civilizer.civilize(input)
  end
end

I don't know about you, but I like the way this code looks. I made a conscious decision on the order of the arguments. Normally assert* methods first argument is what's expected, but here it's the second. The decision on the argument ordering was tied up in what to name the method. I read it as assert_civilizes this [to] that. I probably spent a full minute or two pondering this, probably the most 'agonizing' decision in this exercise. If I kept on with this particular 'project' that might change, no code is sacred!

Another Test, Another Spec Change?

The last test I wrote was this:

    
def test_should_treat_parts_of_words 
  assert_civilizes "You, sir are a retarded moron.",
                   "You, sir are a ******ed *****."
end

I've left this as a proposed spec change. It fails because one of the bad words is not bracketed by word boundaries. This would be easy to make work, just get rid of the two '\b' anchors in the regexp, but I'm not sure that it's a good idea, and neither is the 'client'. Should 'stupidity' be considered a bad word? or oxymoron?

I've raised it with the 'client' and I'm still waiting to hear back.

What Have We Learned?

The whole exercise, involving some 20 subversion commits, probably took me 30-45 minutes, far less time than writing this article.

I hope that those of you who have stuck this out to the end found it interesting and perhaps useful. I think it illustrates some key points about test-driven design, rapid iterative development, and dynamic languages:

Having and maintaining testcode as you go provides value by helping ensure that you aren't wandering away from the goal.
Good test code, particularly when run automatically, serves as a more powerful substitute for the type checking done by compilers of statically typed languages, it causes both interface and logic errors to cause fast failures which can usually be quickly corrected.
Just because code exists doesn't mean it's sacred. I'm just as happy, probably happier when I throw old code away and replace it with better code, as long as I'm making progress. Once again testing is a big boon to this goal.