Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

@dimroc => long overdue, some quacking improvements #42

Merged
merged 3 commits into from

2 participants

@dblock

Based on your last comments, it's basically a bit of cleanup in the RSpec topic.

@dimroc

The quack invocation here would not be on the duck instance but would instead reside in the test's scope

duck.should respond_to :quack
@dimroc

I could be erring on the side of pedantic, but if quack returns nil or false, this test would be a false positive. There are other corner cases too.

Should we propose the following:

# Unit Test
assert Duck.new.responds_to?(:quack)

# RSpec
Duck.new.should.respond_to :quack
@dimroc

Left some comments inline on a few of the assertions. The main issue is that "quack" isn't an RSpec matcher nor would it be one even in the analogy. I've inserted respond_to as a potential matcher.

So if I add an actual RSpec matcher like should_quack the code would make sense?

When asserting against a value, I believe you can only use should or should_not to prepare the invocation of an rspec matcher. should in of itself is not the RSpec matcher. After should is when you would place your matcher, such as be_nil, have_content or validates_presence_of. If you have your own RSpec matcher, it would probably be called has_quack and would test for the presence of the quack method on the object.

This would be identical to

duck.should respond_to(:quack)

You wouldn't want to call your matcher should_quack because then you'd have to type:

duck.should should_quack

https://www.relishapp.com/rspec/rspec-expectations/v/2-0/docs/matchers/respond-to-matcher

@dimroc

space after should instead of period.

duck.should respond_to :quack
@dblock

Ouch, fixed.

@dblock dblock merged commit a34dc7c into generalassembly:master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 9, 2012
  1. @dblock

    Fixed duck quacking.

    dblock authored
Commits on Jul 2, 2012
  1. @dblock

    Clarified quacking.

    dblock authored
Commits on Jul 3, 2012
  1. @dblock

    Ouch.

    dblock authored
This page is out of date. Refresh to see the latest.
Showing with 10 additions and 23 deletions.
  1. +10 −23 lectures/05-rspec/5.1-rspec-refactor.md
View
33 lectures/05-rspec/5.1-rspec-refactor.md
@@ -18,7 +18,7 @@ Test First?
Test and Behavior Driven Development
------------------------------------
-TDD is not about testing, it's about *design*. The process is often called *Red => Green => Refactor*.
+TDD is not about testing, it's about *design*. The process is often called *Red => Green => Refactor*.
1. Write failing tests.
2. Implement the feature, making tests pass.
@@ -35,37 +35,24 @@ Behavior-driven testing is an effective way of testing that helps developers und
RSpec
-----
-[RSpec](http://relishapp.com/rspec) is a Behavior-Driven Development tool for Ruby programmers.
+[RSpec](http://relishapp.com/rspec) is a Behavior-Driven Development tool for Ruby programmers.
+Compare a unit test with an RSpec example.
``` ruby
# Unit Test
-class DuckTest
+class DuckTest < ActiveSupport::TestCase
test "quack" do
- assert_true Duck.new.quack
+ assert Duck.new.responds_to?(:quack)
end
end
+```
+```
# RSpec Scenario
describe Duck
let(:duck) { Duck.new }
it "should quack" do
- duck.quack.should be_true
- end
-end
-```
-
-If quacking were common, we could even write `duck.should_quack`.
-
-``` ruby
-describe Duck
- let(:duck) { Duck.new }
- context "in the water" do
- before(:each) do
- duck.swim
- end
- it "should quack" do
- duck.quack.should be_true
- end
+ duck.should respond_to :quack
end
end
```
@@ -287,7 +274,7 @@ Another way of specifying `:driver => :selenium` is `:js => true`.
Refactor in Confidence
----------------------
-Controllers support filters that avoid copy-pasting. This is called *DRYing* a controller. *DRY* stands for *Don't Repeat Yourself*. Now that we have specs that cover the application, we can refactor in confidence.
+Controllers support filters that avoid copy-pasting. This is called *DRYing* a controller. *DRY* stands for *Don't Repeat Yourself*. Now that we have specs that cover the application, we can refactor in confidence.
``` ruby
class ThingsController < ApplicationController
@@ -313,7 +300,7 @@ Extend the application with authentication by using the [devise gem](https://git
RSpec Output
------------
-Create *.rspec*
+Create *.rspec*
--format nested
--color
Something went wrong with that request. Please try again.