After a few minutes he stands up. I know to turn down the music. He whispers into my ear. I nod in agreement and mouth back a response.

Flow understands my frustration with testing individual methods outside any greater context or usage scenario.

RSpec is a beautiful tool. Leaps and bounds ahead of the standard testing framework built into Rails. It does this, I believe, by allowing you to use more natural language. But it can be be misused. Which is actually closer to abuse, because unless you’re paying respect to flow, you’re fucking yourself.

Don’t test methods outside of the context in which they should be used. It doesn’t mean shit to the person reading your code — even if that person is you.

Your program is a play. Your objects are actors. You are the writer and director. You say action! You say cut! You know all the lines, but it’s not your job to voice them. You assign those roles to your actors, and they carry it out much better than your sorry ass ever could.

Context. Acknowledge it. If your tests look like this:

describe 'An InterestList' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'upon creation' do
 
    it 'should not be a new record'
    it 'should be empty'
    it 'should report having zero Interest objects'
 
  end
 
  describe 'when adding a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
    end
 
    it 'should answer true'
 
  end
 
  describe 'with one ProductInventoryPrototype in it' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
    end
 
    it 'should not be empty'
    it 'should report having one interest'
 
  end
 
  describe 'removing a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
    end
 
    it 'should answer with the item when that item is removed'
 
  end
 
  describe 'after removing a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
      @interest_list.remove(@cheese)
    end
 
    it 'should be empty when that item is removed'
    it 'should report having zero items'
 
  end
 
end

You’re fucking with the laws of nature, and you will be smitten.

What’s wrong with it? The

#before

code is reinitializing all the steps you’ve just accomplished.

Make it look like this.

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
 
      describe 'It now has one product in it.' do
 
        before(:each) do
          @interest_list.add(@cheese)
        end
 
        it 'It should not be empty.'
        it 'It should report having one interest.'
 
        describe 'Now we remove a ProductInventoryPrototype.' do
 
          it 'It should answer with the item when that item is removed.'
 
          describe 'After removing a ProductInventoryPrototype,' do
 
            before(:each) do
              @interest_list.remove(@cheese)
            end
 
            it 'it should be empty when that item is removed.'
            it 'it should report having zero items'
 
          end
 
        end
 
      end
 
    end
 
  end
 
end

Of primary importance is a subtle point. I didn’t illustrate it in the two examples above, but I will now:

Before:

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
      it 'It should not be empty.'
      it 'It should report having one interest.'
...

After:

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
 
      describe ' At which point' do
 
        it 'it should not be empty.'
        it 'it should report having one interest.'
...

On the surface it’s just another level of nesting. After meditation, you realize you are first testing the object’s answer to your message. Second, you are testing the state of the universe after that action is made. The difference is subtle, but important. If you don’t understand the importance, recall the indifference you felt when you first saw RSpec: it’s Rails’ standard test framework with different words thrown in.

You were wrong then and you’re wrong now.

Words offer the means to meaning, and for those who will listen, the enunciation of truth. – V

If an object’s answer to the message passed violates expectations, flow stops. You know, not that a method is broken, but that flow is broken.

Of secondary importance is that your

#before

methods are no longer redundant.

The result of running your tests now looks like:

When working with an InterestList, it must first be created. It should not be a new record. (Not Yet Implemented)
When working with an InterestList, it must first be created. It should be empty. (Not Yet Implemented)
When working with an InterestList, it must first be created. It should report having zero Interest objects. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. To which it should answer true. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. It should not be empty. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. It should report having one interest. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. It should answer with the item when that item is removed. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. After removing a ProductInventoryPrototype, it should be empty when that item is removed. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. After removing a ProductInventoryPrototype, it should report having zero items (Not Yet Implemented)

This is easier to read and understand than a series of isolated tests. You’re made aware of the context in which each test is being run, which is priceless when you’re attempting to understand the system from a high level.

