David Chelimsky

The RSpec Book Beta 6.0 was just released. This release includes a number of fixed errata, two new chapters, and a bit of re-organization.

Hello

We added a new chapter with basic install instructions and basic Hello Cucumber and Hello RSpec examples.

Rails Models

Covers writing model specs, validations, associations, mocks, test data builders and more.

Automating Features with Cucumber

We split Describing Features with Cucumber into two chapters: Describing Features with Cucumber and Automating Features with Cucumber. This allowed us to expand the material on planning the first release and iteration in the first chapter, and keep of the technical in the trenches material in the second.

Even if you’ve already read through the tutorial in previous beta releases, you’re going to want to re-read these two chapters.

If you use Autotest with Ruby on Rails, be sure to gem install autotest-rails when you upgrade to ZenTest-4.1.0.

Without that gem, when you run the autospec command that ships with RSpec, Autotest won’t won’t have any way of knowing it’s in a Rails app and it will load up rspec’s autotest/rspec.rb instead of rspec-rails‘ autotest/rails_rspec.rb.

Even if you’re not using RSpec, you’ll get ZenTest’s autotest/autotest.rb instead of autotest/rails.rb when you run the autotest command.

The next release of rspec-rails will include a patch to resolve this for RSpec users, but in the mean time (and for everybody else), just gem install autotest-rails and resume your regularly scheduled continuous testing.

This release introduces two new chapters:

Writing Software that Matters

Having laid out the case for Behaviour Driven Development in The Case for BDD, this new chapter explores the principles and strategies that BDD brings to the Agile table.

Mock Objects

One of the most complex and controversial topics in developer testing is that of Mock Objects. In this new chapter, Mock Objects, we review some basic terminology and explore the underlying motivations for two essential tools in the BDD toolkit: test stubs and mock objects.

We’ve released version 4.0 of The RSpec Book beta. It’s got a number of improvements per suggestions submitted by readers, as well as two exciting new chapters.

New Chapter: Rails Controllers

Continuing inward on our outside-in journey, this chapter explores how (and when) to write controller specs. We also introduce approaches to dealing with some controller-specific spec’ing challenges like filters, global behaviour defined in application controller and sending email.

New Chapter: Extending RSpec

This chapter introduces techniques for extending RSpec to cater to domain-specific needs. Covered topics include custom example group classes, custom matchers (including an exciting new matcher definition DSL), macros and custom formatters. Whether customizing RSpec for your own app, or in order to ship domain-specific spec’ing extensions with the libraries you’re releasing, this chapter is filled with really useful information that will help you make your specs easier to write and read.

Thanks (again, and again, and again)

Many thanks to all of you who are already participating in The RSpec Book beta program and making so many great suggestions. Your ongoing contribution to this process remains invaluable for the book and all of its readers.

We’ve released version 3.0 of The RSpec Book beta. It’s got a number of improvements per suggestions submitted by readers, as well as two new chapters.

New Chapter: Evolving Existing Features

This is the next chapter in the Mastermind tutorial, in which we take the reader through the process of developing a command line version of the classic Mastermind game. In this chapter, we explore the problem of driving out changes to existing behaviour with new scenarios and code examples, all the while keeping the old code examples passing.

New Chapter: The Case for BDD

As the title suggests, this chapter lays out the case for Behaviour Driven Development as an over-arching methodology. You’ll read about how and why so many traditional projects fail, the Agile Manifesto and the methodologies that emerged around it, and why so many teams continue to struggle in spite of best efforts to adopt these new methodologies.

Thanks

Many thanks to all of you who are already participating in The RSpec Book beta program and making so many great suggestions. Your contribution to this process is invaluable for the book and all of its readers.

rspec-1.2.0 and rspec-rails-1.2.0 have been released!

You’ll need this upgrade if you’re upgrading to rails-2.3.

Be sure to read the change logs before upgrading. There have been a few changes that will impact some (not all) of you.

rspec-1.2.0: RDoc | History
rspec-rails-1.2.0: RDoc | History

Better late than never:

[david: rspec (master)]$ multiruby -S rake spec
...
Passed: v1_8_6_114, 1.8.7-p72, 1.9.1-p0


[david: example_rails_app (master)] $ multiruby -S rake rspec:pre_commit
...
Passed: v1_8_6_114, 1.8.7-p72, 1.9.1-p0

