Phil Calcado Blog Syndication

Annoying RSpec: Dynamic Scope

2012-06-30T22:00:00Z

At SoundCloud, we use a fair chunk of different languages, but most of our current code base uses Ruby; usually web apps built with Rails/Sinatra and workers using EventMachine.

Ruby has a very mature test framework called RSpec. I really like it, even used it through JRuby to test Java code. There are a few things with the way some people use the framework which really puts me off, though. Let's discuss some of them in a series of posts.

Scoping Rules

A while back I wrote on why reading classic computer science and software engineering books is important. One theme you are going to see over and over on these books is the issue of scoping.

There are many different ways to implement scoping in a system, the two most common strategies are lexical and dynamic. Summarising a very long discussion, scope is where the runtime and/or compiler should look to check if something you are trying to use (e.g. a variable identifier) is valid (i.e. it is bound).

Ruby has lexical scope, which pretty much means that we must declare variables somewhere before using them. In the code below, user is not a valid variable, as it isn't bound to anything:

describe Group do
 it 'adds user to the group' do
   group = Group.new
   group << user
   group.members.should == [user]
 end
end

We can fix this easibly by doing:

describe Group do
  it 'adds user to the group' do
    user = User.new
    group = Group.new
    group << user

    group.should include(user)
    group.members.should have(1).item
  end
end

RSpec's DSL has a useful construct called let which lets you define variables you want to use in more than one example —just like one would use an instance variable in a non-DSL framework like JUnit. We can use it like this:

describe Group do
  let(:user) { User.new }

  it 'adds user to the group' do
    group = Group.new
    group << user

    group.members.should == [user]
  end

  it 'removes user from group' do
    group = Group.new
    group << user

    group.remove!(user)

    group.members.should == []
  end
end

Some other languages provide dynamic scope, the classic examples are from the LISP languages, including Common Lisp (but not Scheme). Here is an example in Emacs Lisp (ELisp):


(defun is-expected? (other-thing)
  (eql the-thing other-thing))

