Tuesday, October 26, 2010

I just finished building my first, fully-functional, non-trivial phone tree. This is exciting because it only took me two days. It has a bunch of submenus, it records and plays back content from the user, and it's even pretty friendly about confirmations.

I built it using Ruby on Rails and Twilio which is where I just started working. Building a telephone app using web technologies is very comfortable.

What's most amazing is that I used behavioral driven development using Cucumber in order to develop the app. In fact, I didn't even call my app until I had finished building it. It was mostly correct the first time I called it. Using Cucumber to walk through all the user-flows in the phone tree was a big win!

Note, I didn't use one assertion per test as I warned against here, but rather wrote very full integration tests that walked around the phone tree quite a bit. Here's an example test that actually interacts with the phone tree:

Scenario: delete a friend, but cancel Given I already have 5 friends When I enter "delete_friend" on the edit friend menu for the friend at position 3 Then I should get a valid TwiML response And it should say "You are about to delete" And it should play "name_3"

When I follow the redirect Then I should get a valid TwiML response And it should say "If this is correct" And it should say "If this is incorrect"

When I enter "incorrect" Then I should get a valid TwiML response And it should say "The delete has been canceled."

When I follow the redirect Then I should get a valid TwiML response And it should say "Main menu."

Unfortunately, I can't share the entire source code for this application yet or the phone number since this is a commercial application I'm building for a customer. However, as soon as I finish my pet project that I'm building on the side, I'll post its phone number and its source code. I'm anxious to share a bunch of tricks that I came up with for making it easier to develop phone trees using Ruby on Rails and Cucumber.

Wednesday, October 13, 2010

How many assertions should a test have? For instance, how many times should you use ".should" in an RSpec test? How many times should you use "Then" in a Cucumber test?

I have seen some developers work very hard to never have more than 1-2 assertions per test. They consider tests that are more than 3 lines long to be a code smell, and they tend to break up tests so that there is one assertion per test. I'd like to suggest that this conventional approach has some downsides that are too often overlooked.

First of all, what are the upsides of super skinny tests?

If you put 10 assertions each into their own test, then you can get very fine-grained results concerning which tests pass and which tests fail. That's useful. However, fine-grained results aren't all that crucial. I actually don't care all that much whether one test fails or ten tests fail. It doesn't really tell me how many bugs there are. Either way, it could be a single misspelling. Any number of tests failing is bad, and I don't regain confidence until all the tests are passing.

The next benefit of super skinny tests is that it helps prevent one assertion from affecting the outcome of another assertion. There's nothing more frustrating than tests that fail if you run them one way and pass if you run them another way. However, super skinny tests don't always address this problem. For instance, if you have data cached at the class level, that data will persist even between tests. Furthermore, a lot of tests are so simple you don't really need to worry very much about them affecting one another. For instance, if you check that a string contains "foo", that won't realistically have any affect on another assertion that checks whether it has "bar".

One more benefit of skinny tests is that they result in a comforting feeling. What's better 1000 tests or 1500 tests? The gut reaction is that 1500 tests is better, and I'll admit that I like lots of dots on the screen just as much as the next guy. However, if the 1500 tests only contain 1500 assertions whereas the 1000 tests contain 3000 assertions, it may be that the 1000 tests test more. I don't think there's any shame in adding a few more assertions to an existing test if you think that it adds real value to that test. Let's face it, testing isn't really about who can create the largest number of tests. It's about catching bugs that arise as the code is extended or refactored.

There's an old saying that says the best tests are the ones that get run. There's a hidden cost to super skinny tests that often gets overlooked. Consider the following hypothetical, functional RSpec test:

describe FilmsController do before(:each) do @film = Factory :film get films_path end

it "should have content" do ... end

it "should set flash correctly" do ... end

it "should have the right title" do ... end

it "should set the right value for such and such assign" do ... end

it "should set the right value for some other assign" do ... endend

What's wrong with this set of tests? Well, first of all, I prefer Cucumber integration tests over RSpec functional tests, but let's put that aside from a moment. There is a before filter that runs before each test. Hence, each test has to create a new film record and then regenerate the whole page. Generating the page probably results in a bunch of queries too. Let's assume 10 tests, 1 setup query per test, and 7 queries per page load. That's 80 queries for 10 assertions.

However, none of these assertions is all that complex. Furthermore, they're all simple enough that they are extremely unlikely to have side effects on one another. We could replace the before(:each) with a before(:all), but that turns out not to work out so well in practice. I suspect it's because each test runs in its own transaction.

Alternatively, we can collapse this into one test:

describe FilmsController do it "should generate a proper index" do @film = Factory :film get films_path test the content... test the flash... test the title... test such and such assign... test some other assign... endend

Not only does this remove a lot of boilerplate, it also cuts down the number of queries to 8. That means the tests run faster. When the tests run faster, they're more likely to be run as you develop. (I assume you already have integration testing that will run all the tests once you check the code in, but there's still value in running the tests as you develop.)

In conclusion, I think it's best not to go too overboard keeping your tests skinny. If two assertions require different setup, certainly put them in separate tests. However, once you have everything setup, if you can think of a few extra assertions that would add value to the test, don't be afraid to add them to the same test. I even like to occasionally add some assertions as I'm doing the setup just to make sure that the computer and I are on the same page (although I think it's best not to re-test things that have already been tested elsewhere). Certainly, I wouldn't recommend humongous tests that are 100s of lines long, but neither should every test be constrained to a single assertion.

Saturday, October 02, 2010

The site I've been working on for the last year, Fandor, is finally ready! If you like independent and international films, you might want to check it out. Fandor is a subscription service for streaming independent films on demand. As we move into a new phase, we are inviting our friends and family to sign up for a one-month free trial.

To sign up, go here and fill out the quick subscription form: fandor.com

This is the first version of the site, so we anticipate many changes to come. Please don't hesitate to give feedback. Your comments and questions will be very helpful as we shape the service. By the way, no it wasn't my idea to require a credit card before you can look around on the site ;)