All Posts in RSpec

April 29, 2013 - No Comments!

Bradley Schaefer Joins RSpec Team

IMG_1476Our friend and colleague, Bradley Schaefer, has recently joined the team at RSpec. I sat down with him and asked him about it.

Erik Schwartz: How did you get involved with the RSpec project?

Bradley Schaefer: I’ve been using RSpec pretty much as long as I’ve been using Ruby, and probably in the last year I started following it more on GitHub and participating a lot on issues, as well as submitting some pull requests. Even though RSpec is a fairly established library, there’s quite a number of issues that crop up, especially I think with so many eyeballs on it, they find every single nook and cranny where a bug could be introduced, so there’s a constant stream of activity on the project.

ES: What’s the mechanism for communication?

BS: The RSpec team is pretty transparent, so almost all the activity goes on through discussion and GitHub issues. Occasionally there’s backchannel communication in the FreeNode #RSpec IRC channel. But there’s also a lesser used private Google group. To be honest, everything goes on out in the open and is discussed via GitHub issues so people in the community can be involved in the decisions. Or, like me, get roped into becoming a contributor.

ES: What are some of the things you have on your plate for the upcoming months?

BS: We're working hard on getting RSpec 2.14 out the door, and we're discussing what will go into the next major version of RSpec 3.0. RSpec follows the semantic versioning system, so 3.0 will give us the opportunity to make some breaking changes such as removing features that have been deprecated for ages.

ES: Any other geek-out items you want to share?

BS: From a geeky perspective, another interesting thing we’re working on actively for RSpec is removing all of the the monkey patching the project originally used to get things like the Should method attached to every single object and things like that. In RSpec 3 we’re hoping that we can eliminate all monkey patching, at least in the default configuration, or some configuration, which right now isn’t really possible. Not only does it pollute the global namespace, but it also has the potential to break down as a technique when you have proxy objects, or other sorts of objects that mask or change those methods. So removing the need for those monkey patches is going to make it a little bit of a better Ruby citizen and prevent other subtle issues from arising. So we’re pretty excited about that feature, even though it’s a pretty geeky, behind-the-scenes, “how RSpec works” feature—it may not be completely visible, but it’s kind of exciting nonetheless.

ES: Have you heard any feedback one way or the other for moving to the new Expect syntax, the new assertions vs. the old?

BS: Yeah, there’s definitely two camps on that, I think. Moving forward, the Expect syntax is going to be the default at some point, whether it’s 3.0 or later on, I’m not sure. But that’s part of the effort we’re doing in order to get rid of global monkey patching. So I think Expect is really awesome syntax because it describes what it’s doing really well, and it allows you to pass in either value objects or blocks that have deferred execution, with a syntax that’s very readable, which I think is pretty awesome. Whereas before, doing the block syntax vs. directly calling should on an object was kind of jarring how different it looked. And in fact I think maybe a lot of people don’t even know that you can defer execution of things for various reasons. One example of it is when you’re expecting to raise an exception when you call something, you can’t raise the exception immediately before you make the expectation known, because then there’s nothing to catch the exception so it just bubbles up the stack, and blows up your spec before you can even say that you’re expecting it. So that syntax is a lot cleaner with the new Expect syntax.

But there’s also definitely a camp that really likes the Should syntax, and it will continue to be supported at least as a configuration option, so if you’re one of those people who really likes that and aren’t down with Expect, you’ll still be served by RSpec.

ES: How do you organize the actual team? How do you dole out responsibilities?

BS: It’s really loose, I would say. Andy Lindeman is the primary resource for RSpec Rails, and that’s because he does a lot of Rails work, he’s intimately familiar with that part of the project. And the head maintainer is Myron Marston and he is in charge of everything else other than Rails because he really doesn’t work on any Rails projects. So that’s why that division exists. And between the rest of us new guys—Jon Rowe, Sam Phippen, and me—we are all a bit undefined right now. We’re free to roam and contribute to whatever interests us, but I actually think I’ve seen all three of us contributing across the entire RSpec project to some degree. So we’re kind of floaters, I guess.

ES: Have you bumped into anyone else in town who works on RSpec? I know David Chelimsky is in town, anyone else?

