Presentation materials from the first part of my tutorial at Lone Star Ruby Conf 2010. Code is at: http://github.com/sbellware/preview-signup/tree/work

1. Rapid, Light-Weight Test-Driven Web
UI with Rails, RSpec, and Selenium
Scott Bellware
Ampersand GT
@ampgt
http://ampgt.com

2. Ruby: every now and then, more impressive
testing tools than impressive testing ideas

3. The purpose of testing is to gain an understanding that
you don't already have, not to calcify the understanding
that you already do have

4. The language of tests
should be at a higher
level than the language of
the thing being tested
When the language of
the tests is at the same
level as the thing being
tested, the size of the
audience that benefits
from tests is drastically
reduced

5. Given/When/Then is at a
level of specificity that is
too close to the thing
being specified to be useful
in the general case

6. A Contrived Example
Given that I’m a User
When I’m on the Login page
And I enter ‘foo’ into the username textbox
And I enter ‘bar’ into the password textbox
And I click the login button
Then I should see the successful login message

7. The Problem
The english specification is at the same
level of specificity as the program code
While this is thorough and formal, it’s
excessive and ultimately counter-
productive

8. Have You Considered
If the goal is to communicate the line-by-
line specificity of test code, why not just
show the users clean Ruby code?
(and learn how to write Ruby test code
that is clean enough that users can
understand with your stewardship)

9. Mindless Orthodoxy
“Users are interested in the same level
of detail of specification that
programmers deal with when writing
test and program code”

10. Reality
Users want to know that you’ve
understood what they’ve asked for and
they need to trust you to turn that
understanding into capabilities that meet
their expectations

11. Minimal Specificity
A user, when logged in, can access
protected resources

12. Maximal Specificity
Given that I’m a User
When I’m on the Login page
And I enter ‘foo’ into the username textbox
And I enter ‘bar’ into the password textbox
And I click the login button
Then I should see the successful login message

13. If this Is the Right Level
of Specificity...
A user, when logged in, can access
protected resources

14. Then this Is Waste
Given that I’m a User
When I’m on the Login page
And I enter ‘foo’ into the username textbox
And I enter ‘bar’ into the password textbox
And I click the login button
Then I should see the successful login message

15. Audience
The general audience for highly-detailed
specifications is programmers
(if programmers need highly-detailed
specifications, they can read the
specification code)

16. The Punchline
Don’t translate program code into
English if the only people who care
about that level of detail can already
read program code

17. The right form of
specification in-practice is
always more powerful than
BDD:
an orthodoxy
the exception
rather than
the rule

18. BDD
use it when no other form of
communication is sufficient
(when as little detail as
possible won’t do, use more
detail)

19. Over-Specification
If your goal is to reduce productivity,
over-specification will provide you with
one of the quickest routes.
(the other terminology for
“over-specification” is
“tight coupling”)

20. So... How Much Testing?
The Agile Answer:
As much as possible, as soon as possible
(orthodoxy, methodology recipes)
The Lean Answer:
As little as possible, as late as possible
(principles, momentary ingredients)

21. How Little is Little?
Often, a minimum amount of testing
in software is a lot of testing

22. How Late is Late?
Usually, testing should being when
requirements are being defined

23. This is Efficiency, Not
Productivity
holding pen:
Design Dev waiting for Test (blocked)
testing

24. Productivity
One of the great benefits of testing is
the removal of typical obstructions to
productivity

25. Obstructions to
Productivity
Relearning is the silent killer
(once you solve the problem
of too many defects)

26. Principles
Don’t over-test, don’t under test
Don’t start too late, don’t start too early
Write tests to communicate as clearly as possible
Don’t presume to automate until automation
has sufficient payoff

27. When Does
Automation Payoff?
It depends...
...on team size
...on project size
...on diversity of skill
...on speed of new learning
...on rate of knowledge loss

28. Testing is NOT
Automation
Learn to differentiate between testing
and automated testing, and know when
either is the right choice
(eliminating repetitive work only
matters if the repetition is more
costly than creating and maintaining
automation, and trading off the
rigidity of “test shackles”)
(DRY is not its own justification)

29. When To Start Testing?
The moment you have an
assumption!!!
(which is any time you have an idea
that hasn’t been validated)

30. When To Start
Automating?
Before it’s too late!!!
(the definition of too late depends on
a variety of factors that are usually
different between different teams and
different projects)

31. Cost Traditional Agile
Time

32. Cost Traditional Agile
Time

33. Lean
Testing
Automated Testing
Problem Solution
Cost
Development Development
Time

34. Lean
Testing
Automated Testing
Problem Solution
Cost
Development Development
a bit too late
Time

35. Context Specification
•Form of test-driven development
•Specification
•Documentation
•Making knowledge persistent and consistent
•Holistic optimization
•Principled, rather than orthodox

36. You have to mindfully practice something long enough and to understand its
principles deeply enough to see the orthodoxy
(and not be misdirected by it)

37. Wax On. Wax Off.
Understand the difference between preparation and action
(all concrete forms are the preparation,
not the action)
(in real life, Daniel Larusso would have been creamed
for failing to make this distinction at the critical moment)

38. Thanks!
http://ampgt.com