A little about my mom: she’s now in her fourth year “in exile”, living in New Jersey acting as a full-time caregiver for my grandparents (now just one grandparent). Her computer is pretty much her sole link to the wider world; whether it’s communicating with friends and family, staying way ahead of me (still!) in finding awesome new music, or, occasionally, writing poignantly about caregiving and other topics.

As you might imagine, hers is not a high-income line of work. Or any-income, really. So:

If someone out there happens to have an older model (but still functional) MacBook lying around collecting dust, and you’re willing to part with it for cheap or free, please get in touch. Thanks!

As a community we also like our colorful gem names. A little while back someone wrote a blog post about some of the more questionable naming choices. Which got me thinking about one of my own gems.

The gem in question is HookR. It’s a library I wrote a few years ago for adding event hooks to arbitrary classes and objects.

The name amused me at the time. Actually, let’s be honest, the name still amuses me. But I’m also concerned it could be offensive. Not in an overt, groping-bottoms-at-a-conference kind of way, but in that insidious way that monocultures tend to be subtly threatening to outsiders without even realizing it.

As I personally read it, it is not gender-offensive since “hooker” is a gender-neutral term. However, it is potentially offensive to sex workers. And anyway, as I’ve noted before, ultimately I’m not the one who gets to decide which of my statements are offensive.

So my question for you: is HookR an offensive name? I realize it’s an unconventional, non-enterprisey name; that much I’m OK with. But is it offensive? Is it amusing, or is it off-putting?

And if you do find it problematic: can you suggest a better name?

Something I’ve noticed over the past few years of web programming is how it’s slowly becoming more like the systems/realtime/embedded programming I once did. Not exactly like it, but similar.

In the early days the difference was stark: as Tim points out, the stereotypical web app is an input/output machine. Requests go in, responses go out. Everything you do in a web app occurs somewhere in between receiving a lump of data and pushing out another lump of data. You don’t have to coordinate multiple threads; the app server does that for you. You don’t have to worry about race conditions; database transactions take care of that for you. It’s a black box: data goes in one end, different data goes out the other.

The big difference Tim sees between web programming and device programming is the number of APIs you typically have to deal with:

4. Touch-screen in­ter­ac­tions.
5. Tele­phony.
6. More radio in­ter­faces, po­ten­tially: WiFi, NFC, and Blue­Tooth.
7. A GPS and com­pass and maybe al­time­ter.
8. Audio gear, in­clud­ing speak­ers and a mi­cro­phone.
9. A cam­era, with a sen­sor and lots of con­trols.
10. An ac­celerom­e­ter.
11. Last but not least, a vi­bra­tor.

The thing is, web programming is starting to look more and more like this, as web programs become nodes in ever more complex constellations of services.

1. Semi-smart clients which are asynchronously pulling data, or expecting you to push data, via Websockets and other technologies.
2. Multiple data stores (e.g. Postgresql and Redis) which may become inconsistent if you’re not careful.
3. A service for sending and receiving email.
4. A service for sending and receiving SMS messages, IMs, or voice calls.
5. Integration with a half-dozen social networks
6. Dedicated work queues for long-running operations

And much like the many data busses embedded programs have to coordinate (RS-232! USB! Ethernet! 1553!), often each of these external  services requires a slightly different kind of impedance-matching code in order to talk to it.

What’s especially reminiscent of  systems programming is that any one of these services can fail. In the primordial web app, a failure of the hardware hosting the app, or the database backing the app, is Not Your Problem. The request either works; or it has a software bug (which is your problem); or the platform fails (which is some poor overworked sysadmin’s problem). But when your app depends on a half a dozen services, any of which could crash, or get really slow, or go just plain wonky at any time, you have to start thinking about failure modes and exception safety and sanity checking and periodic self-tests.

I’m not sure if this new “cloud systems programming” will prompt a resurgence of interests in static languages. But I think it is causing a lot of programmers to rethink how web programs are designed. And a lot of the new thought is eerily familiar. For instance, a lot of web programmers appear to be rediscovering that RPC is a terribly leaky abstraction whether done via UNIX domain sockets or HTTP, and why systems that exchange fire-and-forget messages are almost always preferable.

