Topic: rails development

Real Testing Example, Part Two

Noel Rappin, Friday, July 24, 2009 @ 10:45 am

Spam Wall, by freezelight

What with upward of two people saying nice things about last week’s post, I’ve decided to keep going with part two of a look at some real testing code.

Most code-heavy tutorials show the code but not the tests — I’m doing the opposite here, and showing the tests, but not much of the code. Also, although I’m presenting these tests in chunks, you should realize that there was a lot of back-and-forth from Cucumber to tests to code and some backtracking, most of which I’ll spare you from having to wade through.

At the end of last week, I had run through the tests for spam-prevention code which worked by limiting the rate at which a user could send messages to other users of a particular social networking site. Cucumber was involved, and I think I went off on a tangent about writing lots of tests.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

software development best practices

Comparing Ruby Mock Object Libraries

Noel Rappin, Friday, May 29, 2009 @ 12:23 pm

Masks by exfordy

Continuing on the theme of comparing similar things that I started last week, this week I'll be taking on Mock Object libraries.

The purpose of a mock object library is to allow you to create "fake" objects that can take the place of the regular objects in your application during testing (you'll sometimes see them called "test doubles", by analogy with a stunt double, another kind of stand-in).

There are a several reasons why you might want to use a test double in your tests, the two most common are probably these:

• To take the place of a hard to create or expensive to access object or method call, such as a web services call. Using the test double lets the test system pretend that the expensive object is there, but at a much lower time cost.
• To isolate an object being tested from the details of the rest of the system. In Rails, for example, a controller test might create test doubles for methods in the model so that the controller test can pass or fail separately from whether the model implementation is correct.

Ruby's open object model and duck-typing makes creating test double objects relatively easy compared to stricter languages like Java. There are four major mock objects packages in Ruby:

1. FlexMock is the original Ruby mock object package
2. Mocha is quasi-official in that the Rails team uses it for their tests.
3. RSpec defines its own mock package
4. RRis the newest entry, with shorter syntax and a couple of new features

Here's a tour of what each package looks like, and when you might use each feature.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

software development best practices