5. •It's 'tests' that 'drive' the 'development'
•Make sure that No code goes into production
without associated tests
•Benefits of TDD:
http://agilepainrelief.com/notesfromatooluser/2
008/10/advantages-of-tdd.html
TDD
7. BDD
•BDD is based on TDD
•BDD is specifying how your application should
work, rather than verifying that it works.
•Behaviour-Driven Development is about
implementing an application by describing its
behavior from the perspective of its
stakeholders. (Rspec book)
11. describe `Class` do
before do
# Setup something
end
it “should return something“ do
# actual_result.should matcher(expected_result)
end
end
HOW
An Example
E
x
a
m
p
l
e
g
r
o
u
p
This is a Spec file
13. Expectation - Matcher
•Basic structure of an rspec expectation
o Old syntax
actual.should matcher(expected)
actual.should_not matcher(expected)
o New
expect(actual).to eq(expected)
expect(actual).not_to eq(expected)
•For example
o 5.should eq(5) / expect(5).to eq(5)
o 5.should_not eq(4) / expect(5).not_to eq(5)
16. Mocking - Stubbing
Rspec-mocks is a test-double framework for
rspec with support for methods
o mock a `fake` object
o stubs
o message expectations on generated test-doubles and
real objects alike.
17. Mocking - Stubbing
•Test double
o book = double("book")
•Method Stubs
o book.stub(:title) { "The RSpec Book" }
o book.stub(:title => "The RSpec Book")
o book.stub(:title).and_return("The RSpec Book")
•Message expectations
o person = double("person")
o Person.should_receive(:find) { person }
•should_receive vs stub
18. Mocking - Stubbing
•Good for
o Speed up testing
o Real object is unavailable
o Difficult to access from a test environment: External
services
o Queries with complicated data setup
19. Mocking - Stubbing
•Problems
o Simulated API gets out of sync with actual API
o Leads to testing implementation, not effect
o Demands on integration and exploratory testing higher
with mocks
o Less value per line of test code!
24. Controller specs
•Simulate a single HTTP verb in each example
o GET
o POST
o PUT
o DELETE
o XHR
•Accessable variables
o controller, request, response
o assigns, cookies, flash, and session
25. Controller specs
•Check rendering
oCorrect template
response.should render_template
oRedirect
response.should redirect_to (url or hash)
o Status code
response.code.should eq(200)
•Verify variable assignments
o Instance variables assigned in the controller to be
shared with the view
o Cookies sent back with the response
cookies['key']
cookies['key']
29. Model specs
For detail, a model spec should include:
•Attributes
o model attributes should have
•Association
o model association should have
•The model’s create method -> check the
validation work?
o passed valid attributes => should be valid.
o fail validations => should not be valid.
•Class and instance methods perform as
expected
37. Rspec vs Cucumber
•Both testing frameworks.
•Both are used for Acceptance Testing
•These are business-case driven Integration
Tests
o simulate the way a user uses the application,
o the way the different parts of your application work
together can be found in a way that unit testing will not
find.
same
38. Rspec vs Cucumber
•RSpec and Cucumber are the business
readability factor
difference
CU CU M B ER
odraw is that the
specification (features)
from the test code
oproduct owners can
provide or review without
having to dig through code
R SPEC
odescribe a step with a
Describe, Context or It
block that contains the
business specification
oa little easier for
developers to work
obut a little harder for
non-technical folks
40. Integration test with rspec and capybara
(and Senelium)
Feature Specs
•Introduce
•Setup env
•Example code
41. Feature Specs - Introduce
•high-level tests meant to exercise slices of
functionality through an application. Drive the
application only via its external interface,
usually web pages.
•Require the capybara gem, version 2.0.0 or
later. Refer to the capybara API for more infos
on the methods and matchers
•Feature, scenario, background,
given DSL <=>describe, it, before
each, let. Alias methods that allow to read
more as customer tests and acceptance tests.
42. Feature Specs - Setup env
First, add Capybara to your
Gemfile:
In spec/spec_helper.rb,
add two require calls for
Capybara near the top
Capybara’s DSL will be
available spec/requests
and spec/integration
directory
43. Feature Specs - Selenium
First, add Capybara to your
Gemfile:
In spec/spec_helper.rb,
add two require calls for
Capybara near the top
•Run Selenium, just set :js => true
Firefox should
automatically
fire up and run
with Selenium.
•Capybara.default_driver = :selenium (make
Capybara to all your tests - don’t recommend)
•Using Rack::Test (default driver) and Selenium
(JS driver) by setting the :js attribute (faster if use
Selenium for tests that actually require JS)
44. Feature Specs - Sample code
When writing integration tests, try to model the test around an actor (user of the system) and
the action they are performing.
