Archive for the ‘Testing’ Category

« Older Entries

Getting a project off the ground with TDD and Cucumber

Sunday, June 21st, 2009

RSimpy

I am currently wrapping up an initial release of a new gem that wraps the Simpy.com API. I like social bookmarking and used delicious for years before switching to Simpy as my primary service. Simpy is not the biggest online bookmarking service, but I’ve decided to use it for reasons I will outline in another post. In any case I’ve put together a gem that wraps the API with the help of Httparty. It actually turned out much simpler than I expected it to be, httparty did all of the heavy lifting, but again that is for another post.

So, I have a functioning gem for Simpy, now I want to make something useful with it. The reason I made the gem was to simplify my bookmarking which is overall a mess on multiple workstations in multiple locations. Since I’ve recently been getting familia with cron, I’ve decided to make a script to store urls locally and use cron to run a script that pushes a file of pages to Simpy.

As I touched on briefly, I’ve been unhappy with all my previous bookmarking solutions thus far. This time I want to make it, dead simple. I don’t want to have to enter any additional information if I don’t want to, just a url and have it go on it’s merry way. However to post the link, I will need to at least have the page title. Pulling a page title from a url is really outside of the scope of RSimpy. Ruby makes it fairly simple to do, but I don’t want to isolate the functionality to a script. Ruminate to the rescue, but what is Ruminate?

Ruminate

Well the answer to that question is that I’m not really sure. A few months back, I made a gem with jeweler called ruminate with the description “Extracts statistics from html documents”. Actually, I’m not really sure what I originally had in mind when I setup this gem, but it will be useful now since I want to extract at least the page title. Once I get the ability to extract a page title, I can make a script that is simply glue code to put Ruminate together with RSimpy and voila!

Bootstrapping the project

I have a vague idea of something that I want Ruminate to do, that is I want to be able to query a url to return the title of the page. It’s obviously not the entire purpose of the gem, but I’m sure that will be lots of other bits that will come together in time.

The question is, How do I kickstart this project with TDD to get it off the ground?

Programming by Intention

Programming by intention is the practice of writing code, while pretending that any methods or classes you might reference already exist and operate in the way that you reference them. It’s a great way of uncovering a simple intuative API that you might otherwise would have missed.

I’ve seen it described in two books, first in Everyday Scripting with Ruby, from The Pragmatic Bookshelf. Secondly, it’s used in an excellent book I’m currently reading called Test Driven from Manning.

There are a number of sources stating that TDD is about design first and automated testing is a nice by-product. In my limited experience with TDD, programming by intention is the crux of this design, and by extension the primary purpose of TDD.

Cucumber

One of the things that I really like about cucumber is that you can plainly state your intent and important bits of your feature focused domain in plain English and match that up to executable code. To describe the ability of Ruminate to grab the title of a url, I made the following test:

Feature: Get Page Title
  In to get the page title
  A user of ruminate
  Will request a page title
 
  Scenario: Requesting the title of a page from the page
    Given the url "http://www.google.com"
    When I execute the request
    Then the "title" should be "Google"

I let cucumber auto-generate the regular expression blocks and came up with the following steps:

 
Given /^the url "([^\"]*)"$/ do |url|
  @url = url
end
 
When /^I execute the request$/ do
  query = "Select title from #{@url};"
  @result = chew query
end
 
Then /^the "([^\"]*)" should be "([^\"]*)"$/ do |msg, value|
  assert_equal value, @result
end

As you can see I’ve decided to try out a sql like syntax for the tool. I thought it sounded interesting, we’ll see if I keep it. In any case, I now need to make this test pass with the help of a mixin, that I’m including in features/support/env.rb

# features/support/env.rb
$LOAD_PATH.unshift(File.dirname(__FILE__) + '/../../lib')
require 'ruminate'
include Ruminate
 
require 'test/unit/assertions'
 
World(Test::Unit::Assertions)
# lib/ruminate.rb
require 'query_parser'
require 'engine'
 
module Ruminate
  def chew query
    parser = Ruminate::QueryParser.new
    query_object = parser.parse query
    engine = Ruminate::Engine.new
 
    engine.execute query_object
  end
end

Here I’ve used the mixin to split the method into to operations and encapsulated each of these into a class. Programming by intention has now generated a mixin and two classes that have a clean separation of responsibilities. Here is the simplest thing that could possibly work to make the feature pass.

# lib/query_parser.rb
module Ruminate
  class QueryParser
    def parse query
      nil
    end
  end