Congratulations. You are no longer a moron coding outside the realm of the context in which your code lives.

I am an abstract class. My objects represent things that are discrete and map to a number line. My instances can be compared with < and >.

The documentation is written from the perspective of the object. Brilliant.

It sounds epic, poetic and a little corny, but it’s how I think. And it’s how I program. I don’t like solving complicated tasks. I like breaking complicated tasks into many smaller, manageable tasks and solving those. Once each smaller task is solved, I script a dialog between them to achieve the desired effect.

Imagine a movie in which there was only one actor. That actor would have to play the good guy, the bad guy, the dame, all supporting characters and the director’s cameo. Such a movie would have to be classified as a psychological thriller, because it would take an insane person to be able to keep everything together. While the move may have been fun to make (for a sadist), few members of the audience would be able to follow the movie all the way through.

So as your audience leaves the theater, as your programmers leave your project, you realize that being clever and complicated may not have been the best choice.

No, I don’t think I’m a bad programmer. I think I’m a programmer with taste, my own style and a little class. Instead of banging the keys for eight hours, I spend an hour drawing with a pen and paper. Then I spent twenty minutes staring at the wall. I get up, walk around and stretch my legs. I take a piss. When I come back to the computer I have an intricate web of many, simple objects with obvious names and well-defined behaviors. At the end of the day I’m proud of the code I wrote.

And most importantly, I don’t dread coming back to it the next day.

Notice: This is part two of a two-part post. Read the first post if you haven’t already.

All right! We’re taking the experience we gained from our last endeavor, and we’re putting it on rails.

First off, let’s think about our goal — what are we trying to accomplish? How does it flow? What does it look like? In this case it’s pretty simple. It should probably look something like this:

1

product.evaluate('cost')

That’s concise, and it looks good. But it’s not the whole story. So let’s think some more.

We know we have products, as shown above. We have rules, presumably shown above as the argument to the evaluate method. What about variables? I don’t see those in the code above.

Before we go any further, let’s hash out a quick drawing to show our understanding of our objects and their relationships. … Done!

Pretty basic right now, but let’s talk about it.

Rules have many products have many variables. Interesting. When you say it like that, it almost doesn’t make sense. A rule has many products? What would that look like code-wise?

1
2
3
4
5

class Rule
 
  has_many :products
 
end

Hmm… looks perverted, (a rule has products?) but let’s keep going with some pseudo code.

1
2

product = rule.products.create(:name => 'Cheese')
product.variables.create(:name => 'cost', :value => 2)

I dig the second part:

1

product.variables.create(:name => 'cost', :value => 2)

So let’s keep that in mind as we progress.

But what about rule.products? Our first line of code tells us that products should be able to evaluate rules, so there’s gotta be some connection between the two. What do we know least about? I’d probably say the rule objects themselves right now, so let’s take a stab at designing one.

What are rules? Well, let’s look at a real-life example.

1

(x + y) * z

What do you see? … You could say you see a simple math formula. Perhaps, if you recall David West’s explanation of self-evaluating objects, you see an array of operators and variables. Before I tell you what I see, I’d like to say that what I see is based off my previous experience handling self-evaluating objects. That said, I see a string.

That’s it. A simple string.

1

"(x + y) * z"

It’s so simple it’s obvious. And obvious things are often the most difficult thing to see. Now that we know what a rule is, let’s try and define it using object parlance. What can a rule do? What’s it comprised of? What are its responsibilities? Who must it collaborate with to get its job done?

The first thing I see is a definition. Every rule has a definition. I suppose also, that a rule could have a name; it would certainly make distinguishing one rule from another easier.

So now we have named rules with definitions. Let’s see some potential code.

1
2

rule = Rule.new(:name => 'Product cost')
rule.definition = '(cost * tax) + cost'

Looks pretty clean. What next? Oh, that’s right, the obvious: a rule can evaluate itself. Ah, there’s the meat. Now we have a new, non AR-inherited responsibility: evaluation. Let’s take a look..

