A lot of pair programming chatter this week. Starting with a New York times article describing pair programming at Hashrocket. It’s an interesting article, with a tone that could be described as “anthropologist describing the strange, yet quaint customs of the native tribe”

Obie Fernandez followed up with a list of 10 reasons why pairing doesn’t work in most cases. It’s actually a list of the things that Hashrocket does to support pairing, although entries like “2. Most software developers just don’t want to work that hard” and “1. Most software shops don’t really care about excellence” do have a certain, “aren’t we great” vibe to them, causing Mike Gunderloy to dryly observe: “Funny, Extreme Programming Explained never said anything about fancy hw or being awesome as a prerequisite for pair programming.”

C’mon Mike — everybody knows that being awesome is a prerequisite for everything in XP.

Josh Susser adds that pair programming isn’t right for all projects, particularly projects that have long compile times that force the pair to stare blankly at the screen.

I’d also add this interview with Kent Beck because a) every programmer could use some more Kent Beck in their life and b) because he talks about XP as being concerned with the the social context of programmers, with pairing being a part of that.

Now you are caught up. Here’s the part where I talk.

I’ve had a running debate with Dietrich for two years now. He thinks that Pair Programming is the number one most important part of an agile team. I think it’s testing. That said, I do think pairing can be a nutritious part of your agile breakfast. But it’s tricky to do right and easy to do wrong.

Pairing is for the long haul. Like pretty much everything in the Agile toolkit, the real gain in pairing happens over time and is hard to quantify because it’s the absence of friction later in the project. Code is cleaner and easier to change. System knowledge is more distributed, so you are less likely to freak out when Fred catches H1N1 a week before.

Actually, I’d describe most of the XP practices as “we thought we were trading short-term productivity for long-term productivity, then found that we got short-term gains as well.” Certainly can apply to TDD.

Project size and make up matters. A team of three developers, for example, is a challenge for an always-pairing environment. Even a team of two is a problem — some tasks really don’t lend themselves to pairing. If people on the team also has non-developer responsibilities, that’s another challenge.

Some people really don’t like it. And I think it’s glib to say “those people are lazy” or “those people don’t care about excellence”. Even I find pair programming really tiring, but in a “I worked hard today, plus I had to deal with another person all day.” It’s not unusual for programmers to be very strong Meyers-Briggs introvert-intuitives, and it’s not surprising that personality type would find pairing a challenge. It’s not insurmountable, but you do need to structure the pairing with people in mind — the Hashrocket 25 minutes on/ 5 minutes off thing is a good start.

While I’m here, I think you can really overstate the “people work harder with somebody next to them” thing. Pairing is great and helpful because of the continual review and talking about what you are doing. Conceiving pairing as a way to use peer pressure to keep your coders off of Twitter is, I submit, not very much in keeping with the spirit of the Agile Manifesto.

The physical layout is really important. A lot of Obie’s piece is about this. I just want to emphasize first that pairing is a lot louder than solo programming, and this can be an issue in open office environments, and also that pairing really does work better on a neutral environment that isn’t either developer’s home machine.

Pairing is hard to reconcile with offsite practices And I don’t mean just when you’re working with six guys in Krakow, but also any kind of work at home, flexible hours, programmer-friendly kind of time structure is a real challenge to integrate with pairing.

Hmm… A lot of challenges, not much guidance. Which matches my feelings. When put in the right context, pairing is fantastic. But the context can be elusive, even for people with the best of intentions and talent.

Would this have been a better blog post if I had paired with a co-worker?

Share/Bookmark

Please continue reading after the next sentence.

I installed Snow Leopard a couple of weeks ago.

Wait — don’t stop reading. This isn’t a post about how to install MySQL or a post about whether or not Snow Leopard is the Greatest Thing Ever. There are plenty of other places on the Internet where you can get that information.

I wanted to talk about two cool corners of the Ruby universe that I started using as a result of my Snow Leopard installation: MacRuby and RVM

RVM: Ruby Version Manager

One of the Ruby changes in Snow Leopard was an upgrade of the system Ruby version to 1.8.7. All fine, except that one of the projects I work on is on an older version of Rails that is not compatible. Clearly, I needed to get an 1.8.6 Ruby on my machine, ideally without messing up the system installation that other applications are using.

Enter Ruby Version Manager (RVM), a handy command line tool for installing and managing multiple Ruby interpreters on your system. In theory, usage is as simple as this:

$ gem install rvm
$ rvm-install

At this point RVM asks you to make a slight change to your shell files. Then just this:

$ rvm use 1.8.6

“But you didn’t have 1.8.6″, I hear you cry. True. RVM will go out, download, compile, and install Ruby 1.8.6 to my local machine without interfering with anything else on the system (it installs in ~/.rvm). You can install Ruby 1.8.x, Ruby 1.9.x, Ruby Enterprise, JRuby, Rubinius, and (I think) MacRuby.

(Okay — that’s the ideal. In practice, it took a little bit of system tweaks and command line tweaks. Mike Gunderloy’s Snow Leopard guide was helpful here. Although I’ve been able to get all the main Ruby versions to install, I’m still struggling some of the more esoteric version. Once installation is done, the command line interface is really good and things just work.)

Now, the Ruby in my shell is the new 1.8.6. But any other running terminal shells are unaffected — especially helpful if you are working on multiple projects. Each Ruby maintains its own Gem listing, although there’s work ongoing to make it easy to share gems.

To get back to the system Ruby, just

rvm use system

You can also specify any Ruby version as the default.

This is outstandingly cool, not just to solve my problem, but also as an easy way to create a harness to test your Ruby program or library against multiple Ruby setups. There are other useful features about setting different versions and managing shells, check it out.

MacRuby

Here’s the thing. For the last several years I’ve had this script that communicates with iTunes via AppleScript, and creates a bunch of random playlists according to criteria that is a bit more complex that an iTunes smart playlist. For instance, it can create a playlist made up of two-song blocks by the same artist. Okay, it’s wildly overdone, but I like it.

It broke in Snow Leopard. I don’t know why. It seems like the Scripting Bridge framework occasionally decides to go out for a cup of coffee, and my script times out.

This seemed like as good a time as any to investigate MacRuby. MacRuby is an implementation of Ruby in Mac OS X Objective-C. Unlike a lot of hybrid language/vm tools, MacRuby gives you direct access to the native objects. So, if you ask for a string, you get an object that acts as both a Ruby string and a Cocoa NSString, responding to methods of either. MacRuby uses Ruby 1.9 key/value arguments to translate Objective-C method names.

