Lately I've been thinking a lot about how we can improve our code by reflecting on our mindsets and motivations with respect to software testing. A while ago, I wrote about the huge impact that prompts have on how we grow code (even the parts of speech we use to name objects). Later, I sat down to illustrate a taxonomy of the types of tests I tend to see in the wild. Recently, I wrote a bit about our natural tendency to misplace blame when testing gets hard.
"This test is too coupled to the implementation."
This complaint is commonly levied when—on account of test double setup—you have spec code that looks a lot like the subject's ("SUT's") implementation code. I hear this complaint most often in cases where the subject has little responsibility beyond passing a value from dependency A to dependency B and returning it.
Because isolation tests specify not only the externally observable behavior of the subject, but also the subject's contracts with its collaborators, it should be obvious that isolation testing is going to bring complex interactions with collaborators to the forefront in a way that an integrated test would not.
I have a lot of empathy for people that work at big companies. No one should be required to use a crappy ThinkPad loaded with sluggish, productivity-monitoring software. No one should be forced to communicate through a regimented, politicized hierarchy to do their job. No one should have their actions decided for them by someone else, especially because no one else has a better chance of determining necessary actions than the person who is closest to the work.
Has anyone else wondered whether our habit of organizing user groups around a programming language (Java, Ruby) or a technical stack (.NET, iOS) has outlived its usefulness?
Lately, a group's language preference seems to be an unhelpful way to subdivide our community's interests. JavaScript frameworks are all the rage at Ruby user groups. RubyMotion talks are about to inundate iOS user groups. And I've seen "mock objects rock" and "mock objects suck" talks at numerous groups of different languages (noting that mock confusion differs only in dialect from group to group).
Many people who practice test-driven-development completely surrender the practice when they undertake writing code for user interfaces. It's something I observe often as I try to sell people on TDD for JavaScript. The arguments I hear most often go something like, "testing DOM/jQuery/view code isn't valuable", or, "testing a view is a waste of time—I can see that it's working as quickly as I can run a test!" After all, it might take no longer to hit Cmd-R (or F5) in a browser than it takes to run a unit test.
I want to spend some time documenting the different types of automated tests I encounter most often, detailing each type's distinct characteristics, advantages, and challenges. This is not a novel concept, but since many developers I interact with continue to conflate, confuse, and generally stumble over this issue, I figured it couldn't hurt to share my perspective. I'll take a first swing at this post by using the terms I prefer, but I will gladly update it in response to your feedback—after all, any taxonomy is only useful if everyone in a given group can largely agree on it.
I was honored to present this talk at Agile and Beyond 2012 today.
Embedded below is a screencast of the talk (hosted on vimeo) as it was presented, with audio:
Embedded below is my slide deck (hosted here by my gracious friends at SpeakerDeck):
If you have any feedback—questions, comments, criticisms—I'd love it if you left a comment on this post!
Update 2/5/2012: replaced the jasmine-fixture description with examples using the current "affix()" API method.
One of the questions I'm frequently asked about test-driven development with Jasmine is a variation of, "how do I get my specs to see my HTML?" It's a completely fair question: JavaScript very often inspects or manipulates the DOM, so having a way to arrange the DOM's state with HTML is critical to writing tests.
My goal this morning is to explain why exactly I recommend against loading HTML fixtures from external files when writing unit tests.
My spouse and I share an Apple ID. But we also maintain separate Apple IDs. Paradox.
Why? Because nearly a decade ago, it took us all of fifteen minutes to realize that we were purchasing the same songs multiple times from our separate computers.
That realization—and the subsequent decision to share an Apple ID for purchases—has made each new Apple software upgrade increasingly complex over the years. So I made a chart!
All metaphors break down with sufficient mileage.
[And they often break down quite quickly, like that car metaphor I just made.]
Because metaphors break down, it's worth pondering the fact that most of humanity only comprehends software through the use of metaphors.
My proposal today is that we start treating software metaphors with greater skepticism.
First things first: let’s square up terminology. For the sake of facilitating sane discussion on this topic, I’ve adopted the terms used in Gerard Meszaros’ XUnitPatterns book. He drew a complex table for this, but I’ll quickly summarize here:
When it comes to test doubles available to Ruby developers, something has puzzled me for a while. Many of the brightest minds in testing left Javaland to join the Ruby community. Because of this, I was shocked to find that Mockito—a test spy framework for Java—is a more expressive tool for working with generated test doubles than any of the numerous libraries available for Ruby.
This post is partly in response to to this tweet, and partly a follow-up to a teaser I tweeted earlier this week.
We humans are suckers for suggestion. If you need evidence of this, consider something as seemingly innocuous as the order in which we ask people questions.
If I were to ask you:
1. Does the following web site load properly in your browser? Make sure all the pictures load: cuteoverload.com
2. Do you support the euthanasia of stray bunnies brought to animal shelters?
When someone applies to Pillar, we invite them to submit a code example that solves a particular problem. We review the code as an input early in the interview process.
It’s a helpful component of getting acquainted with a candidate, but a few things aren’t ideal:
Here’s an idea that might address those concerns: let’s start asking candidates to submit something useful instead.
Hypothetical: you find what seems to be the perfect prospective client. You’ve collaborated to develop an idea with the potential to realize outstanding value. They’ve decided they trust you to capitalize on the opportunity and achieve that value via some new software system.
*But!*
But the prospect makes a point to tell you they don’t want to be trained or changed (and that you can forget about “transformed”). They compensate by emphasizing that their only objective is to produce that set of value-creating widgets the two of you dreamed up in the (much cozier, in hindsight) first paragraph.
Ron Jeffries just posted a terrific case for clean code, and decoupled a recently-emerged “code can be too clean” meme from a question that has actual merit, “can we spend too much time making code clean?”
Upon discussing the post with Kevin Baribeau this evening, an anecdotal correlation was identified between folks who’ve said things akin to “code can be too clean” and folks who tend to succumb to the pressure to rush development of features.
Over the last year, I’ve made an effort to better identify the styles, idioms, and smells I encounter when reading and writing new Java code. [And, already, a takeaway point! To some of my more successfully sheltered rubyist friends, it may be sorry news to hear that there continues to be new Java code written.]
In any case, I’ve made a concerted effort to internalize habits that I find valuable and to develop a reflex to resist those which I do not. This will be my first effort at documenting either, so I’ll just express them in terms of how my Java looks these days, replete with code snippets as needed.