end
# lib/engine.rb
module Ruminate
  class Engine
    def execute query
      "Google"
    end
  end
end

Obviously this isn’t the final code, but it gives us the minimal implementation to pass the feature. Now I can turn to Test::Unit and shoulda to flesh out tests and implementations to make it work in a more useful manner.

What I really wanted to show here is how to get a TDD project started. I know that I’ve struggled with this in the past. What to test first can be a big decision, one that can create a type of code writers block. When this moment happened where everything just came together and I was able to generate a mixin and two orthagonal classes with a simple feature, I wanted to write it up.

The Code

The full code for this example can be found on github with the tag simplest-thing-that-could-possibly-work

Tags: , ,
Posted in Ruby, Testing | No Comments »

Getting started with ISpec and Ioke

Saturday, May 16th, 2009

Searching for common ground

Now that I have downloaded and built the source for Ioke E, I wanted to start using it. After all, I made a goal back in January to start using it, but as of yet had failed to follow through with it. Oh sure, I’ve been keeping up with the blog posts and looking at it from time to time, but really hadn’t made any steps to speak of. Until today.

I think that what I really needed was to find some common ground with Ioke. Something I could call familiar and the branch out from. ISpec is where I found it. I found it in two ways really, first in the ability to write specs to test my knowledge of Ioke coding and also in reading existing specs that have been written. These specs run when you download and build Ioke from source, which incidentally, is a painless process I would recommend to any interested.

So what’s next?

Note:I’ve pushed my code out to github tagged as start_ispec

I started out by creating a directory for my project with subdirectories for src and test

~/working $ mkdir ioke-examples
~/working $ cd ioke-examples
~/working/ioke-examples $ mkdir src test

Next I created my first spec as test/bag_spec.ik.

use("ispec")
use("src/bag")
 
describe("Bag",
  it("should have the correct kind",
    Bag kind should == "Bag"
  )
 
  it("should return the values in assigned cells",
    Bag name = "cheeze"
 
    Bag name should == "cheeze"
  )
)

There is nothing really interesting being tested here, the behavior is that of pretty much any Ioke object. The only thing of note is that the use directive is from the root of the project so to specify bag.ik which as a relative path from the spec would be ../src/bag.ik, was actually just src/bag.ik. Next I made an implementation src/bag.ik as

Bag = Origin mimic

This passed. Next I started making a another spec and class. Thinking that I would keep going with this path of thought. I made test/evaluator_spec.ik as:

use("ispec")
use("src/evaluator")
 
describe("Evaluator",
  it("should have the correct kind",
    Evaluator kind should == "Evaluator"
  )
 
  describe("Evaluation",
    it("should evaluate nil as nil"
      Evaluator evaluate nil should == nil
    )
  )
)

and src/evaluator.ik as 

Evaluator = Origin mimic
 
Evaluator evaluate = method (
 
)

This results in the following

~/working/ioke-examples$ ispec test
.P..
 
Pending:
 Evaluator Evaluation true (Not Yet Implemented)
 
Finished in 0.26 seconds
 
4 examples, 0 failures, 1 pending

Pretty neat that it sees it as a pending implementation. Overall this was a great success, ISpec was working, but something was still nagging me.

Something isn’t right

Maybe it’s my Ruby roots, maybe it’s that I was being picky but having to specify the source directory when referencing bag.ik and evaluator.ik just didn’t seem right. I needed something like test_helper.rb in Ruby.

I looked around for a while and finally started digging into the test directory for Ioke, which is a great reference for the language. Three cheers for TDD! After a little fiddling I found that I could make a file called test/helper.ik as follows:

use("ispec")
System loadPath << "src"

This automatically loads ISpec and also adds the src directory to System loadPath, which is a list of the locations that Ioke will look for files in the use directive.

This allowed me to change use directives at the beginning of my specs to something like: 

use("test/helper")
use("bag")
 
