BDD = Behaviour Driven Development"Acceptance Test–Driven Planning is one of three practices of BDD. Itis an extension of Acceptance Test–Driven Development. The difference between ATDP and ATDD is simple. ATDD specifies thatwe write acceptance tests before we write code, but it doesn’t specifywhen we should write them.ATDP specifies that the acceptance tests are agreed on during or pos-sibly before, but no later than, an iteration planning meeting. This lets us consider the acceptance criteria in our estimates, which improves our ability to plan iterations, which is why it’s called Acceptance Test–Driven Planning.""The Scenario keyword is followed by a string and then a series of steps. Each step begins with any of five keywords: Given, When, Then, And, and But.*Given* steps represent the state of the world before an event. *When* steps represent the event. *Then* steps represent the expected outcomes. *And* and *But* steps take on the quality of the previous step. In the start game scenario, the *And* step is a second *Then*; a second expected outcome."111. "Perhaps you’re wondering why we’d want to do exploratory testing if we’ve already tested the app. Well, we haven’t. Remember that BDD isa design practice, not a testing practice. We’re using executable exam-ples of how we want the application to behave."112. "We were able to refactor with confidence because we ran the specs between each step, so we always knew right away when we introduced a problem. We looked at two structural refactorings in detail: Extract Method and Extract Class. We also talked about a few specific code smells: Temporary Variable, Long Method, and Large Class."121. "You Can Always Roll BackThings don’t always work out quite this cleanly. Sometimes we’ll try toexperiment like this and run into failure after failure after failure.When that happens to you, and it will, don’t let it go on too long before rolling back to the last point at which all examples were passing. Then you can proceed forward again in smaller steps."125. "How Traditional Projects FailTraditional projects fail for all sorts of reasons. A good way to identify the different failure modes is to ask your project manager what keeps them up at night. (It’s nice to do this from time to time anyway—it helps their self-esteem.) It is likely your project manager will come up with a list of fears similar to ours."127. "Now, because we are responsible adults, we have a Testing phase where we test the software to make sure it does what it was supposed to do. This phase contains activities with names like user acceptance testing or performance testing to emphasize that we are getting closer to the users now and the final delivery."131. "The Agile ManifestoWe are uncovering better ways of developing software by doing it andhelping others do it. Through this work we have come to value:*Individuals and interactions* over processes and tools*Working software* over comprehensive documentation*Customer collaboration* over contract negotiation*Responding to change* over following a planThat is, while there is value in the things on the right, we value the things on the left more."136. "Getting software into formally controlled environments puts us at odds with the corporate governance structures. But if we can’t get into production frequently, there is arguably little value in all the other stuff. It may still be useful for the team’s benefit, but software doesn’t start making money until it’s in production. Remember, we want to be writing software that matters!"139: "Three principles of BDD:> Enough is enough: Up-front planning, analysis, and design all havea diminishing return. We shouldn’t do less than we need to getstarted, but any more than that is wasted effort. This also appliesto process automation. Have an automated build and deployment,but avoid trying to automate everything.> Deliver stakeholder value: If you are doing something that isn’t either delivering value or increasing your ability to deliver value, stop doing it, and do something else instead.> It’s all behavior: Whether at the code level, the application level, or beyond, we can use the same thinking and the same linguistic constructs to describe behavior at any level of granularity."144. "Many people use the words feature and story interchangeably,but there is a subtle difference. A feature is something thatdelivers cohesive value to a stakeholder. A story is a piece ofdemonstrable functionality that shouldn’t take more than a fewdays to implement. So, the feature is more useful from the pointof view of the stakeholder, and the story is more useful from thepoint of view of the team delivering the feature."146. "A story consists of a number of components:> A title: so we know which story are we talking about.> A narrative: that tells us what the story is about.> Acceptance criteria: so we know when we are done.Regarding narrative: the most common format for this is known as the Connextra format, after the company where it was first used: as a [stakeholder], I want {feature] so that [benefit]."147. "We use the slightly artificial structure of givens, events, and outcomes to describe these scenarios. This doesn’t mean that every scenario has exactly one Given, When, and Then in that order. Rather, it means that each step is either setting something up in a known state (a given) or exercising some behavior (an event) or verifying something happened (an outcome). Trying to do more than one of these in a single step usually ends up in confusion." Overall I liked this book. However if you have worked with rspec before you're going to end up skimming a lot of this book as the basics are thoroughly covered. Also if you don't have a strong background in TDD then I think some of the book's message is lost on you. All-in-all then there's a niche here that limits the appeal of this book. On top of that the material will age quickly (the cucumber stuff already has) and I suspect in a year or two's time the book's content will have some significant gaps or shortcomings. Partly due to the nature of the project and partly because you can smell the bleeding edge of design here.The prose has the characteristic PragProg hallmarks (the editors are really good at PragProg I think) in that it is simple, direct and pleasant to read. there's no feeling of being talked down to or suffering through the written equivalent of muzak. the authors build through the concepts with some neat examples and give a good feel for the cycle of development that they're expounding. There were tips and tricks I learnt as I followed along and the repetition helped cement the learning.In conclusion, buy it now, read it now or leave it forever is my advice.
What do You think about The RSpec Book (2010)?
Must read if you want test your Ruby developments.It initiate me to TDD/BDD.
—Ayen
Good intro to BDD. Includes a lot of useful cucumber stuff.
—Twilight_kitty87