1
2
3
4
5
6
7

class Rule < ActiveRecord::Base
 
  def evaluate
    eval(definition)
  end
 
end

That’d be nice if that’s all we had to do. Unfortunately it’s not. Executing that as is will raise an error. If we think back to our earlier work, we did simple string replacement to get the proper values into our definitions.

1
2
3

def evaluate
  definition.gsub('uh oh!', "we're missing something")
end

Things just got interesting. Our rule doesn’t have access to the variables needed for substitution in its definition. Hmm… let’s stop and think for a moment.

Rules, products and variables. Products have variables for use in rules. A rule’s definition must have its variables substituted out for actual values. What does that look like?

1
2

rule = Rule.new(:name => 'Product cost', :definition => '(cost * tax) + cost')
rule.evaluate(product)

Hmm… that could work. A rule requires a product be passed to it to gather the contents of its variables.

Let’s try that.

1
2
3
4
5
6
7
8
9
10
11

class Rule < ActiveRecord::Base
 
  def evaluate(product)
    product.variables.each do |variable|
      definition.gsub!(variable.name, variable.value)
    end
 
    eval(definition)
  end
 
end

Not bad. A rule can evaluate itself in the context of a given product’s variables. This will work provide the product passed has all the variables required of the rule, and vice versa.

Of course, this model doesn’t look like our original diagram, and that’s okay. Things rarely go according to plan. Let’s review what we’ve done so far.

Rule objects stand alone. They are named mathematical definitions that evaluate in the context of a given product. (In reality, ‘product’ could be any object that responds to a variables method.)

So our end result is now:

1

rule.evaluate(product)

That’s the opposite of what I originally proposed (product.evaluate(rule)), and I’ll be honest; it feels weird. On the bright side, this solution is much simpler than my original Rails version. However, I still like the feel of:

1

product.evaluate(rule)

But hey, whatever works, right? There’s just one more thing… rules within rules. Ah, interesting. What would that look like?

Well, actually, it shouldn’t look any different than what we have now:

1

rule.evaluate(product)

The above should still give us a single number. So it’s not the end-result (API) code that will be changing, it’s our internal code that will change. But how? Let’s take a look at our definition.

1

(cost * tax) + cost

The part in parentheses represents the tax of our product. So we’re really saying:

1

tax + cost

But now we’ve run into a problem. Is tax a rule or a variable? Currently there’s no way to know the difference. How can we solve that? We need to be able to differentiate between rules and variables. Or at least, I think we should.

We could not, and simply perform blind string replacement, replacing everything in our definition with every match in our variables method. The result is a definition where the only non-numeric or operator characters must be rules. But that sounds pretty flimsy. I can easily see there being a tax variable and a tax rule. So let’s make clear the difference between rules and variables.

1

r:tax + v:cost

Heh, that works. It changes our replacement around a bit, but not too much.

1
2
3
4
5
6
7

def evaluate(product)
  product.variables.each do |variable|
    definition.gsub!('v:' + variable.name, variable.value)
  end
 
  eval(definition)
end

Okay, so we can still evaluate our variables. But what about other rules? What do we do when we encounter another rule? Let’s try scanning the string for instances of r:xxx, do a find for that rule name, and then call evaluate on it…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

  def evaluate(product)
    # Operate on a copy of the definition so the original is open to variable
    # changes.
    evaluated_definition = definition.dup
 
    # Recursively evaluate any rules in the definition.
    evaluated_definition.scan(/r:\w+/) do |match|
      evaluated_definition.gsub!(match, Rule.find_by_name(match[2, match.length]).evaluate(product).to_s)
    end
 
    # Replace variables in the definition with values provided by product.
    product.variables.each do |variable|
      evaluated_definition.gsub!('v:' + variable.name, variable.value.to_s)
    end
 
    # Evaluate the fully-substituted string.
    eval(evaluated_definition)
  end