BS: David is the only one that I’m aware of, and I’ve seen him at the ChicagoRuby meetup, but I haven’t talked to him. But I have not actually met any of the other team members in person, so that’s kind of interesting, I guess, that it’s an entirely virtual relationship. David has stepped down from being the lead project maintainer, I think because he’s doing a lot more clojure work in his day-to-day life. But he’s still involved in RSpec to some degree. We definitely lean on him to get a lot of perspective on historical reasons for things or our thoughts for the future.

ES: I imagine. He was at it for quite a while.

BS: So I’m going to have to hit up a clojure meetup at some point just to say hello to him.

ES: RSpec is a great name for the project, obviously. Backwards it’s “CEpsr.” Do you think you would have been drawn to the project if it had been named “CEpsr”?

BS: I’m actually spelling it out to look at it to see what it looks like, and I would say probably...probably not. RSpec to some degree is cryptic, but I think the idea of talking about specs is really easy, so it has that. But CEpsr...I don’t know what language you’d use to describe that. But specs definitely speaks to the specifications of something, so it also acts as documentation.

December 28, 2012 - No Comments!

Pragmatic Flight of Fancy in Rails Testing

A Flight Of Fancy sideview full 4x4x120A common TDD concept is that you write tests targeting the most optimal API imaginable, rather than contorting your code around current production realities. It’s possibly the most practical form of flight of fancy anyone has ever considered. Run free in a field with your API before you build retaining walls to thwart mudslides. The resulting code is much better because you work toward the best possible experience, deferring details for as long as possible. It’s amazing how well the process works in all types of contexts.

Let’s consider the Rails test suite. What’s our flight of fancy? Super duper fast tests. Once we set our sights on lightning fast tests, we bring them to life, nevermore accepting pokiness as threadbare reality. Thankfully many smart people have done great work to bring this closer to being, but not without a touch of controversy.

Background on Test Performance

Executing a single (trivial) RSpec test against an empty Rails app is on the order of several seconds. This performance is not the product of anyone’s fantastical dreams, of course, but a function of reality. The Rails stack takes time to load and there’s no obvious way around it. Except, of course, to go around it. All of the sudden tests are several orders of magnitude faster. That’s the trick. Only use Rails when necessary and life is beautiful. Which begs the question, when exactly is Rails necessary in a Rails app?

Rails as Detail of Project

DHH chuckles at the notion of Rails-as-detail: "… Web apps don’t wake up in the morning and don an iOS suit." And it's true, no Rails codebase will ever end up running on an iPad mini. That said, how many people would benefit from lopping off functionality into lightweight independent services but have little idea how to begin? Generally speaking, who doesn’t want a better understanding of the entanglements of an application? After all, clear definition of dependencies is a central challenge in programming—it's a core tenet of useable design.

Quick Example of Rails as Detail

Take a module that lives in Rails whose mission in life is to talk to a third party API. I recently set out to extract something like this from Rails. It required one piece of Rails (the from_xml method) to parse the response:

response = Hash.from_xml(http_response)

So I added the single dependency to the api spec (and learned a bit of Rails trivia in the process):

require "active_support/core_ext

In this simple but common case, the entire Rails stack is obviously not needed to test the wrapper. By decoupling from the entire framework testing is quick and we’ve outlined the specific dependency for the benefit of posterity.

Controversies be Darned

It's true. As programmers we should be happy about and embrace progress in the form of:

1. Orders of magnitude performance improvements. Goes without saying. Orders of magnitude efficiencies are ultimately what we’re concerned with in various forms every day. Does it take 10 people to ship an order or just 1? Does it take 500 ms to execute a test class or 5 minutes?

2. Clearer dependencies. Asking classes to outline their dependencies to Rails and elsewhere leads to clarity. Rails is a big framework. Seeing the forest for the trees drives a better understanding of the framework and its relationship to the domain logic.

tl;dr Actors in Today’s Flight of Fancy:

Rails = Chuck wagon with all manner of useful provisions, but heavy.
Fast tests = Beautiful pastoral field, but far away.
Independence = Awesome horse that gives you a ride and teaches you lessons along the way.

Take the ride, enjoy the field, pick some flowers.