What do you think?
Rate this book
by David Chelimsky,by Dave Astels,by Bryan Helmkamp,by Dan North,by Zach Dennis ,by Aslak Hellesoy The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends (The Facets of Ruby Series)(text only)1st (First) edition[Paperback]2010
Behaviour Driven Development is about writing software that matters. It is an approach to agile software development that takes cues from Test Driven Development, Domain Driven Design, and Acceptance Test Driven Planning. RSpec and Cucumber are the leading Behaviour Driven Development tools in Ruby. RSpec supports Test Driven Development in Ruby through the BDD lens, keeping your focus on design and documentation while also supporting thorough testing and quick fault isolation. Cucumber, RSpec's steadfast companion, supports Acceptance Test Driven Planning with business-facing, executable requirements documentation that helps to ensure that you are writing relevant software targeted at real business needs. The RSpec Book will introduce you to RSpec, Cucumber, and a number of other tools that make up the Ruby BDD family. Replete with tutorials and practical examples, the RSpec Book will help you get your BDD on, taking you from executable requirements to working software that is clean, well tested, well documented, flexible and highly maintainable.
Paperback
First published May 15, 2009
52 people are currently reading
506 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 55 reviews
November 25, 2015
An ok introduction to RSpec that focuses more on the framework and less on the "why test in this way or the other".
If you go through the documentation you'll gain the same value as reading the book.
However the book includes a bit more terminology and information about BDD, good stories, features and in general information gathering regarding test scenarios.
It's not an obsolete book if you know what you're looking for.
But nowadays check out https://github.com/eliotsykes/rspec-r... before making the decision to buy it.
If you go through the documentation you'll gain the same value as reading the book.
However the book includes a bit more terminology and information about BDD, good stories, features and in general information gathering regarding test scenarios.
It's not an obsolete book if you know what you're looking for.
But nowadays check out https://github.com/eliotsykes/rspec-r... before making the decision to buy it.
April 23, 2012
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.
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.
February 28, 2011
Ta książka nie jest o RSpecu, ani o Cucumberze. Ta książka nie jest o Ruby'm. Ta książka nie jest nawet o BDD. To wszystko tylko narzędzia.
Na przykładzie Cucmbera, Rspeca i Ruby'ego oczywiście autorzy przedstawiają zawiłości testowania wg filozofii BDD. Jedne rozdziały są lepsze, inne gorsze (wyraźnie widać pióra różnych autorów), niektóre wydają się niekompletne - całość jest jednak solidnym wprowadzeniem do tematu.
By soft powstawał lepszy, a nam żyło się dostatniej.
No, the meme is more than any one of those things. The meme is a
synergistic witches brew of some of the most contagious and effective
ideas of the past two decades. The meme is. . .
Dare I say it?
The meme is. . .
. . . Craftsmanship.
Na przykładzie Cucmbera, Rspeca i Ruby'ego oczywiście autorzy przedstawiają zawiłości testowania wg filozofii BDD. Jedne rozdziały są lepsze, inne gorsze (wyraźnie widać pióra różnych autorów), niektóre wydają się niekompletne - całość jest jednak solidnym wprowadzeniem do tematu.
By soft powstawał lepszy, a nam żyło się dostatniej.
May 15, 2017
It's a good book, although currently quite dated.
All examples use the should-notation, while current best-practices use the expect-notation.
All examples use the should-notation, while current best-practices use the expect-notation.
September 27, 2018
Solid introduction to the subjects of writing Test/Behavior driven code. Like any programming book that’s more than a week old, it’s a bit dated (ie: RSpec now use expect instead of should methods). But overall, as someone new to the subject, I got a lot out of it.
The big lesson I came away with as a developer (and somewhat related to life in general): Red, green, refactor. I love the concept of “call the method you wish you had”, watch it fail (red) because that method doesn’t exist, then write the method just to get it to work and don’t worry about writing Good code - be a duct tape developer (green), and then make the code elegant under the protection of tests that make sure you don’t break anything (refactor).
I love this idea of giving yourself permission to write “bad” code in the short term. Part of what makes coding hard is feeling like there’s a better way to do it. Of course there is! And this system allows you to find that way using the “net” of tests.
The big lesson I came away with as a developer (and somewhat related to life in general): Red, green, refactor. I love the concept of “call the method you wish you had”, watch it fail (red) because that method doesn’t exist, then write the method just to get it to work and don’t worry about writing Good code - be a duct tape developer (green), and then make the code elegant under the protection of tests that make sure you don’t break anything (refactor).
I love this idea of giving yourself permission to write “bad” code in the short term. Part of what makes coding hard is feeling like there’s a better way to do it. Of course there is! And this system allows you to find that way using the “net” of tests.
started-but-will-not-finish
August 6, 2016BDD = Behaviour Driven Development
"Acceptance Test–Driven Planning is one of three practices of BDD. It
is an extension of Acceptance Test–Driven Development.
The difference between ATDP and ATDD is simple. ATDD specifies that
we write acceptance tests before we write code, but it doesn’t specify
when 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 is
a 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 Back
Things don’t always work out quite this cleanly. Sometimes we’ll try to
experiment 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 Fail
Traditional 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 Manifesto
We are uncovering better ways of developing software by doing it and
helping 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 plan
That 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 have
a diminishing return. We shouldn’t do less than we need to get
started, but any more than that is wasted effort. This also applies
to 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 that
delivers cohesive value to a stakeholder. A story is a piece of
demonstrable functionality that shouldn’t take more than a few
days to implement. So, the feature is more useful from the point
of view of the stakeholder, and the story is more useful from the
point 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."
"Acceptance Test–Driven Planning is one of three practices of BDD. It
is an extension of Acceptance Test–Driven Development.
The difference between ATDP and ATDD is simple. ATDD specifies that
we write acceptance tests before we write code, but it doesn’t specify
when 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 is
a 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 Back
Things don’t always work out quite this cleanly. Sometimes we’ll try to
experiment 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 Fail
Traditional 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 Manifesto
We are uncovering better ways of developing software by doing it and
helping 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 plan
That 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 have
a diminishing return. We shouldn’t do less than we need to get
started, but any more than that is wasted effort. This also applies
to 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 that
delivers cohesive value to a stakeholder. A story is a piece of
demonstrable functionality that shouldn’t take more than a few
days to implement. So, the feature is more useful from the point
of view of the stakeholder, and the story is more useful from the
point 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."
January 21, 2024
I'm waiting for the day this book will finally come out of Beta. As of the 15th of November, the release date is pushed back again. But the Beta versions cover a lot of ground. One thing I miss seeing here is a chapter on how to write a good feature scenario. Great book, nonetheless.
October 20, 2021
A description of BDD.
June 16, 2024
还在看，但是我忍不住来打分了。
January 4, 2015
The book is more or less a duplex book. The first part of the book gives a decent introduction to Behavior Driven Development and how Cucumber and RSpec ideally are used in context of BDD as a methodology. The value of this book lies in those chapters.
It's important to understand the context in which tools were born and the ideas behind them. If you leave those bits and pieces out, you'll easily end up with a narrowed view of them, that doesn't seem to add much value. Like DHHs view of Cucumber as a heavy integration testing framework or RSpec as a noisy test/unit replacement.
I can only recommend spending some time with the ideas behind BDD (or Specification By Example for that matter) because I think agile teams greatly benefit from the side effects of those practices. Be it living documentation, a shared understanding, improved communication and collaboration or implicit knowledge transfer. And this book does quite a good job of explaining those ideas in the context of actual code. I also like that they pick up the discussion of what to test and how to test different parts of an application. Surprisingly few development teams have a well defined out testing strategy for their application that plays well with their development process.
The second part is more or less a reference on RSpec, Cucumber and RSpec-Rails. Mostly stuff that is also available online in the documentation of those tools. If you've worked with RSpec or Cucumber before, you won't learn much new in those chapters, but it's a solid reference.
It's important to understand the context in which tools were born and the ideas behind them. If you leave those bits and pieces out, you'll easily end up with a narrowed view of them, that doesn't seem to add much value. Like DHHs view of Cucumber as a heavy integration testing framework or RSpec as a noisy test/unit replacement.
I can only recommend spending some time with the ideas behind BDD (or Specification By Example for that matter) because I think agile teams greatly benefit from the side effects of those practices. Be it living documentation, a shared understanding, improved communication and collaboration or implicit knowledge transfer. And this book does quite a good job of explaining those ideas in the context of actual code. I also like that they pick up the discussion of what to test and how to test different parts of an application. Surprisingly few development teams have a well defined out testing strategy for their application that plays well with their development process.
The second part is more or less a reference on RSpec, Cucumber and RSpec-Rails. Mostly stuff that is also available online in the documentation of those tools. If you've worked with RSpec or Cucumber before, you won't learn much new in those chapters, but it's a solid reference.
March 18, 2012
A fabulous book about RSpec, a testing framework for the Ruby programming language. Actually, this book is about much more than just RSpec--it's also about a bunch of other tools: Cucumber, Webrat, and Selenium. I rolled my eyes when I first saw this, but as I read it I saw that each of these are pieces to a much greater puzzle: Behavior-Driven Development (BDD) in Ruby.
I rolled my eyes at that too, because it just seemed like a fancy name for Test-Driven Development, and it kind of is. The only real difference is semantics, but what a difference semantics make! I really saw how this paradigm and these tools take TDD to a whole new level. As I made my way through this book, traditional testing tools seemed archaic by comparison. RSpec is very sophisticated and expressive. Isn't that what Ruby is all about?
I rolled my eyes at Cucumber too. Cucumber is a mostly free-form text language for writing specs and expectations for an overall system. As just a programming tool, it's unnecessary, but this book helped me appreciate how Cucumber bridges the gap between the developers and the client/boss/producer/etc. Finally, the non-techies can get their hands dirty and spell out exactly what they expect, and it can be programatically confirmed. No more wishy-washy specs and arm waving!
This book made me a BDD convert. Yes, I did a lot of eye-rolling at first. I prefer tools to be as simple as possible, but no simpler. A good case must be made to add fancy features to something that is tried-and-true. This book made a very good case.
I rolled my eyes at that too, because it just seemed like a fancy name for Test-Driven Development, and it kind of is. The only real difference is semantics, but what a difference semantics make! I really saw how this paradigm and these tools take TDD to a whole new level. As I made my way through this book, traditional testing tools seemed archaic by comparison. RSpec is very sophisticated and expressive. Isn't that what Ruby is all about?
I rolled my eyes at Cucumber too. Cucumber is a mostly free-form text language for writing specs and expectations for an overall system. As just a programming tool, it's unnecessary, but this book helped me appreciate how Cucumber bridges the gap between the developers and the client/boss/producer/etc. Finally, the non-techies can get their hands dirty and spell out exactly what they expect, and it can be programatically confirmed. No more wishy-washy specs and arm waving!
This book made me a BDD convert. Yes, I did a lot of eye-rolling at first. I prefer tools to be as simple as possible, but no simpler. A good case must be made to add fancy features to something that is tried-and-true. This book made a very good case.
April 24, 2016
I have mixed opinions on this book. On the one hand, there's a lot of solid theory here on the philosophy and practice of TDD and a lot of solid practical instruction in implementing Rspec in a Rails app. However, the book is so unbearably out of date that trying to follow along with their code is a challenge. The early parts explaining Cucumber and Rspec in Ruby script were pretty straightforward (with a couple of agonizing syntax differences that took hours of research to discover). However, toward the end of the book as they started diving into Rspec in an actual application the syntax and approach differed so wildly from the current version that I had to put the book down and follow tutorials on the internet to vaguely reproduce the results indicated. Of course, the publishers will tell you that you should simply use the same version of Rails and Rspec that the book uses, but what good does it do me to learn how to run tests in a Rails app that old?
Basically, solid theory but all of the specifics need to be updated, and it's a shame that there isn't a more recent book about Rspec.
Basically, solid theory but all of the specifics need to be updated, and it's a shame that there isn't a more recent book about Rspec.
May 3, 2011
I read some parts and skimmed other parts. The discussion around BDD is really interesting and looks to be really useful as part of a continuous delivery pipeline. I skimmed over the Ruby-specific portions -- probably the last half of the book -- only because I'm currently working on a project with Flash front end and a Java back end. I suspect we'll end up using cuke4duke in concert with Cucumber to get our UAT automated. The ability to use the tests as documentation for system functionality looks like it will be very useful. I'd probably would've rated the book higher if I was a Ruby developer because the authors are very good at pointing out the various land mines as well as discussing the pros and cons of different approaches to certain problems.
May 6, 2013
If you want to test your code with Rspec this is THE book you must read. It is a very nice introduction and reference which also covers Cucumber and Rails. However if you are interested in these two cases, you will have to read other books.
You should know something about TDD if you really want to get most of the value out of this book. The mocking part is a nice reference, but will not teach you how/when to use mocks. Even if you are new to TDD/BDD you will experience the benefits.
Just be aware of something very dangerous. Probably in the name of simplicity, the author decided to test the output of the sample programs with Rspec. If you ever do that in a real program something very wrong might be going on. In most cases, you should use Rspec only for unit testing and most tests looking at a program output tend to be acceptance tests, in which case, you should be using Cucumber.
You should know something about TDD if you really want to get most of the value out of this book. The mocking part is a nice reference, but will not teach you how/when to use mocks. Even if you are new to TDD/BDD you will experience the benefits.
Just be aware of something very dangerous. Probably in the name of simplicity, the author decided to test the output of the sample programs with Rspec. If you ever do that in a real program something very wrong might be going on. In most cases, you should use Rspec only for unit testing and most tests looking at a program output tend to be acceptance tests, in which case, you should be using Cucumber.
October 25, 2015
The RSpec book is more of an introduction to BDD as a concept, and especially focusses on how it works in Rails (the last two chapters) but can be applied to everything.
I felt like maybe it was too beginners'-guide-ish and too prescriptive in places but in general I learnt a lot about BDD and how Cucumber & RSpec work as tools to achieve it.
But the biggest criticism I have of this book is that it hasn't been kept up to date. RSpec 3 recommends a very different syntax and introduces many concepts the book says "they'd like to add in the future", so it feels like it needs a big overhaul for RSpec 3 or even RSpec 4.
I felt like maybe it was too beginners'-guide-ish and too prescriptive in places but in general I learnt a lot about BDD and how Cucumber & RSpec work as tools to achieve it.
But the biggest criticism I have of this book is that it hasn't been kept up to date. RSpec 3 recommends a very different syntax and introduces many concepts the book says "they'd like to add in the future", so it feels like it needs a big overhaul for RSpec 3 or even RSpec 4.
December 12, 2012
Preferring the expressiveness of BDD and RSpec to xUnit, I use it on projects whenever I got a chance. I grabbed this book to add Cucumber to my toolset so that I could exercise the full stack of a Rails application. What I got in the end was an enhanced understanding of how Cucumber, RSpec, and Rails play well together but more importantly was a focus on craftsmanship and how to write code patiently and precisely: coding just enough to solve the problem and refactoring fearlessly.
Want to read
September 27, 2011Got a signed copy from my good friend Dave Astels. I got exposed to RSpec back on 2008-11-07 and I have been waiting for this book ever since. I wish there was an RSpec for Java or Groovy. I heard that JBehave is supposed to be similar, but the syntax is not the same. RSpec reads just like English, with spaces and all!
November 21, 2011
The title of this book is unfortunate. This isn't really a book about RSpec (or Cucumber or Ruby) any more than 1984 is about Oceania (or Winston Smith). Rather, "The RSpec Book" is a treatise on a software development philosophy, and its vehicle happens to be RSpec.
I'm a lifelong student of software development, and this book fundamentally changed the way I think about - and practice - my craft.
I'm a lifelong student of software development, and this book fundamentally changed the way I think about - and practice - my craft.
October 22, 2014
This is a good reference, but it is even better at putting ruby, test driven development, behavior driven development, cucumber and Rspec together in one holistic package. I have found the process of TDD to be the most compelling part of learning TDD, and this book enables that with an easy introduction to the toolset. Honestly, at this point in my experience in software development, tool choice is such a small part of getting things done, that this book is perfect.
December 28, 2015
Disappointed by how it begins selling both RSpec and Cucumber and continues to interlace the two....RSpec is enough for me to learn right now...
The last update of this book was 2012-09-13 (P2.1). Unfortunately, I had difficulty getting the versions described in the book working, then when I used the most recent version of rspec I learned that the earliest examples in the book use deprecated syntax of "should".
I'll see if I can find a recent book solely focused on rspec.
The last update of this book was 2012-09-13 (P2.1). Unfortunately, I had difficulty getting the versions described in the book working, then when I used the most recent version of rspec I learned that the earliest examples in the book use deprecated syntax of "should".
I'll see if I can find a recent book solely focused on rspec.
Want to read
October 29, 2010I've had a long fascination with traceability between requirements and code, and RSpec (and it's .NET cousin SpecFlow) provide one way of doing that.
I've tried RSpec and SpecFlow on small things, and a large upcoming project is a good candidate for using it in a big way.... so going to read up a bit before trying that.
I've tried RSpec and SpecFlow on small things, and a large upcoming project is a good candidate for using it in a big way.... so going to read up a bit before trying that.
April 18, 2012
I liked the book and everyone is probably better off for reading it but I found it a little chaotic in focus. One minute we're deep in Ruby implementation details, the next we're having philosophical discussions about the history of agile software development.
I do like all the little books inside the book, so maybe I shouldn't be complaining.
I do like all the little books inside the book, so maybe I shouldn't be complaining.
February 8, 2013
I've been using Cucumber and RSpec for a while now without having read this book. Needless to say I understand the culture around RSpec a lot better now, and how some of the magic works (like have_key?).
The book is an easy read, with a good chapter in the middle about why software projects fail.
If you are using RSpec on a project then I'd recommend this highly.
The book is an easy read, with a good chapter in the middle about why software projects fail.
If you are using RSpec on a project then I'd recommend this highly.
February 6, 2015
This book introduced me to Tests and Behavior Driven Development. It gives great work-along problems to solve throughout the book so you can apply the skills directly. It would be 5-stars, but it's started to become dated in some of the code libraries like RSpec Expectations and Webrat. Overall, I'll recommend it to anyone wanting to learn BDD/TDD.
October 24, 2016
A good overview of the RSpec library, albeit a bit dated. RSpec's DSL has since changed since the book's publishing so at first it might be a bit confusing. But just look up the current RSpec docs online to see what's changed. I did wish that the book would have explained a bit more to why they chose to go with certain implementation methods.
February 3, 2011
I first attempted to learn about BDD using Internet resource, but found them all to assume I was familiar with things that I wasn't or to only address a small subset of information that I was looking for. This book did a good job of filling in the gaps and getting me started down the right path.
February 22, 2011
Enjoyed reading the sections on Cucumber & RSpec. Suitable for developers of any language as the foreword mentions. Some sections haven't kept pace with the fast moving work of Ruby, e.g. examples in Webrat instead of Capybara.
January 5, 2014
I really liked the discussion about BDD which help me to understand some concepts. I also liked the part where discussed about cucumber and the different scenarios style. What I didn't like so much was the latest chapters where it mixed up domain specific logic of the application with rails.
Currently reading
June 25, 2009test
October 1, 2009
This book is still in beta, so it has some missing chapters. It's a good tutorial and introduction to Cucmber and Behavior Driven Development (testing) of Ruby on Rails web applications.
Displaying 1 - 30 of 55 reviews