1 - Middle-out TDD¶ ↑

david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Not religiously sticking to developing the tests (ie unit tests) first

Think about and start to formulate the system reqs + spec

Create the crude system first and then incrementally add tests (at the appropriate level) and code

2 - RSpec TDD/BDD¶ ↑

https://relishapp.com/rspec/rspec-core/docs
https://github.com/rspec/rspec-core

Unit ('models/*')

Classical TDD (ie use real objects rather than doubles)

Integration ('controllers/*', 'requests/*')

Classical TDD

Transition to BDD - Requests vs Features

Features higher, dumb user, level
Requests at browser level but with some HTTP knowledge eg get, put, post, delete and expect HTTP response values

Acceptance ('features/*' + Capybara + FactoryGirl + Stub the current user)

BDD (evolution from Mockist TDD)

FactoryGirl creates objects that are ruby'ised fixtures
Similar to RSpec stubs

http://railscasts.com/episodes/158-factories-not-fixtures?view=asciicast
https://github.com/thoughtbot/factory_girl

3 - Test Doubles¶ ↑

rspec-mocks: Pure O-O languages like Ruby have a middleware built in that receives messages for method calls

Dynamically typed so determined at run-time by middleware
Not like statically typed O-O langs (eg Java, C++) determined a compile-time 

Can hook messages sent to objects as integration tests
Can change methods in code to return specified value in response to a message

Mocks vs Stubs

http://martinfowler.com/articles/mocksArentStubs.html

Mock is a smarter Stub, a test Double (others doubles: dummy, fake, stubs)
Mocks set expectations (behaviour verification), Stubs just return a value (state verification)