Errata for The RSpec Book

#46030: # Quick Thoughts on "The RSpec Book"

My rating: 10/10.
Heavens gift book! Really.

That said, I have a few thoughts...

## On brute-forcing
I somehow felt sad because "disciplined approach" detailed part from previous
versions was omitted/under-emphasized. It was a great value for me to read it,
and definitely helped my career a lot, per se, "you're not silly, you're on
the right path".

## On testing
Test everything that could possibly break. A lot of debate here.
Not even a mention in the book. I know it's hard to talk on this, but it's
worth at least mentioning it.

## On workflow
I'm unaware of the constraints, but I would like to see a section of BDD DVCS
workflow and deployment. I'm not sure if they're on scope, but feature branches,
staging servers, deployment from day one, and a few other topics are often
under-valued or unpracticed on communities, I'm a strong believer that
stuff works better that way, and I was wondering if there are any plans about
it. Agile++.

## On autotesting
Also, although the some implementations are a little bit buggy at this time, I
would also suggest to focus on automated testing on your development machine,
projects such as autotest-[notification], spork and possibly guard, and the
rspec/cucumber support are worth mentioning.
I'd also like to see to some point CI scenarios.

## On mocks
On test doubles, I have almost nothing to say. Great coverage.
What's not clear to me by reading it, it's the role of mock objects on high
level testing, I mean the cucumber part.
I haven't faced this situation, but I do have the doubt.
I mean, a feature is supposed to be integrated, it's supposed to test your
entire stack, but might also be supposed to be contained, isn't?
My doubt here is probably just an indicator of bad design, but what happens
when you feel the need for a mock object on your features? Their role on
rspec is well understood, as a matter of fact, I'm confident with them since
I've got another layer of testing that allows me to see how are the parts
working, that's why it seems a big no-no to me to use of them on cucumber, but
again, what do you when you feel the need?

## On milestones
An excelent part that one about release planning and milestones: This gets in,
that gets out. A little more emphasis could be added into this customer-driven
iteration negotiation, and even if they're other sources that deal with the
topic I would like to see more about reacting to change, new features breaking
schedule, etc. Absolutely awesome the part of one-week iterations, I have to
say I was shocked, I've been ranging on 2-4 weeks iterations, definitely I must
try that in the near future.

## On Cucumber
I've experienced in the past, begginners at BDD have problems with Cucumber,
because they tend to be much specific and they abstract away from the business
requirements on writing the scenarios, they get to deep into implementation,
and they even have problems with Regexps because of that. Although that
though can be extracted from the book, I've felt somehow it lacks a little more
emphasis on this part.

## On Rails BDD
For the rails part, I must only say I was one of the ones that were expecting a real project in the "Agile Web Development with Rails 4" way.
Totally omitted capybara, I assume there's a very good reason on doing that.
What about database_cleaner? Wasn't database_cleaner on the Gemfile sufficient?
On view testing, three state models, only one mentioned: there are factories,
fixtures and mocks. Each with it's own advantages and disavantages,
but certainly each of them are widely used.

Suggest something like "def and; self; end" to rspec authors, allowing:
mock_model("Message").as_new_record.and.as_null_object
# instead of
# mock_model("Message").as_new_record.as_null_object

I don't like script/rails at all, who does that?
rails g controller messages
instead of:
script/rails generate controller Messages

Also, seems like --no-helper is no longer valid.
A rails bug maybe? It displays '--helper', and even that isn't allowed.

Migrations: I feel something missing here.
Shouldn't be possible to explain at least something like nulldb or similar,
can't remember exactly, adding to migrations continously while a model evolves, or generating a model from a set of expectations on what we might need?
Shouldn't we favoring field_id:references instead of a simple field_id:integer?

The shoulda people will feel a little offended, not a single
mention to their matchers ;)

"is valid with valid attributes" <- pointless? This is not behavior.
What makes valid attributes?

On associations, agree you shouldn't spec them directly.

## On Progressive Enhancement (or the lack of)
Based on experience, and in this book's scope, I was sad that progressive
enhancement wasn't mentioned at all in the book.
We aren't all the time building RIAs in the strict sense,
so this model of FE developing actually helps you on testing your app.
It brings a lot of benefits, but from a testing standpoint
(or a lazy standpoint maybe), it allows you to focus on testing your app
entirely without javascript at first, and then adding those automated browser
scenarios only on those enhancements.
Ex. if you've got a file upload field which gets replaced by a drop area on a
drag-drop UX, you just abstract away from that initially, make sure the form is working, the views are rendered and the file is uploaded, then your
selenium tests complements that.
Narrowed down concept, simple enough, but missing from the book.

## Colophon
Finally, I wouldn't expect you to take my suggestions to the line, you're far
better than that, but since this has become (or I expect it to become) the
point of authority for BDD, I believe some of those points will fill the gaps
in such an important book.

Nevertheless, a terrific work, a must-have book, and an amazing source of
knowledge.
Didn't change the way I program, I've been on this for a while now,
but it certainly enhanced the way I do it, I feel a better developer already.
Keep going, since you guys are my model of inspiration.

Thanks ** NaN ;)

On Cucumber part, there are still examples which use b/w instead of +/-.--Adrian Perez