On the whole, I’m excited about the challenges of heavily interconnected web applications. Yes, it brings with it a lot of the headaches I thought I’d left behind in the systems programming world. But these are interesting problems to solve. And there are few better feelings as a programmer than looking at a system happily humming away, knowing that inside there is an intricate dance going, dozens of inputs being handled and coordinated and dispatched, all according to your careful choreography.

Like I said I’m not experienced with this stuff, so this is just a collection of notes, not a recommendation.

• Lots of people pointed me to Faye. From the home page:
  

  Faye is a publish-subscribe messaging system based on the Bayeux
  protocol. It provides message servers for Node.js and Ruby, and
  clients for use in Node and Ruby programs and in all major web
  browsers.

• Pusher is a service I had already heard of, and it comes highly recommended from many sources. I know Larry Marburger uses it on CloudApp and has nothing but good things to say about it.
• Lots of mentions of Juggernaut. From the website:
  

  Juggernaut gives you a realtime connection between your servers and
  client browsers. You can literally push data to clients using your
  web application, which lets you do awesome things like multiplayer
  gaming, chat, group collaboration and more.

• Several people mentioned PubNub, which appears at first glance to be a similar service to Pusher.
• In addition, lots of people replied with various combinations of lower-level tools and technologies, including: Socket.io, Goliath, WebSockets, and EventMachine.
• EDIT: A couple people have also pointed out that TorqueBox provides built-in WebSockets support.

• About leveraging commonality: “large-scale software re-use has not proven to be the answer”. A lot of the mid-90s OO PR centered around the idea that we’d all build our apps out of reusable off-the-shelf objects. As Beck notes, this didn’t really pan out. With rare exceptions, in-process software re-use still takes the form it always did: it happens at the “library” level of granularity, not at the object level. Patterns have been a much more successful way to re-use ideas.
• “By carrying along their justification, patterns avoid the problem of most “style guides” that simply prescribe solutions without discussing why or when the solution is appropriate”.  Ironically, I often hear the criticism that patterns are “prescriptive, one-size-fits-all solutions”. When I hear this it makes me wonder if the person saying it has read a patterns book lately. Central to the form is a careful discussion of when the pattern makes sense, and when it doesn’t.

Once I got into the meat of the book I decided that, since I’m reading it for the Ruby Rogues book club, I should probably take a stab at translating the patterns to Ruby. You are welcome to follow my progress on GitHub:  https://github.com/avdi/sbpprb. Also, feel free to fork and submit pull requests for alternate translations. There is definitely room for interpretation on some of these.

• On Composed Method, this bit is key: ”keep all operations in a method at the same level of abstraction”. I hate it when I find a system that has been broken up into small methods—except that the small methods still combine high-level calls with fiddly, low-level code. Code like this has all the disadvantages of small methods (harder to follow the logic) with none of the advantages (only having to introduce a change in one place).
• There are a number of construction & coercion patterns early in the book. One thought that sprung out to me in reading these is that I don’t spend enough time thinking about writing alternatives to “.new” in Ruby code. More often, I just write a fancy “#initialize” which can handle various combinations of arguments. But there’s a good argument to be made in many classes for avoiding .new and instead defining more specific forms, e.g. Point.new_from_coords, Point.new_from_polar.
• That last point is relevant to Rails code. A lot of the specialized factory methods I see for testing (“Factory.create(:admin_user)”) really ought to have analogs on the original model (User.new_admin).

Some notes and quotes from the introduction:

• Defining patterns: “a pattern is a decision an expert makes over and over”.
• Patterns in the small: “I’m constantly amazed at how even a little help cleaning up small problems reveals the source and solution of much bigger problems”.
• “It is easy to get numbed to pain and frustration, or treat it as if is part of the territory”—this dovetails with a realization I had recently: my “Confident Code” talk, at its core, isn’t about clean code; it’s about joy. Programming in a conducive programming language should be pleasant. Fun. Joyful, even. Antipatterns steal joy because they add weight to every step. It’s worthwhile to periodically remember the joy of that first “a-ha!” moment in Ruby (or Smalltalk, or whatever), and figure out if and why we aren’t feeling that way anymore.
• “The very act of deciding what corners to cut slows down development. Using these patterns lets you program flat out, applying patterns as fast as your fingers will go, and get results as quickly as possible”. Beck goes on to say of adopting these patterns “whole hog”: “…I spent a couple of frustrating weeks programming at less than full speed. After that, I memorized enough patterns to get back up to my old productivity, but the code I was producing was cleaner than before. After a couple more weeks, I no longer had to look up any patterns, and my productivity shot up while my code kept getting cleaner and cleaner.”