Coming soon to a gem release near you.

The Pragmatic Programmers have just released the The RSpec Book, Beta 2.0. If you’ve already purchased the beta book, you can go to your account page and you’ll be able to download the new update.

If you haven’t purchased the beta book yet, now is a great time to join the party! We just added three new chapters:

Evolving Requirements

This is the next chapter in the Mastermind tutorial, which takes you through the evolution of a command line version of the classic Mastermind board game. The earlier chapters introduce RSpec and Cucumber. This new chapter introduces Cucumber’s new Scenario Outlines feature, which let’s you express repetitive scenarios in FIT-inspired tabular format.

Simulating the Browser with Webrat

Bryan Helmkamp, Webrat’s lead maintainer, builds on the Cucumber/Rails material in earlier chapters, driving those scenarios through the Rails stack with Webrat’s simple, powerful API.

Rails Views

Zach Dennis shows you how to write RSpec code examples for Rails views. Using Webrat’s have_xpath and have_selector matchers, and wrapping them in custom matchers targetted at your app, Zach shows you how to provide value throughout the life of the application with expressive, maintainable view specs.

Chapters from Beta 1.0

These new chapters build on the chapters we already released in Beta 1.0:

• Introduction
• Describing Application Behaviour with Cucumber
• Working from the Outside-In with RSpec
• Code Examples
• Expectations
• RSpec and Test::Unit
• Tools and Integration
• BDD in Rails
• Cucumber with Rails

Up Next

We’ve got many more chapters coming over the next two or three updates, including chapters from Dan North and Dave Astels on Behaviour Driven Development and Mock Objects, new material on integrating Selenium, extending and customizing RSpec, and much, much more.

Thanks to all who are already participating in the beta program. We’ve gotten some great feedback so far. Some of it is already incorporated in the 2.0 beta release, and much more will be addressed in the upcoming releases. You’re all making this a better book for everyone else who will read it, so thank you, thank you, thank you.

Thank you to all who are participating in The RSpec Book beta program. We’ve already gotten some good feedback, and we look forward to more as we release updates over the coming weeks.

For those of you who are reading the beta and would like to provide feedback, there are two outlets for you on the Pragmatic Programmers’ site.

The errata page is for technical errors, typos, etc. Things that don’t really require any discussion and are simple, task oriented fixes.

Although the errata page lists Suggestion as a type of errata, the system provides no opportunity for a conversation. Therefore, if you are making a comment like “I’m not sure I agree with the statement on page 37” or “you say x here and y there, which is it?”, etc, then the forum might be a better option. That way I (or any of the authors) can throw questions back at you to get a better feel for what you’d like to see and how it might help.

Of course, we’d rather have your feedback than not, so if you’re not interested in such a dialog, go ahead and stick to the one-way-street of the errata page.

Again, thanks for the feedback thus far. You’re helping to make this a better book for everyone else who will read it.

So why would you do this? Well, for starters, now you can run this with any of RSpec’s command line options. This prints out the name of each test class and test method:

$ spec addition_test.rb --format specdoc
 
TestAddition
- test_add_1_and_2
 
1 example, 0 failures

Try it with html:

$ spec addition_test_with_rspec.rb --format html:report.html

Wanna should in your tests?

def test_add_1_and_2
  (1 + 2).should == 3
end

Wanna assert in your rspec code examples?

describe "adding in Ruby" do
  it "returns 3 for 2 + 1" do
    assert_equal 3, 1 + 2
  end
end

When you invoke rspec’s test/unit bridge, rspec and test/unit become completely interoperable. This means that most of the extensions and plugins for both libraries are available to you at the same time. I say most because libs that monkey patch their way into internals of either don’t always play nice in this environment.

This also means that transitioning from an existing test/unit suite to an rspec suite is as simple as changing a single require statement and then gradually changing the tests to rspec code examples. You can run them all together during this refactoring, so you don’t have to do this all at once, and you can keep moving on your project with little to no penalty.

So if you’re choosing an alternative framework because you prefer its syntax, more power to you. If you’re choosing it because you understand its internals better, right on! Have at it. But if you’re choosing it only because it plays nice with test/unit and you didn’t know that rspec does as well, well, now you know.