#45749: In section 1.2, end of the second paragraph: the word "is" should be removed from "...but even then, they generally mean is that it's stored somewhere and they can get it back."--Brian Darrell Green

#45897: The phrase "go ahead and <x>" is used too much throughout the book. It would improve the writing to remove that part and just state the "<x>". For example, on page 34, the phrase could be removed from the sentence beginning with "Go ahead and add a step_definitions directory."--Jimmy Cuadra

#45883: So, now we have our release plan with 3 stories. It’s time to start breaking it down into iterations.

Yet only 2 stories are worked out and page 52 reads: We picked out two stories that will result in working software sufficient to interact with it in a meaningful way.

Poor third story…--Thomas Maas

#45887: Throughout the PDF, output is colored as though it were code. On page 67, in "prompts for the first guess" the "for" is highlighted as a keyword; in "Codebreaker::Game#start", the # is treated as the start of a comment. This could be overlooked were it not for the explicit instruction to "use the --color flag".--Thom Raybold

#46098: The path cb/325/... threw me for a minute, after seeing a steady progression of 27,28,30,32. I guess you meant 32.5. In the next edition, I would make sure the numbers always progress in sequence.--Dale Visser

#46559: Recommend Enumerable#count, not enumerable#inject. The #count method does exactly what's required here. Using #inject makes the code harder to read to save a temporary variable. Using #count still gets rid of the temporary variable, and improves readability to boot.--Sheldon Hearn

#45787: "Create a marker.rb file in lib/codebreaker/, open the Codebreaker module, and copy the Marker into that file." This is unclear to me. I think it means simply "Create a marker.rb file in lib/codebreaker and move the Marker class into that file." With no module around it? That works, but I'm not sure it's just what was meant. It's a Ruby-newbie issue but it might be worth trying to clarify a bit.--Mike Blyth

#46580: In Ruby 1.9.2 there isn't a String#map method any more. but in this example you could use String#each_char instead. Perhaps you could mention it in a future print run--Jens Fahnenbruck

#46338: Your code snippet formatter has decided that the text following => is ruby code and highlighted "require" and "and" inappropriately in the second line:

describe User, "should require password length between 5 and 40" { ... }
=> User should require password length between 5 and 40
--Jonathon Abbott

#45799: "All of the other patterns we’ll talk about and you’ll read about elsewhere are usually variations of method stubs and method expectations..."

Does this means that *every* other pattern is *usually* (but not always) a variation, or the *nearly every* (but not all) patterns are variations? There is a difference in meaning.--Mike Blyth

#45770: "The first example specifies that the WidgetsController finds the widget, so we set an expectation that the Widget class should receive the find() method." This should be "find() message" rather than "find() method" because messages are received, not methods.--John Topley

#46054: The autotest command appears to be part of the ZenTest gem, which is not listed on page 18. While autotest appears to have been its own gem for a while, it was also not listed on page 18. Please consider adding the appropriate gem to page 18 or mentioning where to find it on page 230.--Daniel Hedlund

#45801: RSpec::Core::RakeTask.new do |t|
t.rspec_opts = ["--color"]
end

spec_opts takes an array of strings,...

Should "spec_opts" be "rspec_opts"?--Mike Blyth

#45806: Under the Exclusion heading, "...we tend to try to disable them so we can run rest of the suite..." should be "we tend to try to disable them so we can run the [sic] rest of the suite..."--John Topley

#45809: "We’re going to focus on Cucumber with Webrat and Selenium, so we’re going to skip over some of the low-level details that we use RSpec for in practice."

Awkward sentence with "for in practice." Consider rewording at least to "that in practice we use RSpec for," if not the more formal "for which in practice we use RSpec."--Mike Blyth

#45907: The messages example in the rails_view chapter works with rails 3.0.0 but does not work when running on rails 3.0.3. The refactoring of new.html.erb_spec.rb on pdf page 338 results in a an unintended failure:

Failures:
1) messages/new.html.erb renders a text field for the message title
Failure/Error: form.should have_selector("input", type: "text", name: "message[title]", value: "the title")
expected following output to contain a <input type='text' name='message[title]' value='the title'/> tag:
<form accept-charset="UTF-8" action="/messages" class="new_message" id="new_message" method="post">
<div style="margin:0;padding:0;display:inline"><input name="utf8" type="hidden" value="&#10003;"></div>
<input id="message_title" name="message[title]" size="30" type="text" value="Message_#&lt;RSpec::Core::ExampleGroup::Nested_1:0x00000102adcd18&gt;"><input id="message_submit" name="commit" type="submit" value="Save">
</form>
--Jeff Hutchison

#46310: "Use Webrat’s have_xpath( ) and have_selector( ) matchers for view specs." I believe this is misplaced and should be moved to the summary of Chapter 21, where they are actually talked about and used.--Ted Milker

#45807: The database migration on this page specifies "recipient_id":

"script/rails generate model message title:string text:text recipient_id:integer"

On PDF page 371 and 372, the reference is to "recipient" (no "_id"). Admittedly I'm a beginner in Ruby but for me this example fails.

For context, I'm running Rails 3.0.3 and Ruby 1.9.2p0.--Sully Syed