RSpec and the Death of Should

I love writing expectations like the following:

1
account.balance.should be_zero

It was one of the reasons I first fell in love with RSpec and had a reason to move from dabbling in Ruby to diving in. This was hard and clear evidence that Ruby crushed testing syntax of Java in a way it could never compete with. Just a beautiful DSL with a single little word ‘should’.

Expect has come along to replace and it accomplishes the same thing with a bit more syntax and parens:

1
expect(account.balance).to be_zero

It reads well, but I still like ‘should’ better and I’m not as upset as some about object purity and polluting objects with an extra method. Our development team concluded as much for the last few years. We’d put a quick vote up every 6 months or so to keep should() or bite the bullet and move onto expect. Should always won, but over time the objections became more mild and newer team members had gotten adjusted to expect elsewhere. When the vote came up again a few weeks back, we finally voted to default to the new expect syntax.

My vote had changed from preferring should to being neutral on it. Over time most of that came from working on newer Ruby open source projects and following the new expect syntax when adding tests in a pull request. Idioms and styles evolve and I’d seen enough adoption to justify retiring my old friend should(). The small benefit has been with Jasmine with its very similar expects now doesn’t lead to accidentally writing a should() in a Jasmine spec. I still miss should(), but having everyone use the same assertion approach is better for the group.

One Language Resumes

Reviewing resumes as a manager, tech lead, or even just a developer is no one’s favorite activity. Resume’s are inefficient, misleading and so often boring. If you’re a prospective hire boring is bad.

A simple case is the standard corporate style J2EE developer resume. There are host of bullet points claiming skills I already expect them to have with 10+ years of development experience.

  • Spring
  • Hibernate
  • Tomcat, JBoss, Weblogic, or WebSphere
  • A smattering of design patterns from Singleton to Template Method
  • Javascript and some JQuery
  • Some selection of Java’s innumerable web frameworks.
  • Oracle/SQL Server/MySQL

At this point they’ve done nothing to distinguish themselves from the pile of already screened and rejected resumes beside them. You’ve developed on the JVM for 10+ years and you’ve never looked into alternative JVM languages. No Groovy, Scala, or Clojure. Not even some adventure off the JVM into Ruby, Go, Elixir, Python.

Java is by design a simple if verbose language with a huge amount of libraries and IDE tooling. It has never been the best solution for almost anything. Luckily there’s been a “Get out of Jail” free card option for a long time now. You can pull out a JVM language that better fits the problem space solve the problem more elegantly. All that and still produce compatible byte code and interop easily with existing Java libraries. It’s a career limiting to ignore that opportunity.

For the brave there’s always the option of leaving the JVM entirely and trying something like Ruby, Python or Go. It may require adjusting to life outside a familiar IDE or dealing with a new set of libraries, but it’s not a very difficult step to make.

So fair or not let me explain the conclusions I make when I see a J2EE developer resume with many years of experience and no mention of a second or third language experience:

  • Not very interested in learning in an engineering field that is constantly changing.
  • Did the majority of their learning by working on an existing Java codebase, and aren’t interested in spending any time coming up to speed on anything that isn’t currently required for the job.
  • Don’t enjoy development as a pursuit other than the fact that it’s fairly well compensated.
  • Are OK with doing things the hard way because they have one hammer in the toolbox.
  • Think they know a second language because they hack some javascript when required.
  • Copy and Paste is their most common approach to gaining code refuse.
  • Won’t be able to come up to speed quickly.
  • Are going to bomb out in a phone screen, so no point in scheduling one.

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.

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.