This last quote nicely sums up an observation I’ve made over the years. A lot of programmers, when evaluating a new discipline, note (correctly) that adopting it will slow them down in the short term. They then extrapolate from this short-term slowdown that it will always slow them down, and is therefore a waste of time.

Maybe it’s just good ‘ole hacker hubris: the assumption that we can fully assimilate any new knowledge in a matter of hours, and if not, it’s not worth learning. In any case, it’s a flawed mental model. New disciplines, when practiced diligently, eventually become automatic.

Over the weekend I started writing it. I thought it was just going to be a sort of maxi-article, but I’m at 37 pages and I’m only 2/3 done at best. So far I’ve covered stuff like adding ActiveModel bits as-needed, Dependency Injection, and the Presenter pattern, but I’m sure there’s stuff I’ve missed. So I thought that while I’m in the process of brain-dumping all of this stuff I might as well open up the floor.

SO! What would you like to know about OOP on Rails?

To be a successful mockist, you must dislike mocks.

A lot of people re-tweeted it, so I guess I’m not completely alone in thinking this way.

I should back up a bit. A “mock object”, or “mock”, is a specific kind of test double. It is an object used in a Unit Test which stands in for another object, and carries certain expectations about how what methods will be called, and how they will be called. If the expectations are not met, the test fails. By contrast, other test doubles, such as stubs objects, make no assertions about which methods will be called. This article is specifically about mock objects and mocked methods, which make an assertion about when, how many times, and with what arguments certain collaborator methods will be called.

The term “Mockist” refers to those programmers who use mock objects in their unit tests. There is another camp of programmers, called “Classicist” by Martin Fowler, who eschew mock objects entirely in their tests.

Actually, if you haven’t read Fowler’s article on the “mockist”/”classicist” divide, go read it and then come back. There’s really no point in reading this post any further unless you have that as background. Fowler’s article is an excellent breakdown of the origin of the two camps, as well as a pretty objective evaluation of the pros and cons of both approaches to writing unit tests. Seriously, go read it right now.

I’m a Mockist. I write tests that make assertions about object interactions, not just about static outcomes. I’ve been doing it for a while, and I’m pretty happy with the results.

However, it’s a technique that’s very easy misuse. Applied poorly, it can lead to testing suites which are so brittle they have to be either extensively rewritten or thrown out entirely when it comes time to change functionality or re-architect the code.

Mock Objects are a Test Smell

When I realize that I’m using a mock where I shouldn’t be, it’s often because I haven’t spent enough time on my test tooling, and as a result I don’t have a good way to make assertions about method output.

For instance, the other day I was building a Presenter for some Rails code. The presenter held references to both a domain model object (an ActiveRecord instance) and the Rails “template” object which makes various HTML-building methods available. The presenter’s job was to take model data and format it for display.

One of the first tests I wrote went something like this:

This test asserts that the presenter will call the button_to helper to generate some HTML.

I’ve been making an effort to write isolated tests which can be run without loading the full Rails infrastructure. This test completely isolates the presenter functionality from that of its collaborators. It doesn’t require any actual HTML to be generated, it just asserts that the presenter must use the button_to method and return the result.

The test felt wrong as soon as I wrote it. It was clearly brittle. I could look ahead and imagine, as the requirements for the HTML became more complex, how the mock object would have to grow more and more mock methods in order to keep up. The tests would become, in effect, an exact replica of the method implementation.

I decided to change up my spec setup a bit in order to pass in a template object which included the actual Rails tag helpers. Then I included the Capybara spec matchers for making assertions about HTML. In the end, the spec looked like this:

The test is slightly less isolated now, but for a class which is all about generating strings, I think this style of test more suitable. Note that what I didn’t do was graduate the tests to the level of an integration or acceptance test. Instead, I added the minimum coupling necessary to get rid of the suspect mock object.

In my experience, well-isolated tests lead to neatly decoupled code. Not to mention that they run really fast. Rather than tie my presenter tests to the entire Rails stack, I let the mock object pain guide me to the one area where a little relaxation in my isolation discipline would lead to a big gain in productivity.

Mock Objects are a Code Smell

In the preceding case, the mock object was a test smell. But mock objects are more often smelly because they are telling you something about the system under test.

A Code Smell is defined as “a hint that something has gone wrong somewhere in your code”. A hint, not a certainty. Whenever I use a mock object to assert that a certain method call must be made, a little voice in my head says “should I really be using a mock object here?”. When a test has more than one or two mocked method calls, that little voice gets a lot bigger.

In my experience, multiple mocked methods often indicate that either a) the method being tested is trying to do too much; or b) the method being tested has high structural coupling. As I wrote in another testing article, mocks are like the hydrogen peroxide of programming. They “fizz up” when they encounter highly-coupled code. Show me a test with a lot of mocked method calls, and I’ll show you a class under test which violates the law of Demeter. And which is, consequently, a liability to future code changes.

Mocks act as a canary in coal mine: they are an early warning system that your code is beginning to depart from the path of small methods, each having a single responsibility, and each interacting with a very small set of collaborators.

Mock objects are for Design

Which brings me to my next point about using mock objects: mock objects are all about design. They were developed hand-in-hand with the “Behavior Driven Development” movement, which sought to re-emphasise the design component of TDD. Here are the inventors of mock objects, talking about them in the intro to an OOPSLA 2004 paper on using mocks:

Mock Objects is an extension to Test-Driven Development that supports good Object-Oriented design by guiding the discovery of a coherent system of types within a code base. It turns out to be less interesting as a technique for isolating tests from third-party libraries than is widely thought.

Guiding design isn’t just a side-benefit of using mocks; it’s the primary reason to use them.

Which means that if you aren’t using tests to drive your design, there’s little point to using mock objects.  I suspect this is the root of a lot of the the arguments over whether to use mocks or not; if your primary reason for writing unit tests is verification and avoiding regressions, mock objects aren’t going to buy you much. And people talking about how useful they are aren’t going to make a lot of sense.

Mock objects also make more sense in an outside-in model of test-driven development. They enable developers to ferret out the needed interfaces of objects that don’t exist yet. Many if not most of the mocks I write are mocks of classes and methods I have yet to write. The mocks I write while TDDing one layer of the design gives me the clues I need to work out the necessary responsibilities of the next layer down.

(By the way, that OOPSLA paper is full of good advice on how to use mock objects without shooting yourself in the foot. The whole thing is worth reading)

Mock objects are for Commands

This is a distinction that is just starting to become clear to me. You may be familiar with notion of  ”command/query separation“. This is when you make an effort to divide all methods into either command or query methods. Command methods cause something to change, either internally or externally to the receiver, and return no value. Conversely, query methods change nothing, (i.e. they have no side-effects), and are used solely for their return values.

As a general rule, I think mock objects are mainly useful when describing command methods. Their use is suspect for testing query methods. As a corollary to this observation, mocked methods with defined return values are often (though not always) a warning sign. I find most of my test doubles fall into one of two categories: stubs with no behavior, just a return value; and mocks that expect a certain method call, but define no return value (no ‘and_return()’, in RSpec terms).

This distinction has the side effect of encouraging you, as a user of mock objects, towards a design that has a strong delineation between queries and commands. This is widely regarded in OO circles as a Good Thing.

Conclusion

This has been a brain dump of some of my current thinking on mock objects. As such, it’s probably not as clear or well organized as it could be. To sum up: mock objects are helpful, but they are as often useful for drawing attention to problematic tests and code as they are for specifying object interactions. Mock objects are only a meaningful exercise when tests are being used to drive design. And finally, mock objects tend to make the most sense when specifying pure command methods.

I hope you find some of these observations helpful in your own TDD practice.

Posted from Diigo. The rest of my favorite links are here.