The RSpec Book

The RSpec Book

First, let me thank you for this great book. It is the main source for my thesis. And without the beta book I would have a problem. So thanks a lot.

In Chapter 11.1 (Beta6) you wrote, that “Enough up-front thinking” comes with BDD and that this is a great benefit, because “no up-front thinking” is simple irresponsible. Now I wonder how TDD behaves in this point, in comparison to BDD. Is TDD a methodology that tends to “no up-front thinking” or is there no different to BDD? Or to ask in other words: is “Enough up-front thinking” a unique feature of BDD?

In my opinion TDD isn’t really a “No up-front thinking” method either. Both approaches encourage developers to pause and think about the design as and when it’s needed.

“Enough up-front thinking” is a balance between waterfalls ‘Everything up-front’ and perhaps some peoples ideas of agile being ‘Nothing up-front’ (or making it up as you go along).

“Enough up-front thinking” is very good advice, think just enough ahead to leave yourself room to adapt to changes in requirements and assumptions. TDD and BDD let you do that.

*Edit: the difference I see between TDD and BDD is the point of view. TDD takes the point of view that you design and test an API to ensure it provides behaviour, while BDD takes the point of view that you want to design and test behaviour provided by an API. OK it’s very ‘grey’ but the emphasis is different BDD produces a testable specification, TDD produces a testable API.

These are my opinions. If you feel I am wrong then please let me know.

thanks a lot for your answer. Any suggestions and comments are welcome.

You made some good points, I have to think about. The transition from TDD to BDD is an important part of my thesis, and that the difference between TDD and BDD lies in the point of view is an interesting definition.

Regarding to my question about “up-front thinking” I am still not sure, if there is a difference between TDD and BDD or not. I am thinking about something like “Using BDD you must do ‘Enough up-front thinking’, using TDD you should”. Perhaps anyone here has additional suggestions.

I appreciate that this is a bit confusing, especially in light of the fact that the meaning of what BDD is has evolved over the years since its introduction. At this point, and I think this is made clear in the book, BDD has evolved to a methodology that includes TDD as a practice. We still use the language of BDD to approach TDD from a different angle, but the process is exactly the same: red/green/refactor, small steps, etc.

In regards to enough up-front thinking, there are a series of scopes to which it applies. When you’re in a release planning meeting you want to do enough up-front thinking to be able to start working on the release with confidence. This will likely include considerations like business strategy, marketplace, etc.

In an iteration planning meeting, the scope is narrower. The goal is still to do enough up-front thinking to start working on the iteration with confidence, but the considerations tend to more about the functional details of specific features that we’ve already selected in the release planning meeting. Perhaps you don’t do separate iteration and release planning meetings, and that’s fine, as long as you recognize that even in the context of a single meeting, the concerns for release planning are wider than the concerns of iteration planning.

Within an iteration the scope is narrower yet. You still want to do enough up front thinking, and perhaps you’ve recognized some design challenges that are presented by the features slated for the current iteration. In that case you call a design meeting with your peers. The goal here is stay within the scope of what you’re doing this iteration.

Then, when you get down to the minute to minute practice of doing TDD, the scope is even narrower. The focus is on objects and how they respond to events in given contexts.

At each level, we’re informed by what we know from the wider scopes, and we can’t help but consider the things we know. We’re human, after all. The trick is to avoid the temptation of considering the things we don’t know or are not relevant to the task at hand.

I once heard Mike Cohn describe the idea of a planning horizon. I think it’s described in his book Agile Estimating and Planning as well. The premise is that when we’re planning anything at all, the closer we are to taking specific actions, the more detail we need to consider. The inverse is true as well: the further out the actions are, the less detail we need to consider. When we’re sitting down to write code, we have a lot more detail in mind than when we’re considering introducing a new project.

thanks a lot for your reply. I didn’t consider the different scopes. But I think this makes sense. And I like the phrase, that BDD is a methodology that includes TDD as a practice.

In reply to Derek:

The experience with the work on my thesis is, that it is very difficult to determine, which xDD methodology is inspired by an other xDD methodology. On my initial research I found an articel written by Tracy Reppert titled “Don’t just Break Software, Make Software”. The article is about storytest-driven development, and I wondered why this is called STDD, because for me it was BDD. And then I saw, that STDD was first used in 1999 and Dan North started his work on BDD 2003. Even this article was published 2 years before Dan’s article about BDD. This was a little bit confusing at first. But now, four months later, I think, that you can break down most of the xDD and agile methodologies to the same elements., like automated developer tests, automated acceptance tests, refactoring, small iterations and so on. They mainly differ in their scope, point of view, linguistic features and tool support.

The book you mentioned is the first I know, which decribed TDD with inner and outer loop. For the TDD aspects in my thesis I use the books from Kent Beck and David Astels and I do not remember that they wrote something like this. But based on the sentence “BDD is TDD done well” this makes sense.

Sorry for the delay in replying - I’m just catching up with the forum.

The link you posted from mockobjects.com looks like a recent draft and it’s an interesting development. TDD historically has only ever concerned itself with what we would call the code example level (i.e. the level addressed by rspec rather than cucumber). It is interesting to see that some of the TDD folks are now retroactively absorbing acceptance test-driven development (the “outer testing loop”) into its definition.

It doesn’t surprise me that there are a number of earlier references to acceptance test automation, and using this to drive development at the feature level. For example it was this that inspired Ward Cunningham to create FIT (as a Functional Integration Test framework). One of the differences with BDD is that it uses a consistent language and approach at both the story and code level, which makes the transition between the two more natural in your day-to-day work. Remember, it’s all behaviour :)

On a tooling level there are a number of challenges in expressing behaviour with a purely tabular model like FIT. ucumber’s hybrid approach - mixing Given/When/Then narrative with optional tables - makes this much easier and more intuitive, and lends itself better to reusing fragments of story automation.

The prhase “BDD is TDD done well”, while a nice compliment, is a bit out of date. As David mentioned, BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space - around 2003-2004 - this was a valid description. Now it only covers a small part of the BDD proposition.

I hope that helps. I’m currently reworking the “Writing software that matters” chapter to provide a richer definition of BDD, which hopefully will help to clear up some of these gaps.

thanks for the great rework. From my view, the chapter provides a better definition now, what BDD is about. And additionally I have a better understanding of Elizabeth Keogh article at InfoQ, espacially about the transition between vision and feature set.