describe("Bag", ....

Comfort level

Now that I have my ISpec basics up and running, I hope to be playing more with this interesting language. Hopefully you will be seeing more Ioke posts here soon.

Tags: ,
Posted in Ioke, Testing | 1 Comment »

Functional Testing Rails with a Session variable

Wednesday, April 8th, 2009

I recently had a frustrating situation while using the session to store the id of the current user. I was writing functional tests for my app an was using code based on the acts_as_authenticated plugin. My problem was that I was trying to set the id in the session before I made the get request and for whatever reason it wasn’t working and I kept getting redirected to the login screen.

Now I was not using the acts_as_authenticted_plugin, so

1
2
3

  def setup
    login_as :quentin
  end

was not available to me. Instead, I tried doing something along the lines of this, which mimics what it seemed that the authenticated_test_helper was doing:

1
2
3
4

test "that a request for index will be sucessful" do
  @request.session[:identity_id] = 1
  assert_response :success
end

but that didn’t work either. So I looked around a number of places and finally came across the newly shiny Rails Guide for functional testing. There, before my eyes, was the answer.

The get method kicks off the web request and populates the results into the response. It accepts 4 arguments:

  • The action of the controller you are requesting. This can be in the form of a string or a symbol.
  • An optional hash of request parameters to pass into the action (eg. query string parameters or post variables).
  • An optional hash of session variables to pass along with the request.
  • An optional hash of flash values.

    • Four arguments! not only the two I’d used (action and params), but 4. Armed with this knowledge, I soon got my test to pass. Here is a sample passing test

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

    def setup
  @identity = Identity.make
end
 
test "that a request for index will be sucessful" do
   get :index, nil, build_session_hash_for(@identity)
   assert_response :success
end
 
protected
  def build_session_hash_for identity
    {'identity_id' => identity.id}
  end

    Hopefully this will help out someone else who may run into this issue.

    Tags: , ,
    Posted in Rails, Testing | No Comments »

    Simple mocking with RhinoMocks

    Monday, January 19th, 2009

    Mocking frameworks and me

    Until recently, mocking frameworks never really clicked in my mind.  I understood their purpose, however the terminology really didn’t fit with the idea of mocking to me and the tentative grasp I had on the concept would fall apart when I tried to get the mocking framework up and running in my tests.  So for a while I was mocking by hand.   Recently, I have been using Rhino Mocks successfully.  It has finally made sense to me, and I will mock by hand no longer.

    The biggest mistake that I made in trying to understand the Rhino Mocks framework was thinking that all the mocking framework was doing was playing stunt double for the object that it was mocking.  Rhino Mocks doesn’t just ’stand in’ for the object you wish to mock, it will verify that methods are called on that object, giving you additional testing power.   Once I understood this, it explained the replay and verify terminology I would see in the examples, and things started to fall into place.

    Once I had my epiphany about the usage of Rhino Mocks, I went to use it and I was stymied again.  I saw that I needed to create a mock object from an interface, but how?   And what is the difference between a StrictMock and a DynamicMock?   It wasn’t until I read this that I was able to begin actually using the framework.

    As it turns out, the difference between a StrictMock and a DynamicMock is pretty simple to understand.  As we have seen, a core concept is the recording, playback and verification of method calls on the mock objects.  Well what happens if your System Under Test calls a method on the mock object that the mock wasn’t expecting?  What happens in this situation is the difference between Static and Dynamic Mock objects.  A StrictMock is just that, strict.  If a method gets called on a strict mock that it wasn’t expecting, it will let you know with red.  Now the terminology here still get me sometimes.  I think of the opposite of strict to be lax, forgiving or maybe flexable.  Likewise, I think of the opposite of dynamic to be static.  In this case, the opposite of strict is in fact, dynamic.  If a method is called on a dynamic mock that you didn’t tell it to expect, it just keep trudging along.  That’s not to say that it will necessarily return somehting valid, but the fact that the method itself  was called isn’t going to turn your test from green to red.

    Making a mockery

    So how do you actually use this beast?  Well it’s quite simple really, once you have all the pieces in place.   Having an understanding of interfaces and dependency injection will help get you off the ground here.  Let’s set up a couple of classes.

    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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

    public class DeathTrap : IDrivable
{
  private int _speed;
  private bool _brakesFunctional;
 
  public DeathTrap()
  {
    _speed = 0;
    _brakesFunctional = true;
  }
 
  public void Accelerate(int amount)
  {
    _speed = _speed + amount;
    // Something really time consuming and irrelevant here
  }
 
  public bool Brake(int amount)
  {
    // Something really time consuming and irrelevant here
 
    if (amount == 21)
    {
      _brakesFunctional = false;
    }
 
    if (_brakesFunctional == false)
    {
      return false;
    }
    _speed = _speed - amount;
  }
}
 
public interface IDrivable
{
  void Accelerate(int amount);
  bool Brake(int amount);
}
 
public class Driver
{
  private IDrivable _prideAndJoy;
 
  public Driver(IDrivable prideAndJoy)
  {
    _prideAndJoy = prideAndJoy;
  }
 
  public void Go(int amount)
  {
    _prideAndJoy.Accelerate(amount);
  }
 
  public bool Stop(int amount)
  {
    return _prideAndJoy.Brake(amount);
  }
}

    Ok so this is a basic driving game where a driver has a DeathTrap that implements IDrivable. If the driver tries to brake by 21 units the brakes will go out and will no longer function. So let’s test Driver and make sure it does what we would expect it to do. First let’s test that when we tell the driver to go, he goes.

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

    [Test]
public void WhenITellADriverToGoTheCarWillBeAccelerated()
{
  mockery = new MockRepository();  //Create an object to hold and manipulate mocks.
  car = StrictMock<idrivable>();  //Tell Rhino Mocks to make a strict mock from the interface.
  driver = new Driver(car);  // inject the car into the driver via constructor.
 
  car.Accelerate(5);  // tell the mock to expect a method call to Accelerate with a value of 5.
  mockery.ReplayAll();  // switch the mocks to replay mode.
  driver.Go(5);   // The actual call.
  mockery.VerifyAll();  // verify that the expected call was in fact made.
}

    As you can see there are a number of things happening here, but it really breaks down to the following.

    1. Setup Mock
    2. Hand the mock to the System Under Test
    3. Tell the mock what call to expect
    4. Flip the mock framework into replay mode
    5. Do the stuff you want to test
    6. Verify that the expected call was made

    That wasn’t too bad. Let’s try another example. This one has a slightly different syntax. I could have used a StaticMock here, it really didn’t matter.

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

    [Test]
public void WhenIPressTheBrakeWithAValueOfTwentyOneItWillReturnFalse()
{
  mockery = new MockRepository(); // Setup our mock repository
  car = DynamicMock<idrivable>();  //make the mock car
  driver = new Driver(car);  // inject car into our driver
 
  Expect.Call(car.Brake(21)).Return(false);  //tell our mock to return false when it gets a call to brake 21
  mockery.ReplayAll();  // switch to replay mode
  bool returned = driver.Stop(21);  // call the System Under Test
  mockery.VerifyAll();  // verify that the method on car was called
 
  Assert.False(returned);  // assert the return value is false
}

    The primary difference here is that the method that we are calling returns a value this time. So we have to tell our mock what to return when the method is called. Notice that in both cases of this contrived example, by mocking the car we were able to do three important things.

    1. Isolate the behavior we were interested in.
    2. Ensure that the IDrivable returned the value we wanted.
    3. Avoided having to wait for Something really time consuming and irrelevant to happen.

    I hope this helps get you off the ground with using a mocking framework. If I come across any further eureka moments I’ll be sure to post them. Enjoy!

    Tags: , , ,
    Posted in Testing | No Comments »

    If you buy Cucumber and Webrat now, you will also get…

    Sunday, January 18th, 2009

    When you install Cucumber to your Rails project you get a number of  built in steps out of the box without any additonal effort.  These steps will do a number of common tasks.   Using them is a simple matter of knowing the correct wording.  If you want to see these steps for yourself, open ./features/step_definitions/webrat_steps.rb in your project after you have installed cucumber in your project.

    Here are are a number of useful steps that are included with webrat:

    • Submitting a form with a button – Let’s say you have a feature to collect email addresses and you have gotten to the step where the user clicks the button marked “I love Spam” to entrust you with their email address.   To perform the clicking of the spammy button in your cucumber feature simply write the step.

    When I press “I love Spam”

    •  Clicking a link – Have a feature that includes clicking a link labeled “Log in” that logs you in to the website?  To click the link in your test simply use the following.

    When I follow “Log in”

    • Filling in a field in a form – Let’s say you are writing the website where people can go to register their mouse.  You have a new action on your form controller and the view for new allows the user to fill in the serial number of their mouse to be saved via your Mouse model.   The html generated by this view would name the serial number field something like “mouse[serial_number]“.   To write a feature where you enter a serial number of “I10v3M1c3″ and click a button named “Submit”, you would simply use the following pre-built webrat steps in your feature.

    When I fill in “mouse[serial_number]” with “I1ov3M1c3″

    And I press “Submit”

    • Verifying that text is displayed – So you want ensure that a message is  sent to the screen that says “Hey smart guy, you entered your gender as a numeric value!”?  Use the following step to make sure that text is being displayed in the response.

    Then I should see “Hey smart guy, you entered your gender as a numeric value!”

    These are just a few of the pre-built steps available to you that you can use without any step writing at all.  Check them out. 

    Tags: , ,
    Posted in Testing | 2 Comments »

    « Older Entries