1.) I’ve never fully grasped Behavior-Driven Development.  Many highly nuanced descriptions of BDD exist, but none is straightforward.  What’s the main idea?

BDD ain’t easy. But there’s a good way to hack the learning curve; adopt the following two axioms:

1. BDD is not testing. Anyone who wants to understand and practive BDD must forget all notions of testing. This can be a challenge since we use the word “test” so frequently in reference to BDD (e.g, “test suite,” “test coverage” etc.). But the word “test” puts us in the wrong frame of mind.  This is because:
2. BDD is a design process. When practiced correctly, BDD helps developers design a system, from the classes and their interactions down to individual methods and their behaviors. This is what is meant by Behavior-Driven Development. The developer makes decisions about a particular class interface, for example, and then implements.

So, again, to begin to understand BDD, first eliminate any reference to testing lingering in your mind. Then, meditate. Here’s your mantra:

BDD is a design process.

2.) But I still find the words “Behavior-Driven Development” misleading. I keep thinking of “Test-Driven Development,” and, as you say, I should stop thinking about testing.

Yes, it seems that the words “Behavior-Driven Development” have meaning only for the initiated. Let’s use another term altogether, at least for the remainder of this FAQ. We’ll call this design process Design-Build Development. It keeps the mind on track. First design, then build.

3.) Ok, so what’s Design-Build Development?

Design-Build Development is an iterative four-step design-build-verify process.

Step 1: Design

Using a design-build framework (e.g., RSpec, Shoulda), specify how a some bit of code should behave.

For example, suppose I’m building a web crawler. I have a Cralwer class, which is somewhat fleshed out, and an Indexer class, which I’ve yet to work on. The important thing to notice is that as I specify behavior,  I’m deciding how the crawler will interface with the indexer.  Here’s my specification (using Shoulda):

I mock the method add_url on the indexer. So my thought process is something like, “Well, let’s say that we’ll build a method on the indexer for adding urls. We’ll call it add_url, and it’ll return true if the operation is successful.”

The benefit here is that I get to decide how the Indexer class will behave even before I’ve written any Indexer code!

Step 2: Run the design verifier.

I run the design verifier (a.k.a tests) and receive an error saying that @indexer did not receive “add_url.”

Step 3: Build

Now, I write the code that satisfies my specification (Note: highly oversimplified).

Step 4: Verify

I run the verifier again. Now that I’ve added “@indexer.add_url”, I don’t receive any errors.

By running the verifier, I assure myself that the code conforms to the design.

Then I go back to Step 1,  continuing the design-build process.

4.) What’s a design framework?

Examples include RSpec, Shoulda, Test/Spec, and many others.  A design framework allows the programmer to translate her design into code. It’s what most of us call a testing framework. But in the case of BDD and DBD, we want to eradicate any reference to testing. Therefore, we call it a design framework.

5.) So, Design-Build Development doesn’t require a special framework?

Not at all. Because DBD is a reframing of BDD, any of the BDD tools can be used to do DBD.

6.) Why is it important to avoid the word “test” when thinking about BDD and DBD?

Design-Build Development is first, and foremost, a design process. When engaging in DBD, we are specifying the design and behavior of code. This must not be confused with writing tests. To use the word “test” is to shift the mindset from “design, then build” to “build, then test.”

The design mindset says, “I’m crafting this system. I’m creating classes and deciding how they interface with each other. As I design, I implement my specifications little by little.”

The test mindset says, “I just wrote a bunch of code; now I’m gonna write some tests to make sure that everything works like I think it should.”

In the first case, the mind wields the power; in the second, it’s the code that rules.  The test mindset puts us at the mercy of the codebase.

7.) I see. Design-Build Development values the programmer’s intentions over the whims of a codebase.

Exactly. Design-Build Development is an intentional approach to writing code. It elevates our frame of mind, focusing our energies on one chunk of the system at a time.

Design-Build Development seeks to counteract what the Pragmatic Programmers call “programming by coincidence.” In the worst case, this means unreflectively writing code for weeks on end until we’ve created a monster.  Once the monster is born, our coding degenerates into a series reactive strategies to keep it in check. Tweak here, bug fix there. Anything to keep the codebase happy (and working).

Programming by coincidence engenders chaos in the mind. Design-build development, by contrast, encourages focus.

8.) What are some other benefits of Design-Build Development?

Practicing Design-Build Development, we slowly build up a wall of [specifications] that cannot break without our immediately knowing about it” (paraphrase of Ruby Test::Unit docs). This inspires confidence; it assures us that future changes to the system don’t break the behavior of any other part of the system.

At the same time, the design-build process produces a specification of our system in code, so we get documentation for free.

9.) Why do we need yet another conceptualization of xDD?

Those who already understand BDD don’t need this FAQ. My hope is simply that anyone who hasn’t internalized BDD will gain some insight from the ideas presented here.

There are three obstacles preventing a wider adoption and understanding of Behavior-Driven Development:

1. Emphasis. BDD is a design process. This is the fundamental insight, but it’s rarely emphasized.
2. Testing. BDD connotes testing. But this works against (1), that BDD is all about designing a system. The testing mindset and the design mindset do not peacably coexist.
3. Naming. BDD sounds like TDD, and the words “Behavior-Driven Development” are not sufficiently precise. I believe that the term “Design-Build Development” more accurately indicates what BDD is. These words are a better starting point for the BDD novice.

If we introduce BDD as Design-Build Development and then emphasize the value of thinking of BDD in terms of a design process (and not as testing), I believe we can effectively lower the barriers to adoption and understanding.

10.) Where can I read more?

For an essay on the importance of thinking in terms of design, read Paul Graham’s “Taste for Makers.”

For a great discussion on the BDD learning process, read the Introduction to Behavior-Driven Development at behavior-driven.org.

Updated 9/26/08: Fixed some typos and omissions.  Added should_route and should_render_with_layout (Thanks to Dan Croak and Michal Szajbe).

I’ve created a basic Shoulda cheat sheet.  Along with Topfunky’s Ruby on Rails Testing Cheat Sheet, it should be a good reference, especially for those migrating from RSpec.

Shoulda Cheat Sheet

Designers running free, creating without concern for the production is nonviable. Designs can become hinged to interactions that will not work, with the compromised result damaged to the point of mediocrity. Engineers paving the way is just as fruitless. Solutions will lack elegance and beauty. A utilitarian wonderland of marginal design with exquisite engines. Volvo-world.

To see engineering as divorced from design is to fall prey to an even greater fallacy: that design and engineering are entirely separate disciplines.  It is tempting to think of the engineer as mere implementer, as one who mechanically applies the laws of physics to make a design reality.  Many also find it convenient to assign all creative control to the designer, as if engineers were somehow devoid of creativity.

This kind of thinking quickly crumbles once we reflect for a moment on elegance.  Elegance, as David Gelernter defines it, is the combination of simplicity and power.  The human mind, with its innate aesthetic sensibilities, quickly apprehends elegance, and that is why we love Velcro, the iPhone, suspension bridges, object-oriented programming, and the jet engine.

But its not just simplicity and power. These inventions are elegant because, in their design, they fit snugly within the jagged spaces between the laws of the physical world and the modes of human being.  Put more colloquially, they are effective and user-friendly.

It should be immediately obvious that cooperation between engineers and designers is only the minimum requirement for such elegance.  Even better would be engineers who read Shakespeare and designers who study physics: engineer-designers, as it were.  For without creativity, engineers cannot produce elegant solutions.  And lacking knowledge of the physical world, designers work against nature. 

The ideal, then, is a sort of Leonardo da Vinci, the Renaissance man with a sense for beauty and mystery and a keen understanding of process and physical law.  For engineering and design are much more intertwined than they appear.

Shoulda provides an elegant DSL for doing Behavior-Driven Development in Test::Unit.  In addition, Shoulda includes macros for many common tasks in unit and functional tests. Thoughtbot, the company behind Shoulda, has created an excellent tutorial.  I also recommend Tammer Saleh’s presentation on BDD with Shoulda.

The Trouble with RSpec
Part of my newfound enthusiasm for Shoulda, and Test::Unit in general, stems from a comment made by Saleh in the presentation mentioned above.  He points out that a change in the implementation of a method should not automatically cause that method’s tests to fail.

This was my experience with RSpec, particularly when it came to testing controllers. The RSpec controller testing philosophy favors heavy mocking.  The rationale, as I understand it, is twofold: 1) mocking isolates the testing of the controller from the model, and 2) mocking allows for the testing of a certain kind of behavior, which, in this case, seems to be the explicit expectation that certain methods will call certain objects and return certain other objects.

This test-the-implementation philosophy resulted in brittle tests. Slight changes to a controller method would frequently cause the tests to fail. To repair them, I would spend time tweaking my mocks and stubs so that they would fit the new implementation.

Sure, the religious BDD way would have me adjust my tests first. But if the behavior of the controller hasn’t changed, does it make sense to go to all the trouble? When I consider controller behavior, I think of which instance variables are populated, what’s rendered, where the controller redirects, etc. Implementation, it seems to me, is not behavior.

Two notes
First, mocking is a great boon when used judiciously, even when testing controllers.  It’s beneficial to be able to mock, say, authorization methods.  But ActiveRecord models?  I’m not so sure; I’d love to hear any arguments to the contrary.

Second, this is not meant to write off RSpec once and for all; I mostly enjoy it, having recently completed a lengthy project using the framework.

Conclusion
Shoulda’s clean syntax and time-saving macros are reason enough to check it out. Regardless of where you fall in the mocking debate, you may find Shoulda quite charming.

The most effective, most creative problem solvers engage in a process of meta-thinking, or “thinking about the thinking.” Meta-thinking means that you are aware of how you are thinking as you are doing the thinking. Meta-thinkers engage in continual internal dialogue of testing, stretching, criticizing, and redirecting their thought processes.

