Good Stuff from The RSpec Book

David Chelimsky’s The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends (The Facets of Ruby Series) covers one of my favorite areas of Rails development. I thought I’d share some highlights for you if you haven’t read the book (and as a quick reference for me.)  Since I read the book on Kindle I’ll be providing the Location rather than page numbers.

2138 This is the BDD cycle. Driving development from the outside in, starting with business-facing scenarios in Cucumber and working our way inward to the underlying objects with RSpec.

4374 Behaviour-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.

Using the SMART approach in software delivery. Each area is defined on 4431 The acronym SMART is used to describe outcomes or objectives that have certain characteristics, namely, that they are Specific, Measurable, Achievable, Relevant, and Timeboxed.

I like the idea of wrapping a class in a test module for report clarity. 4633. If User is in the Authentication module, we could do something like this:

module Authentication   describe User, “with no roles assigned” do

The resulting report would look like this:

Authentication::User with no roles assigned

On using “context.” 4652. The output would be the same as when we used describe on the second line, but context can make it easier to scan a spec file and understand what relates to what.

4777. Example on using “pending” to stop execution.

4794. Wrapping test code in a Pending block. Block is executed and raises a PendingExampleFixedError if passes.

5063. Including shared modules in RSpec Configuration.

5629. array.empty?should == true expresses our intention, but array.should be_empty is better.

5634. RSpec overrides method_missing to provide this nice little bit of syntactic sugar. If the missing method begins with “be_,” RSpec strips off the “be_” and appends “?”; then it sends the resulting message to the given object. Ex: user.should be_in_role(“admin”) / user.in_role?(“admin”)

6271. For literal values, we can just pass them directly to the with method: account_double.should_receive(:withdraw).with(50)

6750. RSpec ships with adapters for Mocha, Flexmock, and RR mocking frameworks.  Add in RSpec Configuration config.mock_with <framework_id>

6984. Adding RSpec options like –color and –format documentation in ~/.rspec.

7048. RCov – code coverage tool, observing what code in your application that was never executed when you ran your specs with a percentage of code base covered by specs.

7304. Creating custom matchers. Ex: joe.should report_to(beatrice)

7569. RSpec formatting options.

7629. A common understanding of done is crucial to the success of any project. How do we know when we’re done if we can’t agree on what done means? Such agreement is pretty easy to find in many kinds of projects. A cake is done when it reaches the right consistency. A building is done when the city inspector says it meets code. If we apply the right tests and they pass, we’ll know when we’re done. But with software, there’s a catch.

…Cucumber supports collaboration and communication between stakeholders and the delivery team. It uses a simple language for describing scenarios that can be written and read with ease by both technical and nontechnical people. These scenarios represent customer acceptance tests and are used to automate the system we’re developing.

9453. Using save_and_open_page to capture scenario response at any point and open it as a static HTML file in the browser.

11445. In his article “Skinny Controller, Fat Model,”[63] Jamis Buck recommends pushing business logic down to the model, keeping views and controller actions lean. This guideline helps us to follow the Single Responsibility Principle by keeping controllers and views focused on application logic and keeping the models focused on business logic.