(set 'the-thing 999)
(is-expected? 666) ;; returns false
(is-expected? 999) ;; returns true
the-thing ;; returns 999


(let ((the-thing 666))
  (is-expected? 666)  ;; returns true
  (is-expected? 999)) ;; returns false
the-thing ;; returns 999

(let ((the-thing 0))
  (is-expected? 666)  ;; returns false
  (is-expected? 999)) ;; returns false
the-thing ;; returns 999

(defun multiply-and-compare (what)
  (is-expected? (* what 100)))

(let ((the-thing 100))
  (multiply-and-compare 1)) ;; returns true
the-thing ;; returns 999

The value of the-thing depends on when it was invoked. This is an extreme case of temporal coupling, very similar to the problems caused by using global variables.

Nevertheless, dynamic scope can be really useful. It is often a great tool when you need to implement embedded DSLs. To use it, though, one has to adopt many conventions and tricks to avoid losing sanity; and as Doug Hoyte discusses in his awesome Let Over Lambda book:

Dynamic scoping used to be a defining feature of lisp but has, since COMMON LISP, been almost completely replaced by lexical scope. Since lexical scoping enables things like lexical closures (which we examine shortly), as well as more effective compiler optimisations, the superseding of dynamic scope is mostly seen as a good thing. However, the designers of COMMON LISP have left us a very transparent window into the world of dynamic scoping, now acknowledged for what it really is: special.

And even Emacs Lisp, in its last version, has lexical scoping.

Dynamic Scoping in RSpec

So how is this related to RSpec usage? Well, turns out that RSpec's embedded DSL provides an equivalent of dynamic binding, and pretty much every Ruby project I was part of uses this "feature".

Here is an example:

# event_consumer_examples.rb
shared_examples_for 'event consumer' do
  it 'raises error if asked to consume invalid event' do
    expect { subject.consume(invalid_event) }.to raise_error
  end

  it 'consumes valid event' do
    expect { subject.consume(valid_event) }.to_not raise_error
  end
end

# user_creation_consumer_spec.rb
describe UserCreationConsumer do
  let(:invalid_event) { SpamEvent.new  }
  let(:valid_event) { UserEvent.new  }

  it_should_behave_like 'event consumer'
end

# spam_report_consumer_spec.rb
describe SpamReportedConsumer do
  let(:invalid_event) { UserEvent.new  }
  let(:valid_event) { SpamEvent.new  }

  it_should_behave_like 'event consumer'
end

The shared examples in the first snippet depend on two symbols, invalid_event and valid_event. How these symbols are defined depends on when it_should_behave_like 'event consumer' is called.

To make matters worse, it is very rare that a test case is as simple as the minimal example above. Often you see things like this:

# user_creation_consumer_spec.rb
describe UserCreationConsumer do
  let(:transaction_type) { stub('transaction type')  }
  let(:invalid_event)    { SpamEvent.new  }
  let(:valid_event)      { UserEvent.new  }
  let(:observer)         { FakeObserver.new  }
  let(:event)            { stub('some event')  }

  it_should_behave_like 'event consumer'
  it_should_behave_like 'observable'
  it_should_behave_like 'component'

  it 'logs the user creation somewhere' do
    #...
  end
end

Now, if I want to do some simple refactoring, like renaming the :event binding, I have to go through all the example groups and see what uses that.

Eventually, my tests will become so hard to maintain I will pretty much wrap each it_should_behave_like block into its own describe or context block, and maybe define some naming conventions around variables consumed by a given shared example. This is exactly the same kind of overhead we need to apply when using dynamic scope, as described by the article linked above.

Making it Explicit

When I first had to work on a big code base with tests relying on dynamic scope, I spent a couple of hours thinking about how to bypass what I saw as a limitation of RSpec. Then I realised something: even though you cannot make what you define in your spec not visible by the shared group, you can be explicit about what you pass to the argument groups.

You can pass an initialisation block, which will be executed before the specs on that shared group. This doesn't require any change to the shared group itself, we just need to change our specs a bit:

describe UserCreationConsumer do
  it_should_behave_like 'event consumer' do
    let(:invalid_event) { SpamEvent.new  }
    let(:valid_event) { UserEvent.new  }
  end
end

describe SpamReportedConsumer do
  it_should_behave_like 'event consumer' do
    let(:invalid_event) { UserEvent.new  }
    let(:valid_event) { SpamEvent.new  }
  end
end

Or you can declare your shared group in a way that receives parameters, just like any other function call would:

shared_examples_for 'event consumer' do |valid_event, invalid_event|
  it 'raises error if asked to consume invalid event' do
    expect { subject.consume(invalid_event) }.to raise_error
  end

  it 'consumes valid event' do
    expect { subject.consume(valid_event) }.to_not raise_error
  end
end

describe UserCreationConsumer do
  it_should_behave_like 'event consumer', UserEvent.new, SpamEvent.new
end

describe SpamReportedConsumer do
  it_should_behave_like 'event consumer', SpamEvent.new, UserEvent.new
end

The resulting code not only is smaller, but easier to follow and refactor.

I am not sure why people don't use this more often, maybe because people are so used to everything being global in Rails that they don't think too much of it.

Read The Dinossaurs!

2011-12-28T23:00:00Z

I just finished reading a review for The Mythical Man-Month on Jaco Pretorius blog. This post started as a comment there but... you know how it works.

I would recommend to read his review in full, but here are the parts which caught my attention:

Apart from the examples being so outdated I’ve only really heard of one or two of them (in history books), the entire book reads like a dinosaur. [...]

So apart from the examples being from the stone age and the diction being long-winded, I tried to take a step back and consider why the concepts being discussed seem out of place.

It comes down to Agile development. Pretty much all the concepts and possible solutions introduced are superseded in one way or another by Agile. [...]

This book seems to advocate the incredibly outdated software life-cycle [...] Those days are behind us (hopefully).

I realize that at the time this book was written this was pretty much standard practice, I simply fail to see how it still has any relevance today. [...]

To be fair, some of the later chapters are a bit more modern [...] but arguing about whether or not Ada will be the next big programming language and whether or not Object-Orientated Programming will become mainstream really doesn’t appeal to me. Software development is simply a field which changes too quickly – a book which was written 10 years ago would be completely out of date, never mind one which was written 36 years ago!

I think a large part of the popular appeal of this book is unfortunately simply the nostalgia value. From a practical and relevancy perspective it offers very little.

If you follow this blog, you probably expect me to have some strong opinions about the points Jaco raises, as I am a bit of a book worm myself.

Disclaimer: I don't know Jaco; everything I write here is based on my interpretation of the review he posted and my assumptions can be just plain wrong.

It's about the mindset

It seems to me that much of Jaco's reaction is not to the ideas contained in the book, but to the "old" feeling of everything.

I used to buy a lot of books on technology. At some stage I gave up and decided that for frameworks, languages and tools I would read the book on the (excellent) Safari Books Online. I would only buy books where technology was used as a medium, not the goal. It's like the old, often misquoted as Dijkstra's, quote:

We need to do away with the myth that computer science is about computers. Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes or chemistry is about beakers and test tubes. Science is not about tools, it is about how we use them and what we find out when we do.

—Michael R. Fellows and Ian Parberr, SIGACT trying to get children excited about CS

Many of the most important books for both computer science and software engineering use "outdated" technology (e.g. SICP, TAOCP, Refactoring, OOSC, Object-Oriented Heuristics, GOF's Patterns, POEAA...) and they are still relevant because the good ideas are still applicable.

Jaco asks a commenter to provide specific examples of how Brooks' essays originated many of the practices in this industry; I would be surprised if I find a recent book on software management that doesn't base its content on Brooks' work, even if transitively.

It is surely much more pragmatic to read a book with "Agile something" on the cover, drinking from the derived work. This is good enough for most practitioners.

If you don't understand what the situation was before that, though, agile becomes just another cargo cult (I'd say it's been one for quite a while). Knowing where our techniques come from is not nostalgia, it's History.

But I can see how people get frustrated with old, "classic" material. Authors use their current environment to illustrate how to apply the principles they had in mind. Some literature, like the Agile Manifesto and its practices try to be smarter by not mentioning specific technology; but this is not the norm; even for books published today.

There is always plenty of demand for books using some technology, even if the actual content is just recycled. In 2002, Uncle Bob released a book called "Agile Software Development, Principles, Patterns, and Practices". I found it great, and when Amazon recommended me what looked like a new edition of it I placed my order immeditaly.

What i didn't realise until I got my copy was that it has pretty much no difference to the first edition. The ideas, patterns... all important stuff was just the same, except that they used another language in the examples.

I surely prefer what was done with Domain-Driven Design. The book itself uses Java to illustrate its ideas, but it doesn't use more than the basic features of a class-based object system. Some authors then published books mapping the ideas to actual technology stacks, like 'enterprise' Java and .Net.

Outdated? Really?

Jaco works for ThoughtWorks. I was with them for four years (I don't think we overlapped), and a lot of my time there was spent on recruitment.

One day, I was interviewing a candidate for a development position. He submitted his answer to the coding challenge in JavaScript, and I was interested in how he coordinated multiple events happening on the browser window --it was a very nice animation.

As he was speaking, the technique sounded familiar and I asked a tricky question: "Sounds cool; did you invent this?"

He was young and never did anything that wasn't JavaScript before, so I expected to hear a proud yes. I was surprised when he said "Oh, not at all. This is the kinda stuff they used in old video-games". What he had was, essentially, a port of a very old-school, single-threaded game loop.

Outdated techniques may not be useful in our mainstream enterprisey world, but a good developer needs to learn about them so that they can at least know what to Google for. The limitations of browsers, mobile devices, big data platforms and so many cool tech are not that different from the limitations previous generations had to deal with. Again, it's History and you either learn from it or repeat the same mistakes.

Different opinions are good

Fred Brooks released a new book recently, it got a lot of attention back then and I read it as soon ad it was out.

I think people will be disappointed to know that his opinions haven't changed much over the past decades. It is still very much based on engineering and architecture (Brooks is an amateur architect). I am very sure that this has to do with the fact that Brooks is not like most of us, working for a company writing web apps. His perception of the field is different. That doesn't mean, though, that I cannot learn from him. His words on design consistency and trade-offs are really inspiring.

We talked about this topic a while back and, as I said then, I try to not let my limited vision of the development world get in the way when I am reading a text by someone who doesn't share the same tiny corner with me.

I never engineered a computer architecture or wrote an operating system. No software developed by my teams was ever considered "to be one of the most successful computers in history, influencing computer design for years to come"; so when someone on his position writes something I am eager to read it; even if it is not directly applicable to my current situation.

Better Functional Design Through TDD - Slides

2011-11-06T23:00:00Z

As mentioned before, last week I gave a presentation to the Clojure Berlin Meetup on how Test-Driven Development can help achieving better design in functional languages. Slides here:

Better Functional Design through TDD

View more presentations from Phil Calçado

This is a theme I want to explore more, so expect new posts soon!

Slides: What I Have Learnt Working With Startups

2011-10-28T22:00:00Z

I am in Hamburg for the awesome RailsCamp Hamburg 2011. Here are the slides from my presentation on startup culture vs. tech debt:

what i have learnt working with startups.

View more presentations from Phil Calçado

On The Testing In Clojure Debate

2011-10-07T22:00:00Z

As said before, I recently moved from London to Berlin. Last week was my first time at the Berlin Clojure User Group, a very friendly and interesting meetup.

At some point, the conversation focused on testing in Clojure. Recently, Rich Hickey said something at the Strange Loop conference comparing Test-Driven Development to driving a car around banging into the guard rails --I actually don't know the exact words, I wasn't there and didn't see any video. This is not the first time Rich says something like this, and years ago Donald Knuth said something similar.

It should be very clear to readers of this blog that I use Test-Driven Development in pretty much all code I write; but I have absolutely no problem with what Rich or Don said.

I have a limited view of the development world

Over the past decade I've been writing systems for banks, real-time billing systems, massive scale multimedia distribution and all sort of application domains. I am convinced that this kind of work benefits a lot from having executable specifications written up front, and to me the best way to write executable specifications is with tests. I was never paid to write a programming language or any hardcore systems-level code, though

Just as some hardcore systems programmers tend to say things that are completely bogus in my world (in the old days this would be something like "real men write it in C"), I am aware of the fact that I shouldn't try to sell the tools I find useful in my tiny little corner of the development world to everyone.

I have friends who solve hard problems without even running a test for months, and it works for them. Could their feedback cycle be made shorter by introducing TDD cycles? I suspect yes, but I have no experience in the kind of work they do; so instead of bringing in my pitchfork and torch I would rather seat down with them over beers and compare notes.

TDD is neither requirement, nor guarantee

One thing I've learned early in my career was to always read the source code of whatever tool I am using. Since I started playing around with Clojure I tried to get myself familiar with the implementation of the language, and even hacked around a bit whenever there was some need or opportunity.

As someone who spent the past few years reading the Clojure code base every now and then, I don't have a lot to complain about the readability of the code.

Interestingly, the same mindset of always read the source code made me read many frameworks, libraries and tools in multiple languages. There is little correlation between readable code and usage of TDD by the author; even though usage of TDD by the developers makes me much more confident in changing code and sending a patch, even if the code is a mess.

There is no real guarantee that a TDD code base will provide you with better or more readable code; what TDD helps with in this case is making it much easier to know if a change to some piece of --good or bad-- code is correct or if you broke something by mistake.

So...?

So what's the deal, should we do TDD in Clojure or not? I surely believe that most people would benefit from TDD in Clojure, Scala and other Functional languages; it works for me, has been working for a decade. I am more than happy to show you how so, and see if I can help you in applying the techniques I use in your reality (in fact, I just proposed a Better Functional Design in Clojure through TDD talk for the next Berlin Clojure meetup, you should come along!), but there's no way I would say that this is the only way to have a good and reliable code base.

That said, just as I see a lot of die-hard TDD people complaining about Rich and Don's words, I see a lot of cool kids using them to ditch good practices in software development as something irrelevant in Clojure. Well, the last time I saw this happening was a couple of years ago, when the Ruby on Rails cool kids decided that Ruby was so awesome that they could just drop whatever practices they thought were not cool. The consequences of this mindset are not, well, awesome; so be careful here.