[person name];
[person setName:name];
[person setFirstName:first lastName:last];

In Ruby (this example is from a tutorial on the MacRuby site)

person.name
person.setName(name)
person.setFirstName(first, lastName:last)

Unlike regular Ruby, the order of the keyword arguments must match the Cocoa method selector.

For most people, this allows writing Cocoa applications in Ruby, including integration with XCode and Interface Builder.

That’s extremely useful, and I plan on trying it soon. For my purposes, the point is that it uses the Scripting Bridge directly, and I hoped that would allow it to bypass whatever weirdness was breaking my original script. (The original script was in Python, but I had a 75% functional Ruby version that I never actually built the I/O on, so it was largely a matter of learning the MacRuby way to communicate with iTunes.) Here’s a sample, cobbled together from various parts of the script:

def itunes
  @itunes ||= SBApplication.applicationWithBundleIdentifier(
    "com.apple.itunes")
end

def library
  @library ||= itunes.sources.objectWithName("Library")
end

def all_music
  @all_music ||= library.userPlaylists.objectWithName("Music")
end

all_music.fileTracks.each_with_index do |track, index|
  # stuff here
end

def create_itunes_playlist
  playlist = itunes.classForScriptingClass(
      "playlist").alloc.initWithProperties(
      {'name' => name})
  library.playlists.addObject(playlist)
  playlist
end

#chosen_tracks are my object wrappers around Cocoa
#itunes_track is the actual cocoa object
playlist = create_itunes_playlist
chosen_tracks.each_with_index do |track, index|
  track.itunes_track.duplicateTo(playlist)
end

