RSpec Stubs with no_args

We’ve been getting pretty particular about our stub/mock expectations at work. A few months ago I would been perfectly happy with:

1
TwitterGateway.stub(:new).and_return(double)

I didn’t worry about specifying that I didn’t pass any arguments to the constructor. After it was pointed out that the stub didn’t really fully specify its’ expectations I changed to this style:

1
TwitterGateway.stub(:new).with().and_return(double)

Then a colleague pointed out a nice bit of syntactic sugar. You can simply specify a no_args matcher if no arguments are passed in:

1
TwitterGateway.stub(:new).with(no_args).and_return(double)

A more complete stub with better readability. Reminds me of how I fell in love with RSpec the first time I saw it back in 2006.

10,000 Tests and Counting

I played a “Yeah” sound effect in campfire a few weeks ago in celebration of checking in our 10,000th test. It was a milestone worth celebrating with both Creme Brûlée Bread Pudding and a chocolate chip cookie. Stepping back a few years I had to fight policy battles just to allot any development time to testing or even check it into CVS with the production code.

Some good things about 10,000 tests and counting:

  • We have pretty good confidence that we can catch breaking changes throughout the app. CI and a suite of much slower QA Acceptance tests add to that confidence.
  • We can run the entire suite of 10,000 RSpec examples in about 8 minutes on the newest Macbook Pros with 16GB of RAM and 4 cores plus hyper threading.
  • Finding old crufty areas of the codebase that aren’t’ tested is a rare surprise rather than a common experience.
  • Even our large “god” classes are generally well tested.
  • We’re constantly thinking about ways to increase the speed of the overall run to at least keep it under the 10 minute threshold rule of thumb. This tends to lead to good refactoring efforts to decouple slow tests from their slow dependencies.

Some not so good things:

  • Many of the ‘unit’ tests are really light integration tests since they depend on database objects, Rails ActiveRecord objects in our case.
  • Some of our ‘god’ classes have 3000+ lines of tests and take 2-3 minutes to run on their own.
  • We have to rely on methods like parallel tests to distribute our unit test running.
  • If it doesn’t look like a change will impact anything outside the new code we sometimes skip running a full spec and let the CI server catch issues.
  • Running individual specs that use ActiveRecord often take 5-8 seconds to spin up, which is painfully long for a fast TDD cycle.
  • Our full acceptance test suite still isn’t consistent enough and running on CI so we have even more of a dependency of trusting the indirect integration testing in our unit test suite.
  • We’d like to use things like guard or auto test, but we haven’t been able to make them work with such a large number of tests.

Even with all the cons of a really large test suite, I love that we have it and run it all day long.

One Year with Jasmine

It’s been about one year since we introduced Jasmine as our default for Javascript testing. Looking back it’s easy to declare it a success:

  • We test all our new javascript instead of just deciding it isn’t worth the effort.
  • Javascript is broken out into files instead of having the temptation of just leaving it inline in a view template.
  • Functions are broken down and refactored to be small and testable.
  • We’ve even been able to test some complex Closure javascript using Jasmine instead of JSUnit.
  • Running the full Jasmine suite is a part of every CI build.

If we’d only achieved a few of these things I’d consider it a big success. For a long time my default approach was to handle Javascript testing through functional Selenium based tests. While these are valuable tests, they certainly don’t help doing TDD with Javascript. Jasmine has finally allowed me to stay in a BDD/TDD workflow when switching between Ruby and Javascript.

Daily Agile Standup Comedy

“So this mornings standup is brought to you by this ethernet cable, because you guys are so connected”

I’ve seen numerous standup rituals over the years, from passing along a Rugby ball to signaling the end of stand ups by noting it was time for lunch. Some of the rituals help keep everyone engaged and focused on the central goal of the standup, coordinating the team and making everyone aware of potential obstacles. Recently I became a participant in a novel approach to leading off the daily standup.

One Monday our manager walked into the standup room carrying an ethernet cable. Mistakenly I took it as another standup totem. We regularly have used books, cups, or packages of black licorice as standup tokens. Today though he held up the cable as he began the started and opened up with a themed joke to lead off the startup. There were groans and chuckles, but little did we know for about the next month or so the stand ups would start with these humorous tokens and little sayings. The black licorice with a mention of ‘like black licorice we all were experts in different things’ or the day with a tack that ‘we were as sharp as this tack.’

It’s a very small thing, but it’s details like these that keep a process fresh. You really don’t want the daily standup to degenerate into a complete ritual, so mixing things up keeps people alert and thinking. Not a bad practice to try out sometime if you find your standup getting a bit stale. And for other ideas you can always check with Jason Yip’s exhaustive patterns on standups.

My Biggest Career Mistake


My software career path has been a planned affair for many years. It started out as a happy accident with some exposure to a very early internet startup and an opportunity to build out a few web sites. It only took a few months to determine I really liked doing web development and I began my love affair with the computer section of local bookstores, devouring titles in an effort to come up to speed.

As my career progressed I always stepped into the next job to take on new challenges. I went from Perl CGIs to Java, from in-house development to professional services, and from being an individual contributor to managing a development team. The learning curve was exhilarating and enjoyable and when the position ran out of challenges I started looking at new opportunities. Learning new skills is a large component of what keeps me happy on a daily basis.

I didn’t realize it at the time, but I made my biggest career mistake on what seemed a very orthogonal concern about 5 years ago. At the time I was managing a corporate development team, having led them through an Agile adoption process that had been successful at a team level, but generally a failure at the larger corporate level where the management teams simply weren’t interested in changing. Having accomplished much of what I could I started a process of looking for new opportunities again.

My big mistake? Taking on a large home mortgage. In that year we moved from a nice modest home with a very affordable mortgage into a larger remodeled house with two bathrooms. Both my wife and I were advancing in our careers and bought into the idea that while the mortgage was a bit tight to begin with it wouldn’t seem that bad as our salaries grew.

At the time I started my job search I was aware that I had become disillusioned with corporate development. I loved mentoring up teams and bringing them up to speed on testing, refactoring, and CI, but I had begun to doubt that I could win many battles at the CIO level with making a greater impact. I pursued several opportunities at small software firms that sounded really exciting, but I ultimately said no because I wasn’t ready to take even a small drop in salary. I ended up taking another corporate management position at a company that was 7 years into a 200 million dollar death march project. There were some other warning signs going in beyond the death march project, but the compensation package was very respectable and in line with my new mortgage.

Up until this point my criteria for switching jobs had been:

  • The chance to make a real change in the organization
  • The opportunity to learn new skills
  • Working with great people who I could learn from

At the time I convinced myself the positives outweighed the negatives, but again it was really the mortgage that made the difference. The job had aspects of my criteria in it, but I had turned down several others that really fit the criteria completely, but involved taking a salary hit.

It took four years for me to undo the side effects of making the wrong career decision.