Let’s run this! (You’ll need to download the complete Rails app and follow the directions in doc/readme.)

1
2
3
4
5
6
7
8
9
10
11
12

rule = Rule.new(:name => 'Product cost')
rule.definition = 'r:tax + v:cost'
rule2 = Rule.new(:name => 'tax')
rule2.definition = '(v:cost * v:tax)'
rule.save
rule2.save
 
product = Product.new(:name => 'Cheese')
product.variables.create(:name => 'cost', :value => 10)
product.variables.create(:name => 'tax', :value => 0.05)
 
rule.evaluate(product) # => 10.5

Scha-weet! But wait! Do I see a recursive function in there? I sure do! Let’s deconstruct it.

We have a rule. We scan its definition for strings that look like r:xxx. Once found, we perform a global string replacement on it, using r:xxx as the pattern match, with the substitute string being the return value of calling evaluate on the rule referenced by r:xxx.

Was that confusing? Don’t worry if it was. Recursion can be pretty difficult to wrap your head around, especially if you didn’t write it. If you’re determined to understand, I suggest reading it several times, line by line, very slowly. It may also help to add some puts messages in there and run it a few times in IRB. That way you can “watch” the recursion magic.

Anywho, just know that it works, and will go as deep as you need it to.

So there we have it! A fully Rails-based self-evaluating monster that will slay accountants everywhere! Okay not really, but it’s pretty cool nonetheless, right?

As excited as you may be, don’t lose yourself. It still only works in console. If you choose to use a solution like this you’ll still need to build an interface for people to use it. There are some other small issues, too. Rule names, for instance. The way the evaluate method is written, you can’t have multiple rules with the same name. Well, you could, but you’d only ever be able to access the first one. There’s also the rigidity of relationships. Product specifically defines its relationship to variables, and there’s still the (I consider) perversion of calling rule.evaluate(product). I’d love to see product.evaluate(rule).

That, however, is an exercise I leave to you. ;)

Oh, before I go, here’s the complete code listing:

rule.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class Rule < ActiveRecord::Base
 
  # Answers with a BigDecimal after recursively solving rule definitions,
  # performing variable replacement and finally evaluating a flat formula.
  #
  def evaluate(product)
    # Operate on a copy of the definition so the original is open to variable
    # changes.
    evaluated_definition = definition.dup
 
    # Recursively evaluate any rules in the definition.
    evaluated_definition.scan(/r:\w+/) do |match|
      evaluated_definition.gsub!(match, Rule.find_by_name(match[2, match.length]).evaluate(product).to_s)
    end
 
    # Replace variables in the definition with values provided by product.
    product.variables.each do |variable|
      evaluated_definition.gsub!('v:' + variable.name, variable.value.to_s)
    end
 
    # Evaluate the fully-substituted string.
    eval(evaluated_definition)
  end
 
end

product.rb

1
2
3
4
5

class Product < ActiveRecord::Base
 
  has_many :variables, :dependent => :destroy
 
end

variable.rb

1
2
3
4
5

class Variable < ActiveRecord::Base
 
  belongs_to :product
 
end

schema.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ActiveRecord::Schema.define(:version => 3) do
 
  create_table "products", :force => true do |t|
    t.column "name", :string
  end
 
  create_table "rules", :force => true do |t|
    t.column "name",       :string
    t.column "definition", :string
  end
 
  create_table "variables", :force => true do |t|
    t.column "product_id", :integer
    t.column "name",       :string
    t.column "value",      :decimal, :precision => 8, :scale => 2
  end
 
end

Have you ever written a program that sells products? Did you have to write the pricing rules for those products? Was it difficult? Time-consuming? Constantly changing? Screwing up your code and frustrating you to no end? Did people dip their grimy hands into your beautiful algorithm by asking you to make (gasp!) exceptions for this or that product? And don’t forget that special affiliate that everyone loves! He gets an extra percentage on top of everything else.