Still, it doesn’t hurt to have principles to guide practice. I stated in my last post that such principles, while sparse in the Ruby literature, are readily found in the Smalltalk canon. One example is Alec Sharp’s concise Smalltalk By Example. This book is not a manual on Smalltalk, as the title might suggest, but more a series of meditations on good coding. In a mere six pages, the chapter Object-Oriented Thinking conveys a number of essential principles. Here are some of my favorites:

1. Write Down the Concepts

Sharp advises us to “think in conceptual terms rather than worrying about the details.” He goes on: “Someone should be able to easily read the method to see what it’s doing (short methods, very descriptive names), without actually seeing any of the work done.” This is the same idea that Kent Beck communicates through his Composed Method pattern (from SBPP). Write methods that read like documentation:

2. Put Off The Work

A related principle is that methods should be short (fewer than seven lines). One way to keep methods short is to put off the work. “Smalltalk might be considered the procrastination language - procrastinate as long as possible and maybe you won’t need to do anything.” This helps to assure that each method expresses just one concept, leading to a more object-oriented system.

3. Tell, Don’t Ask

If we want to write good, object-oriented code, we have to focus on sending messages. “Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.” Instead of writing this:

We simply write:

Each vehicle knows how it’s supposed to move. Each class (Car, Helicopter, Bicycle) defines travel in the appropriate way. We don’t make decisions for the vehicle; we just tell it what to do.

4. Don’t Check the Results of Doing Things

Similarly, good object-oriented code should not check the results of sending a message. “In a Smalltalk OO system, it’s much more appropriate to just tell an object to do something, then forget about it.” How do we handle errors, then? Exceptions, of course! Writing code that elegantly raises and handles exceptions is one of the keys to clean, object-oriented code.

Conclusion

Are these observations groundbreaking? No. But they’re fundamental, and, as I said before, they don’t often appear in Ruby books. Heeding them will yield readable - even elegant - code. And in the long term, they may help us on our way in the art of coding.

Ruby’s debt to Smalltalk is no secret. So much of what we love about Ruby - pure object orientation, the Enumerable module, closures, and the inject method - derives from a language twenty years its elder. Rubyists may have much to learn from Smalltalk.

This is especially true given that the Ruby literature, as it stands, consists mostly of syntax and language fundamentals. Books on design, style, and patterns in Ruby are few. In Smalltalk, they seem to abound.

In my relatively superficial survey of a site containing free Smalltalk books, I’ve discovered a significant repository of ideas on object-oriented design and programming.

This is understandable for a least a couple of reasons. Obviously, Smalltalk’s literature has had more time to mature. But perhaps more importantly, Smalltalk grew up in an age when OOP was not yet the dominant paradigm. Therefore, it would have been important to advocate for the OOP philosophy and coding style.

This advocacy is still important; hence, the continued appeal of Kent Beck’s SBPP. While the book may be ten years old, and the Smalltalk language somewhat beyond its prime, there’s much to be gleaned from this gem of a language and its literature.

Now, I often find myself writing Rails helper methods that act on Ruby classes (String, Array, etc.). But to keep my code clean, I like to refactor these helpers as core extensions. This is a useful refactoring pattern for Rails applications. We might call it

• Replace Core Class Helper with Core Extension.

I’m going to show you how to include core extensions in your Rails app. Then, I’ll describe four extensions that I commonly use.

1. Write Your Own Core Extensions

First, create a module, name it core_extensions.rb, and store it in your /lib folder.

Then, at the very end of your environment.rb file, require the CoreExtensions module.

2. Format a string as a possessive.

These two methods extend the String class. The first returns the last character of a string. The second produces the possessive (’s) form.

Here’s how it works:

3. Format Time as Month / Day / Year
Times needs to be formatted in all kinds of ways. Here’s just one example:

And it works like so:

4. Display an array of ActiveRecord objects.
It is often necessary to iterate through an array of ActiveRecord objects, surrounding each with an html tag. Here’s an extension to array to automate this:

How does it work? Say you have a recipe application. You need to display a list of recipe titles, each within a paragraph element:

5. Get class name as string.
Here’s a simple method that comes in handy when using inheritance. Sometimes, you just don’t know what sort of object you’re dealing with. The class_name method does just what it says, giving you an easy way to display information about your object.

Suppose I have a class modeling vegetables in a garden. If I needed to display a message about a particular vegetable, I could use class_name like so:

Summary

Next time you write a helper that acts on a basic Ruby class, consider writing a core extension instead. Using core extensions can help create more elegant, portable, maintainable code.

But there’s no overarching plan for subsequent posts. My hope is that, at least, this blog will give me a chance to improve my writing, examine new ideas (in the world of coding, and elsewhere), and participate in the great dialog afforded by a technology so commonplace that we rarely stop to think just how remarkable it is.

Cheers!