Overall, everything works as advertised (it seems as though MacRuby is better able to deal with whatever happens to cause the Scripting Bridge to take a nap. I’m using the pre-release MacRuby 0.5, so there’s the occasional feature glitch (gem installation is a little dicey, for example). But the MacRuby team is actively, even furiously, pushing forward, and this looks like it’ll be very useful, very soon.

Share/Bookmark

WindyCityRails 2008

Sometimes I write these just for me.

As I’ve mentioned a couple of times, tomorrow I’ll be speaking at WindyCityRails, and I need a checklist of all things I don’t want to forget, and all thing things I want to do to make the talk great.

Preparing the Talk

Figure out what you want to say first. The outline view in PowerPoint and Keynote is a great way to organize what you want to say without worrying about how it looks.

Determine a small number of things that you think are key items that you want the audience to walk away with. Mention them at the start, summarize them at the end.

The classic advice is not to put too much text on your slides, and avoid reading the text directly. A pragmatic way to manage this is to set your body text font pretty large (I use 44 point fonts for my body text if I can get away with it), and break up any slide that threatens to overrun.

That said, you can make the opposite mistake as well — I find it tiring to go to a talk where all the slides are two-words and a non-sequitur picture. People may be viewing just your slides online, they need a little bit of context. Even people in the room often need a bit of context on the slides to help follow what you are saying.

Building up the slides during the talk point by point using animation can be a good way to keep from reading too much text on the slides. And it can help time a “punch line” by keeping it from the audience until you are ready. But don’t use it everywhere. (I’ve always wanted to give a talk that used bullet points like Colbert does in The Word segment, as ironic commentary. But that’s very hard, and I’m not sure it would work.)

I do like to separate off major sections of the talk with title-only slides. I’ve started tying these sections together by putting images on the title slide, and carrying those images in the background of the slides in the section at something like 20% opaque. It makes it easier for people in the audience to follow along.

Keep the number of moving parts to a minimum — rather than switch to an editor to show code, copy the code into your slides. TextMate has a “Copy to RTF” bundle that preserves syntax highlighting, or take a screen shot.

Similarly, try to avoid having to run code during your talk. (Unless the interactivity is the point, as in a longer workshop).

Try not to depend on Internet access for a demo, you never know how flakey the Internet is going to be at a venue. At the very least, have a bunch of screenshots in hand as a plan B.

Practice. Do a dry run by yourself. If you see something wrong in your slides or missing in your talk, write it down. But do try and get a clean dry run at some point, so you get a sense of how long the talk is.

If possible, practice in front of other people. Nearly every talk that somebody at Pathfinder gives has a practice run as a company brown bag. This is invaluable feedback as to what is interesting in your talk and what is not.

In many situations, your last slide will be up for a while while you answer questions or something. Put something useful on there, generally either a summary or places to go for more information.

Doing the Talk

Make sure you bring everything you need. Laptop. Power Cord. Monitor Adapter. Remote Control. Don’t assume that anything will be as you expect in the actual setup. As I type this I’m going to put my monitor adapter in my backpack. Put a copy of your talk on a thumb drive. Put a copy online using Dropbox or Gmail it to yourself.

If at all possible, scope out the space well before your talk. Where will you stand? Will you be able to see your own slides? Will you need a remote, or will you need to stand in front of your presentation machine?

Try and set up early if you can (if you are part of a conference program, you’re limited because there’s a previous speaker). Still, the less the audience sees you fumbling with cables the better off you are. It helps if you can check to see if the display resolution matches your slides.

Before the talk, shut down as many programs as you can on your laptop. Especially shut down notifiers — you don’t want an IM from your mom popping up in the middle.

I use a Mac utility called Caffeine to keep my computer from going to sleep in the middle of the talk, because it’s annoying when that happens.

The point of all this is to reduce the amount of things that can go wrong so that you can be as relaxed and have fun during the talk.

Getting started can be awkward. Sometimes it helps to get the audience involved by asking a question or two right off the bat — this can also help you gauge how much the audience already knows about your topic. It can also be an unobtrusive way to make sure that everybody can hear you.

At the end, if there’s time, take questions. Get in the habit of repeating the question before you answer it. There’s a good chance that most of the audience didn’t hear the question. If you are miked and being recorded, the recording probably won’t pick up the question unless you repeat it.

Stick around afterword if you can, often there will be one or two more people who have questions.

Share/Bookmark

Ask Mr. Lizard, from Jim Henson’s Dinosaurs

It’s time to play “Ask A Tester Person”, where I answer questions that I’ve gotten via email or otherwise about Rails Testing topics.

If you have a question for Ask A Tester Person, send it to railsprescriptions at gmail.com.

I’ve got two questions today:

Question 1: I’m writing too many tests!

One subject I still have questions
about is how to test authorization in controller tests. In my
applications I’ve been testing three different user cases for every
controller action, but this leads to, for example:

test_edit_by_anonymous_user
test_edit_by_unauthorized_user
test_edit_by_authorized_user

So every action has at least three tests, which obviously means a
*ton* of tests for the entire application. This has always felt like
overdoing it but I haven’t yet been able to convince myself that just
testing the authorization part of the code is sufficient. If I could
isolate the authorization mechanism for testing that might convince
me, but I’m not really able to do that (maybe my authorization process
needs to be redesigned?), and I’m not sure I’d be convinced
anyway…how the application responds in all three cases seems like
something that *should* be tested for every action…

I doubt that your authorization process needs to be redesigned, but then I’ve never seen your authentication process.

I’d recommend a couple of different things to clean this up a bit. On the assumption that unauthorized access has largely the same behavior across the application, you can create a boilerplate test like this example — the example uses Shoulda, but the basic idea should work in any framework.

  self.def should_block_access_for_anonymous_user(*actions)
    actions.each do |action|
      should "block anonymous access for #{action}" do
        logout_current_user
        get action
        assert_redirected_to root_path
      end
    end
	end

Which you would then use as:

  should_block_access_for_anonymous_user :edit, :update, :delete

The implementation shown here is probably a little too simplistic for full use (you might need to pass more information than just the action for each request), but the simple version could easily cover the most basic authentication issues with very little fuss.

If your authentication system is more complicated, the other option is nested contexts — again, this is in Shoulda, but can be adapted to RSpec or the Context gem:

context "GET edit" do

  setup do
    # generic edit setup here
  end

  context "with an anonymous user" do
    setup do
      logout
      get edit
    end

    should "not allow access" do
      assert_redirected_to root_path
    end
  end

  context "with an admin user" do
    setup do
      login_as_admin
      get edit
    end

    should "allow access" do
      assert_response :success
    end
  end

end

The upside of this compared with what you are probably doing is that it consolidate the setup between the different options. The downside is that it can be kind of verbose and hard to follow. But it’s still potentially easier than writing three separate tests for each action.

Question two: I’m creating too many objects!

Okay, I actually can’t find the email that this came from, which is driving me crazy, because how do you lose an email message these days? Anyway, the gist was that this person’s tests were running very slowly because he or she was creating so many objects for each test — I distinctly remember the number 50 to 100 being tossed around. So the question was how to avoid creating so many objects?

The bottom line is that there’s no way that you should need to create 50 to 100 objects for every TDD test, or even for any TDD test — it’s pretty rare that a unit-level test really needs that much data to work. There are a lot of potential issues here. Three that spring to mind are:

• You are trying to test too much code at one time. It’s possible (though still not very likely) that an integration test might need that many objects, but testing a single method almost never does
• You’ve transitioned from fixtures to factories, but you are still writing your tests as though you were using fixtures.
• You have perhaps an unnecessary fixation on providing “realistic” data in unit tests.

There’s some overlap here. One cause of this is problem is that in fixtureland, there’s very little marginal cost to creating new objects, so the tendency is to create fairly large aggregations of objects that cover all possibilities and have that be the universe for all the tests. When you transition to factories, though, keeping that big data blob around is not necessary. Since you can and should be custom-creating the data for each unit test, most model methods only need one model with specific attributes in order to specify the logic. Sometimes that model will need associated objects, but the factory tool can be set to create those automatically.

A special find method or named scope can be tested with as little as two objects — one to be found and one to be skipped. Sort logic similarly can be tested with two or maybe three objects. If the logic is really complicated, it’s better to do multiple tests with small amounts of data than one test with the whole shebang. The idea of a “unit” test is to verify one small piece of logic with as little data as possible, not to check program behavior under realistic data load — that’s what integration tests, performance tests, and actual user acceptance is for.

I feel like I’m answering the question “How do I create fewer objects in my tests?” with “By creating fewer objects in your tests”, I hope this answer gives you some tools for minimizing the number of objects you need to create in your tests.

Related Services: Ruby on Rails Development, Custom Software Development, Testing and Quality Assurance

Share/Bookmark

To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.

Designers and developers obviously have different goals for their HTML — developers have issues of reducing duplication, organization, and performance that are largely not the designer’s concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.

By the way, I’m absolutely not trying to make this some kind of left brain/right brain thing. It’s more of a software needs vs. domain expertise thing. Once upon a time, I was writing scripts that outputted router configuration files, and I had exactly the same issues with the router domain experts — my software engineering desire to structure the code without duplication conflicted with the way the router experts liked to structure their hand-written configuration instructions.

Our teams have had success with getting everybody on the team using common tools as much as possible. This means putting designs and code in the same code repository, and it means the development team supports the designers in creating a set up to run the current development version of the app locally. (By the way, this article by Mindy Wagner might be helpful if you are trying to convert everybody to Git.)

From the developer perspective, if you are working with HTML provided by designers, it’s important to keep the view layer of your code accessible to the HTML providers. Exactly what this means is subject to negotiation. Left to my own devices, I’d be putting all kinds of HTML generation in Ruby via helpers or something more esoteric. That didn’t work out well when the designer needed to go mucking about in metaprogrammed Ruby code to start changing CSS classes. We do better with putting pure logical stuff in helpers and using partials to split view logic. I’m pretty sure that if I were to suggest Haml for a project, the designers would veto it — Haml barely meshes with the way I think of HTML, the designers I’ve shown it to have basically recoiled in horror.

That said, everybody likes Less CSS, which seems to augment CSS in ways that seem very intuitive to CSS designers, and which are very satisfying to coders. It does all the things that you would expect CSS to do if it was a real language, but vanilla CSS works just fine. It really caught on quickly here.

From the designer perspective, get everything out of photoshop and into HTML/CSS as early as possible. It’s just too easy to put stuff into a photoshop image that represents hours of development work, leaving the developers in the position of trying to determine which parts of the impossible image are vital, and which are just chrome. Doing the wireframes in HTML/CSS keeps the design honest.

We use this little hack to integrate wireframes into the development app, which is really nice for developers when working with in-progress designs.

Ultimately what it comes down to is for everybody in the team to take some responsibility for making the team work together. The developers need to make the code base accessible to designers and to be alert to basic design issues and flexible in adapting wireframes into the site. Designers need to help place their deliverables in a format that keeps the developer from having to guess how things are supposed to work — nobody wants that.

Related Services: Ruby on Rails Development, User Experience Design, Ajax Rich Internet Applications

Share/Bookmark

Blue Ridge Mountains by eleda 1

So, I tried Blue Ridge for the first time yesterday and I thought I’d write down some quick impressions. Hence, Rails Testing First Look.

Disclaimer: We came into this tool so cold our toes froze. We fumbled, we made mistakes, we probably missed really great ways of doing things. I look forward to being enlightened.

Let’s do this question-and-answer style: What is Blue Ridge? Glad you asked. It’s an framework for testing JavaScript from inside a Rails application. For the most part, it’s a cohesive bundle of existing JavaScript test tools, such as Screw.Unit. The value-add of Blue Ridge is an easy installation and nice integration with Rails testing tasks.

Why did we start using it? We had some simple JavaScript stuff to do, and thought it would be a good time to start out with what looks like a solid way to test.

Is it easy to install? Very. Install as a plugin ./script/plugin install git://github.com/relevance/blue-ridge.git, then generate the Blue Ridge files with script/generate blue_ridge.

Blue Ridge will install a test/javascript directory. In that directory will be a sample test file application_spec.js, a helper file, and a fixture directory. Each javascript test file is assumed to have a matching HTML file in the fixture directory which is loaded to provide a sample DOM for test purposes.

Does it make any other assumptions? BlueRidge assumes you are using jQuery as your library. It’s theoretically possible to use Prototype, but we ran into continual difficulties (possibly because we were doing it wrong), and actually wound up switching to jQuery for the project, easy enough to do since we just started.

How do you write tests? Tests are written using Screw.Unit syntax, and if you are familiar with RSpec, the syntax will look pretty similar. Here’s the final draft of the first couple of tests we wrote, for a search box with default text that goes away when focused. The TextMate Screw.Unit bundle was very helpful, but other than that, the tests are pretty straightforward.

Screw.Unit(function() {
  describe("With my search box and default", function() {
    it("should switch the default", function() {
      search_focus($('#unified_search'));
      expect($('#unified_search').attr('value')).to(equal, '');
    });

    it("should switch a non-default", function() {
      $('#unified_search').addClass('search_entry');
      search_blur($('#unified_search'));
      expect($('#unified_search').attr('value')).to(equal, default_text);
    });

    it("should not switch if there is a value", function() {
      $('#unified_search').attr('value', 'Fred');
      search_blur($('#unified_search'));
      expect($('#unified_search').attr('value')).to(equal, 'Fred');
    });

  });
});

How do you run tests? Two ways. Blue Ridge provides a test:javascripts Rake task that will run all your Javascript tests in the terminal, this is also suitable for including in your continuous integration build, for example. A very nice feature from Screw.Unit is the ability to run tests in browser by simply opening the fixture HTML file in the browser of your choice. As long as your choice isn’t Safari, which isn’t supported at the moment. The ability to run the tests in console and in browser is very useful.

Any gotchas? Oy. We had what appeared to be some minor differences between the Rhino implementation that powers the console tests and the browser tests, leading to tests passing in the browser and failing in the console. We weren’t quite able to do what amounted to integration tests — we tried to trigger the JavaScript events so that the jQuery functions tested above were triggered, but couldn’t get that to work. You have to be careful that the fixture HTML file actually has all the DOM elements you need, and remember that fixing the actual view doesn’t change the fixture. Screw.Unit’s error messages on failure aren’t as helpful as they might be, there also seemed to be a thing where the fixture DOM wasn’t actually being reset between tests, but I’m not 100% sure about that, we wound up working around it.

And in the end? That said, I did feel better about my JavaScript after having tested it. Fixing the JavaScript code, it was nice to see that other functions hadn’t broken. There’s a lot to like here, and I’m hoping to get past my initial problems to a tool that will improve the JavaScript parts of my code.

Related Services: Ruby on Rails Development, Custom Software Development

Share/Bookmark

Here’s a minor thing that bugs me all the time.

I’m writing a functional test:

should "do something functional"
  get :search,  rder_id => @order.id, :user_id => @user.id
  # and so on
end

The get call in that test simulates a browser request. Intuitively, you would (well, I would) expect this request to be identical to a request coming from the actual view, via a helper like link_to("search", :action => :search, rder_id => @order.id, :user_id => @user.id). At least, you’d expect that parameters hash in the controller to be the same between the

Makes sense, right? The testing call should set up the same environment as the actual call being tested.Well, if you’ve gotten this far, read the title that said “Annoyances”, or have ever read any blogs, you know that isn’t how Rails works. Specifically, the actual browser call has all its arguments converted to strings as part of going through the HTTP wire, but Rails, oddly, does not similarly convert the arguments in the test.

Most of the time it makes no difference — if you pass the string or the integer directly to an ActiveRecord find method, everything works swimmingly. If you do a direct equality check on the parameter, though, you can get code that passes tests, but fails in the browser because the string value is no longer equal to the integer value.

For some time, I’ve had this on my list of annoyances that I don’t have the energy to fix, right next to the slightly misaligned light over my desk, and the fact that they bought the wrong kind of Kleenex at the office that one time.

This week, Adam Milligan at Pivotal Labs tried to do something about it. Specifically, he created a Rails patch, then a plugin, that can raise a warning or an error when a non-string argument is passed to an HTTP method in a functional test.

Adam chose to fail or warn rather than silently convert the parameter because he feels that some arguments that might get placed in an HTTP method don’t have clear correct conversions (his example is false), and he’s trying to avoid setting up a whole different kind of difficult-to-diagnose test to app misalignments.

As much as I love that Adam did this, I kind of think that it’s more consistent with Rails design to silently convert, to make the browser call and the test consistent. Still, having the code warn or fail (your choice) is a pretty good way to get into good habits and avoid having to track down weird test errors. So, thanks, Adam.

Related Services: Ruby on Rails Development, Custom Software Development

Share/Bookmark

Frustration, the game, photo by unlovalblesteve

Dot, dot, dot, dot, dot — tests are passing, looks like it’s time for lunch — dot, dot, dot, dot, F. F? F? But the code works. I know it does. I think it does. Why is my test failing?

One of the most frustrating times as a TDD developer is that moment when a test is failing and you don’t know why, as opposed to the more normal case where the test fails as expected. Here’s a grab bag of tips, tricks, hints, and thoughts to get us all through that difficult time.

Something Must Have Changed

This may be the most obvious piece of advice in the history of ever, but I find it’s worth repeating, mantra-like, when confronted with a bad bug:

When a formerly-passing test fails, it means something changed.

It may be in the code, or the system, or the test. But it’s probably not sunspots, and it’s probably not evil spirits possessing your MacBook. (Unless you are either living in a Charles Stross novel or writing Perl, but I digress…)

Looking through recent changes can help figure out what the cause of the failure is. Git’s bisect tool can do this automatically, or you can just look through recent changes in your source control viewer of choice. If the test was passing at one time, there’s a good chance the answer is in there somewhere.

This is a great argument in favor of committing to your source control very, very frequently (especially when you are using git and can do local commits), so that your changes are very granular.

Isolate

When looking at a small number of failing tests, it’s helpful to be able to run just those tests. Autotest is outstanding for this, since it will run the failing tests over and over until they pass. This is especially helpful if you have a number of failing tests that are not in the same test class.

This little code and terminal snippet is very helpful for quickly running one class at a time, which is almost like isolating a failing test, or at least close enough to be useful. Depending on your IDE and test framework of choice, you may also be able to run individual tests from the IDE.

Isolating tests makes the tests run faster when you are focused on just a few tests, and also makes any diagnostics you insert easier to interpret.

Two tips that I’ve stolen from listening to and reading Kent Beck:

• Back out your entire most recent change since your last passing test and start over. This works best if you work in very small increments, but it gets you out of the “I know I typed something wrong but I just can’t see it” nightmare
• Replace all the expressions in the method under test with literals — if that passes, then put the expressions back one by one until you find the culprit.

Diagnose

I have to say, I’m not a big fan of using stop-and-step debuggers. I’ve used them when I’ve been in an IDE, I’ve never really used the Rails command line debugger, but mostly I’ve found that not to be a great experience.

Normally, to diagnose what’s going on in a test, I usually either add additional assertions in the test or have the code print information to the console. If I diagnose via assertions, generally I’m testing the values of variables in more detail.

For some reason, I see a lot of people using Ruby’s puts method to write to the console — I recommend p, which calls inspect on the object before printing, and generally results in more informative output. As a matter of course, I put require pp, which allows me to use pp to get pretty-printed output, which is nice for nested data structures. Also, y gives a YAML representation of the output — very readable for ActiveRecord objects.

>> x = {1 => ['a', 'b'], 2 => 'c'}
>> puts x
1ab2c

>> p x
{1=>["a", "b"], 2=>"c"}

>> pp x
{1=>["a", "b"], 2=>"c"}

>> y x
---
1:
- a
- b
2: c

Especially if I have autotest running just the one test, I’ve been known to bury print statements all over the place — controllers, Rails itself (often educational). Just remember to take them out when you are done.

Clear Your Head

Take a walk. Force your pair to solve the problem. Get a cup of coffee (actually, I hate coffee, get a Diet Coke). Take a nap. All those silly clear your head things really do work sometimes.

Band Aids

It’s tempting sometimes to comment out the offending test and then your suite passes and all is well with the world again. That’s generally a bad idea (although sometimes a major refactoring can genuinely make tests obsolete.

Hope this helps. What do you do to fix stubborn tests?

Related Services: Ruby on Rails Development, Custom Software Development

Share/Bookmark

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.

Once the basic rate limiting code was in place, the client and I came up with a couple of special cases. The application allows a user to explicitly reply to a specific message sent to them. We agreed that these replies should not count towards the rate limit on the grounds that a reply was, pretty much by definition, not spam. Similarly, we decided that any message between users with a friend relationship on the site also doesn’t count toward the rate limit. More subtly, we decided that if a user was inadvertently blocked, then reinstated by an administrator, that their rate count should drop back to zero, so the user doesn’t just get immediately re-blocked.

The Cucumber tests:

Scenario: Reply behavior
  Given I am a user who is not a new member
  When I send 4 messages in a day
  And I reply to a message
  And I send 1 message in a day
  Then 6 messages are sent
  And I am not blocked from sending further messages
  And the administrator does not get an email

Scenario: Friend Behavior
  Given I am a user who is not a new member
  When I send 4 messages in a day
  And I send a message to a friend
  And I send 1 message in a day
  Then 6 messages are sent
  And I am not blocked from sending further messages
  And the administrator does not get an email

Scenario: Unblocked behavior
  Given I am a user who is not a new member
  When I send 6 messages in a day
  Then I am blocked from sending further messages
  When I am unblocked by an administrator
  And I send 5 messages in a day
  Then 5 messages are sent
  And I am not blocked from sending further messages
  And the administrator does not get an email

These tests are quite similar in structure to the tests I started with last week. I might start thinking about combining some of the steps, but in Cucumber, I bias in favor of having the actual test be as clear and readable as I can get it. I don’t think these scenarios are so complicated that they require simplification.

Most of these steps have already been defined, here are a couple that aren’t. The first two steps are slight variants on the message sending step definition:

When /^I reply to a message$/ do
  original_message = Factory.create(:message, :sender => @recipient,
      :recipient => @sender)
  message = Factory.attributes_for(:message, :sender => @user)
  message[:in_reply_to] = original_message.id
  visit(messages_path,
      :post, {:recipient => @recipient.id, :message => message})
end

When /^I send a message to a friend$/ do
  @user.become_friends_with(@recipient)
  visit(messages_path,
      :post,
      {:recipient => @recipient.id,
          :message => Factory.attributes_for(:message, :sender => @user)})
end

One thing that you may have noticed about these step definitions. Despite all my jumping up and down about Cucumber being a black-box system, both of these steps bypass the UI to complete the setup. The first step creates a factory message and the second step creates a friend relationship. In both cases, the actual message send being tested passes through the UI.

There are basically two reasons for bypassing the UI in the setup. One is, of course, that it’s the setup and not the action being tested, the second is that being a purist all the time is a pain, and it’s much easier to get the background info out of the way directly.

The final missing step, however, is completely through the UI — the step logs the user out, logs in as an administrator, navigates to the page, unblocks the user, and then logs the administrator out and the original user back in.

When /^I am unblocked by an administrator$/ do
  @blocked = @user
  visit "/logout"
  Given "I am a logged in administrator"
  visit path_to("the admin messaging page")
  click_link("Unblock")
  @user = @blocked
  visit "/logout"
  Given "I am logged in"
  reset_mailer
end

A little on the Rube Goldberg side, perhaps, but it works.

With the Cucumber step definitions in place, the question becomes what tests and code need to be written to make these pass. For the first two scenarios that adjust the definition of what makes a message count toward the rate limit, the code change will be in the User and Message models. Since it’s a thin controller that defers to the models for data, there shouldn’t be any code change in the controller at all.

Now, that’s a much easier determination to make in hindsight than up front, and as it happens I did write controller tests for both of those scenarios, largely because they were so similar to the controller context chunks in last week’s post that it only took about five minutes to set them both up.

The real test action was in the user and message models. I added a database column for messages called counts_toward_spam. The idea is that this would be true for most messages, but false for replies, friend messages, or messages otherwise cleared by the admins. This requires some unit tests in the message class to support it. Again, I’m using Matchy here, and testing the boolean spam_message?, which is basically an alias for counts_toward_spam that I added for readability. In retrospect, adding the method was probably unnecessary.

context "spam count" do

  setup do
    @sender = Factory.create(:user)
    @recipient = Factory.create(:user)
  end

  should "give an ordinary message a spam count" do
    @message = Message.new_from_params(
        {:subject => "fred", :body => "body"}, @sender, @recipient)
    @message.sender_id.should == @sender.id
    @message.recipient_id.should == @recipient.id
    @message.should be_spam_message
  end

  should "not give an ordinary message a spam count if it is a reply" do
    @message = @message = Message.new_from_params(
        {:subject => "fred", :body => "body", :in_reply_to => 11},
        @sender, @recipient)
    @message.should be_reply
    @message.should_not be_spam_message
  end

  should "not make a message between mutual friends a spam count" do
    @sender.become_friends_with(@recipient)
    @message = Message.new_from_params(
        {:subject => "fred", :body => "body"}, @sender, @recipient)
    @message.should be_friend_message
    @message.should_not be_spam_message
  end
end

The message tests simply set up the different classes of message and verify that they are classified appropriately, they are pretty straightforward.

I also added a test to user to verify that the spam count was being used appropriately — this is part of the same context as last week’s user tests. The user has already sent four messages in the setup.

should "not count a reply message" do
  message = Factory.create(:message, :sender => @user,
      :created_at => 10.minutes.ago)
  message.in_reply_to = 3
  message.update_count_toward_spam
  message.save!
  @user.spam_message_count.should == 4
  @user.update_message_block_status.should be_nil
  @user.should be_able_to_send_messages
end

It’s interesting what you see when you go back over a chunk of code to explain it to other people. In this case what I notice is the update_count_toward_spam method, which is part of Message that unsets the count_toward_spam_ field if the message is a reply and is automatically called as part of the controller create message code. However, strictly speaking, it should be tested in the message class rather than here (although, the message controller tests would also exercise it).

That’s the bulk of the testing for those features — at the time, I didn’t think there were any other special cases.

The part about unblocking a user requires controller tests, because the unblock action needs to be written in the controller. I’m making it part of the message controller, although I know that RESTfully speaking it probably should be a separate resource — the legacy app is such a REST tangle that it’s not worth it.

The controller test context looks like this — the setup creates a blocked user and calls the unblock method.

context "GET unblock" do

  setup do
    ActionMailer::Base.deliveries.clear
    @recipient = Factory.create(:user)
    @user = Factory.create(:user,
      :message_sending_status => User::BLOCKED_STATUS)
    @user.should_not be_able_to_send_messages
    admin!
    get :unblock, :user_id => @user.id.to_s
    @user.reload
  end

  expect { @user.should be_able_to_send_messages }
  expect { assert_redirected_to :action => :admin }

  should "send email to unblocked user" do
    assert_sent_email do |email|
      email.to.first == @user.email &&
      email.from.first == "do_not_reply@singlestravelintl.com"
    end
  end
end

The assertion tests verify that the user can send messages again, and that the user gets an email from the system to that effect. The associated user model test validates that the user’s spam message count is reset back to zero, which was the specific point of this round of tests (in the actual application, there were other Cucumber scenarios supporting basic administrative behavior).

context "unblocking a user" do

  setup do
    Message.new_from_params(Factory.attributes_for(:message,
        :created_at => 10.minutes.ago), @user,
         Factory.create(:user)).save!
    @user.update_message_block_status.should == "blocked"
    @user.should_not be_able_to_send_messages
    @user.unblock_message_status
  end

  expect { @user.should be_able_to_send_messages }
  expect { @user.spam_message_count.should == 0 }

  should "reblock" do
    @user.block_message_status
    @user.should_not be_able_to_send_messages
  end

end

Anyway, the code that I wrote along side these tests to make them pass seemed to work fine, and we deployed to production.

Shortly thereafter, we got a bug report. I haven’t stressed it here, but new users were limited to a single message in their earliest time on the system. We heard from a new user who sent a message, received a reply, and then replied back to that message, only to find that he was blocked, even though the reply message shouldn’t count toward the rate limit.

Interesting. It’s one of those bugs that almost turns philosophical — exactly when in this process does a user become blocked? In the code that I originally wrote, a user was blocked as soon as he or she hit the rate limit, and before sending another message. In fact, the code should wait until the user tries to send that next message to consider that user blocked, because a user who is at the rate limit border should still be able to send replies and friend messages without being blocked.

So, bug. Since the bug involves multiple interactions, I started in Cucumber:

Scenario: New User Behavior on reply
  Given I am a new user
  When I send 1 message in a day
  And I reply to a message
  Then 2 messages are sent
  And I am not blocked from sending further messages

All those step definitions exist, but the last two steps fail without further work. I wasn’t initially sure whether the code change for this would wind up in the controller or not — as it happened, it turned out to be a minor controller change and minor model change but it took me a few tries to get it right.

Since I already had a decent controller harness for similar scenarios, it took almost no time to adapt to the new condition:

context "with a borderline new user and a reply" do

  setup do
    reply = Factory.create(:message, :recipient => @user,
        :sender => Factory.create(:user))
    flexmock(User).should_receive(:new_user?).and_return(true)
    flexmock(Message).should_receive(
        :toward_spam_in_last_24_hours).and_return(1)
    post :create, :recipient => @recipient.id,
        :message => Factory.attributes_for(:message, :sender => @user,
            :in_reply_to => reply.id.to_s)
    @user.reload
  end

  expect { @user.messages_sent.size.should == 1 }
  expect { @user.spam_message_count.should == 1 }
  expect { assigns(:message).should_not be_new_record }
  expect { @user.should_not be_message_sending_blocked }
  expect { assert_no_email_to_administrator }
end

I have to say, in retrospect, that I’m not 100% sold on the use of the mock package here — it’s a clear user of mocking to limit the test’s exposure to the model layer, but I’m not convinced it makes the test more clear or readable. This setup and tests is very similar to the other bundles of controller test and makes most of the same assertions.

The main change was in the user method, triggered by the following tests — one of which tests the positive sequence, one the negative — and yes, the setups probably should have been combined.

should "move a new user to blocked mode after first message" do
  Timecop.freeze(Date.today)
  new_user = Factory.create(:user, :created_at => 1.day.ago)
  m = Message.new_from_params(Factory.attributes_for(:message),
      new_user, Factory.create(:user))
  m.created_at = 2.hours.ago
  m.save!
  assert_equal(2.hours.ago, new_user.last_message_sent_time)
  assert_equal("blocked", new_user.update_message_block_status(true))
  assert new_user.message_sending_blocked?
end

should "allow a new user a second message that is a reply" do
  Timecop.freeze(Date.today)
  new_user = Factory.create(:user, :created_at => 1.day.ago)
  m = Message.new_from_params(Factory.attributes_for(:message),
      new_user, Factory.create(:user))
  m.created_at = 2.hours.ago
  m.save!
  assert_equal(2.hours.ago, new_user.last_message_sent_time)
  assert_nil new_user.update_message_block_status(false)
  assert !new_user.message_sending_blocked?
end

The key here — which would be easier to see if the setups were combined — is the next to last line where update_message_block_status is called. That’s the method called by the controller when a new message is sent, and the false argument means that the new message does not count toward the rate limit. So in the second test, the user can still send messages, while in the first test, the user does move to a blocked status.

Having the existing suite of tests around the controller and model behaviors was a big relief when fixing this bug — it’d be easy to make a fix for this issue that affected one of the other scenarios (I know because I made fixes that broke a lot of tests…). This was a case where the tests clearly made me more confident in the fix that I made.

Related Services: Ruby on Rails Development, Full Life Cycle Software Development

Share/Bookmark

Spam Wall, by freezelight

As sort-of promised in last week’s post, I’m going to work through a real-world test example, with an eye toward explaining how and why I tested the way I did. Hopefully, I’ll be able to do this at blog-post length. If not, well, there’s always next week.

This site, which was a legacy rescue, allows users to send messages to each other within the site without having to give away their other contact information. The problem is that nefarious spammer types were creating logins and immediately sending messages to large numbers of the user population, irritating them. After some deliberation, the client decided on a rate-limiting strategy, where a member could only send a certain number of messages in a day, and a new member could send even fewer messages a day. Messages above that point would require administrative action to unblock the user’s privileges.

I started with Cucumber tests — the first two are representative of the initial batch. Everything you see here is actual code, only slightly tweaked to anonymize details of the site. But I’m trying not to present simplified “example” code. That said, this is the final state of the code, there were some intermediate steps and false trails that I’m sparing you from having to read about. I’m also focusing on the tests here, rather than the resulting application code.

Background:
  Given the user database is cleared
  Given a group of recipients.

Scenario: Normal User behavior
  Given I am a user who is not a new member
  When I try to send 5 messages in a day
  Then 5 messages are sent
  And the administrator does not get an email

Scenario: Excessive User behavior
  Given I am a user who is not a new member
  When I try to send 6 messages in a day
  Then 5 messages are sent
  And I am blocked from sending further messages
  And the administrator gets an email

This test uses an implicit style, so a lot of the details are in the step definitions. I start by writing the step definitions one by one until I get to one that I can’t make work without writing new code. As it happens, since not sending email is the current state of the system, the entire first scenario should work without any new code. It’s very important to include that scenario, though, to ensure that the new changes don’t break the basic behavior.

Here’s what the steps look like — the user who is not a new member defers to the boilerplate RESTful Authentication step for logging in:

Given /^I am a user who is not a new member$/ do
  @user = Factory.create(:user, :created_at => 5.months.ago)
    Given "I am logged in"
end

Given /^I am logged in$/ do
  visit "/login"
  fill_in("email", :with => @user.email)
  fill_in("password", :with => @user.password)
  click_button("Sign in")
end

Next up, sending messages. Since the point of Cucumber is to treat the application as a black box, the step definition uses Webrat to simulate number of posts to the create message RESTful action. (The @recipient is created in the background action, which I didn’t show here because it’s not very interesting.)

When /^I try to send (.*) message(.*) in a day$/ do |count, plural|
  count.to_i.times do
    visit(messages_path, :post, {:recipient => @recipient.id,
             :message => Factory.attributes_for(:message,
                                :sender => @user)})
  end
end

So this step definition allows you to match “send 3 messages” and “send 1 message” by adding that little group at the end of the message, that group needs to have an associated variable in the block argument list, but it’s just ignored. Somebody with better offhand regular expression skills could easily make it so the end of the expression only matches “message” or “messages”, but I can live with it being a little overly matchy for now.

Closing out the normal case, the step definition to test emails sent uses the excellent
email_spec plugin, which creates RSpec matchers and Cucumber step definitions for email testing. This one checks an all_emails method, filters out any methods sent to the administrator, and makes sure the right number exist.

Then /^(.*) message(.*) (is|are) sent$/ do |count, plural, verb|
  emails_out = all_emails.select do |e|
    !e.to.include?("admin@admin.com")
  end
  assert_equal(count.to_i, emails_out.size)
end

The administrator email step definition uses the email_spec steps directly — and yes, I could have included those steps explicitly in the Cucumber scenario. I chose not to, on the perhaps dubious grounds that I wanted to keep explicit string literals out of the scenario. But it doesn’t make that much difference either way.

Then /^the administrator (gets|does not get) an email$/ do |status|
  if status == "gets"
    Then '"admin@admin.com" should receive an email'
  else
    Then '"admin@admin.com" should not receive an email'
  end
end

Everything here passes for the normal case. So far, my main note is that all the step definitions are really simple — it’s almost impossible to misinterpret them.

At this point, I move on to the blocking case. There’s one more step definition to write. In actuality, the “then 5 messages are sent” step will fail, since the blocking isn’t in the code. So, I would normally jump to writing regular tests at that point, but since I’m here, I’ll present the last step definition.

Cucumber is a black box, therefore in order to detect if the user is blocked, we need to find some place in the application that will display it. After their initial notification, the user doesn’t see anything confirming their block status. But the administrator does, via an admin screen that actually hasn’t been written yet. So, the cucumber tests logs the user out, logs an admin in, and checks the admin page for a row associated with the user.

Then /^I am blocked from sending further messages$/ do
  @sender = @user
  visit "/logout"
  Given "I am a logged in administrator"
  @admin = @user
  visit path_to("the admin messaging page")
  assert_select("tr#?", dom_id(@sender, :blocked_row), :count => 1)
end

This step definition is a bit more complicated than the others, and it’s also taking it slightly on faith that the row with the correct DOM id will actually have the information the admin needs. (The tradeoff in view testing, as always is faith an flexibility vs. certainty and brittleness…)

Okay, there are genuinely failing Cucumber steps, it’s time to make them pass.

A couple of things to note:

• After going back and forth on this some, I’ve decided that Cucumber tests don’t really replace controller tests, except in maybe the simplest cases. My rationale is that Cucumber and controller tests look at different error conditions, and that Cucumber tests are really (partially) replacing the hand-testing that I would be doing to verify that the feature is working. Cucumber is the 30,000 foot view of the application, I still feel the need to test from the ground.
• This app was a legacy with effectively no tests, leading me to have to write some extra tests to cover the normal, non-blocking case. If the whole app was TDD, then that functionality would already have tests, but since I’m working on the new features, I need to go back and cover the base functionality.

The basic ideas is write the tests in the class where the code is going to go. I can guess that code will need to go in the MessageController, the Message model, and the User model. In fact, I’m going to need a new field in the user model, a string representing message sending status. (It’s a string and not a boolean, because I know from a later requirement that there will be more than two states). I actually will wait to write the migration, though, until a test compels it.

My preference is to start with the controller tests — it’s the easiest way into the system for me.

Here’s the batch of tests I wrote to cover the normal sending a message and not getting blocked functionality. These tests will probably look weird to just about everybody since I wrote them using a combination of Shoulda, Zebra, and Matchy. Zebra gives nice one-line tests, and Matchy gives a sort-of RSpec syntax that I sometimes like.

context "POST CREATE" do
  setup do
    ActionMailer::Base.deliveries.clear
    @recipient = Factory.create(:user)
    @user = login!
  end

  context "with a clean user" do
    setup do
      post :create, :recipient => @recipient.id,
          :message => Factory.attributes_for(:message,
                :sender_id => @user.id)
    end

    expect { @user.messages_sent.size.should == 1 }
    expect { @user.spam_message_count.should == 1 }
    expect { assigns(:message).should_not be_new_record }
    expect { @user.should_not be_message_sending_blocked }
    expect { assert_no_email_to_administrator }

    should "create and send" do
      assert_sent_email do |email|
        email.to.first == @recipient.email &&
        email.from.first == "do_not_reply@singlestravelintl.com"
      end
    end

  end

### Outer context continues

What to say about these tests…

• In controller tests, I organize contexts by action. The outer context setup clears the email and creates a couple of users — the login! method creates a factory user and simulates a login.
• The internal context posts the message
• The various expect blocks each resolve into a test that passes if the block returns true. The first one checks that a message has actually gone into the database (messages_sent is an association on user). The spam_message_count is what is used to determine if a user is blocked — that’s not going to pass yet, because the concept of a spam count is new to the app. The third tests that the message assigned in the controller is actually saved. The fourth checks the message_sending_blocked? method of a user, which is also going to need to be written. The last calls a helper method to determine if an email is sent to the administrator, which should only happen if the user is blocked.

Many of these tests pass as is. The ones that don’t are dependent on the new user features. Which means we need user tests.

I realize that some of you are starting to think that having all these tests is ridiculous overkill — I mean, you’ve got your Cucumber tests, you’ve got your controller tests, and now model tests. That’s, like, triple the work, isn’t it?

No, I don’t think it is. My rationale for doing all this testing goes something like this:

• In my head — which is, admittedly a strange place to be — these are all different tests covering different aspects of the same feature. They could all fail independently of each other, at least in theory. Each of them is exercising a different part of the code, and crucially, each of them is responsible for potentially testing error conditions at in their own space.
• It’s not that much extra time — I’m presenting the code in larger chunks than I actually wrote it (can you imagine how long this would be otherwise?). In the rhythm of testing, it’s a very short piece of test, followed by a very short bit of code, and the amount of tests grows over time.

Anyway, the user tests cover the case where a user has four messages, and then the transition to five messages. The setup is pretty similar (another reason why the extra tests don’t take as long to write as you might think)

context "rate limiting" do

  setup do
    ActionMailer::Base.deliveries.clear
    Timecop.freeze(Date.today)
    @user = Factory.create(:user, :created_at => 1.month.ago)
    4.times do |i|
      Message.new_from_params(
          Factory.attributes_for(:message,
              :created_at => i.hours.ago, :body => "Message #{i + 1}"),
          @user, Factory.create(:user)).save!
    end
  end

  should "correctly count messages" do
    @user.spam_message_count.should == 4
    @user.update_message_block_status.should be_nil
    @user.should be_able_to_send_messages
    assert_number_of_emails_to_administrator(0)
  end

  should "move user to blocked mode after fifth message" do
    Message.new_from_params(Factory.attributes_for(:message,
        :created_at => 10.minutes.ago), @user,
        Factory.create(:user)).save!
    @user.update_message_block_status.should be("blocked")
    @user.should_not be_able_to_send_messages
    assert_number_of_emails_to_administrator(1)
  end

## Outer context continues

Most of this should be clear given all my blabbering so far (and I have no real clear reason for abandoning Zebra in this section of tests). One thing is that the method update_message_block_status is actually responsible for changing the user status after a message is sent.

This is getting way long, so back next with with how this played out with new requirements, and a kind of interesting bug.

Quibbles with my testing style or process should go in the comments.

Related Services: Ruby on Rails Development, Custom Software Development

Share/Bookmark