Stop. Breathe. Calm down. Everything will be okay. Object thinking to the rescue. Introducing the self-evaluating rule.

David West, author of Object Thinking, describes a self-evaluating rule thusly:

…think of a self-evaluating rule as an expression in the form of an ordered sequence of operators, variables, and constants. When the rule is asked to evaluate itself, each of its variables is asked to instantiate itself (become a known value), after which the rule resolves itself (applies the operators in the expression) to a final value — a Boolean true or false, for example.

Let’s take a stab at that, shall we? (You can paste the whole thing into IRB if you want to follow along.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class SelfEvaluatingRule
 
  attr_accessor :price, :tax
 
  def evaluate
    (@price * @tax) + @price
  end
 
end
 
rule = SelfEvaluatingRule.new
rule.price = 100
rule.tax = 0.05
rule.evaluate # 105.0

Interesting. Okay, not really. It might resemble something you’ve written before, but instead of calling the evaluate method, you called price (or something similar).

Let’s think for a moment… What we have is a collection of variables, and a hard-coded formula that puts those variables to use. Right now it’s pretty crappy code. How can we make it better?

1. Enter variable names and values dynamically
2. Enter arbitrary rules
3. Evaluate changes to our variables and rules without rewriting code

Those sound like solid goals. We’re going to take another stab at it, but before we do, I’d like to show you something that might be new to you…

First, fire up IRB.

Now, type the following, then hit enter:

1

eval "1 + 1"

What did you get? 2? Pretty cool, eh? This simple trick forms the basis of everything else we’re going to do.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class SelfEvaluatingRule
 
  attr_accessor :price, :tax
 
  def evaluate(rule)
   eval(rule.gsub('price', @price.to_s).gsub('tax', @tax.to_s))
  end
 
end
 
rule = SelfEvaluatingRule.new
rule.price = 100
rule.tax = 0.05
rule.evaluate('(price * tax) + price') # 105.5

Not bad. We can now write dynamic rules that accept any values for price and tax, and use them in any formula we want, without having to rewrite our code. So let’s cross out number two on our list of enhancements.

Now let’s tackle those variables…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class SelfEvaluatingRule
 
 def initialize(rule)
   @rule = rule
 end
 
 def variables=(variables)
   @variables = variables
 end
 
 def evaluate
   @variables.each do |var, value|
     @rule.gsub!(var, value.to_s)
   end
 
   eval(@rule)
 rescue
   raise StandardError, 'Failed to evaluate'
 end
 
end
 
rule = SelfEvaluatingRule.new('(price * tax) + price')
rule.variables = { 'price' => 100, 'tax' => 0.05 }
rule.evaluate # 105

See what happened there? We extended our object by giving it the ability (more at responsibility) of maintaining an arbitrary collection of variables. We also specify the rule, though now we’re doing it during instantiation. Is this the best way to do it? Probably not; I can think of at least one more enhancement I’d make to the way rules are handled. What about you? Do you see room for improvement? I encourage you to challenge yourself and make it better!

With this last iteration we have completed all three of our stated goals. Not bad for just a few minutes work, eh?

So there you have it: the basics of a self-evaluating object. It sure feels like we’ve come a long way, but there’s more. Lots more. Currently we’re working with a single rule. However, chances are good that if you have need to write one rule, you’ve need to write many rules. And of course, we’ve been playing around in IRB. What if want to save rules and use them later? Perhaps attach those rules to other objects? There’s a world of possibilities out there!

I’ve written a solution in Rails that handles multiple rules, and even evaluates rules within rules. It’s a pretty neat solution. Though, after writing this post, I’m certain it can be cleaned up considerably.

I’m not sure what part two of this post will contain… whether I will simply post and explain the code I’ve already written, or try to refactor it first and then post. Time shall tell.