This document provides an overview of testing and discusses four main purposes of testing: assertion, design, communication, and discovery. It discusses using tests for assertion to ensure code behaves as expected. Tests can also be used as a design tool, such as with test-driven development (TDD) or behavior-driven development (BDD). Well-named tests improve communication by clearly describing intended behavior. Characterization tests are used for discovery when working with legacy code without tests, to understand what the code is doing before changing it. The document provides examples of using tests for each purpose.

1. Testing.has_many
:purposes
by Alex Sharp
@ajsharp

2. I’m Alex Sharp.

3. I work for a healthcare startup called OptimisCorp.

4. We’re based in Pacific Palisades, just north
of Santa Monica.

5. We’re hiring.

7. So if you want to work by the beach in Santa
Monica, get in touch with me ;)

8. Brass Tacks
This is a talk about the many purposes and
benefits of testing.

9. Brass Tacks
We’ll span the testing horizon, but...

10. Brass Tacks
We’re going to talk a lot about LEGACY CODE

11. 4 Main Purposes of Testing
1. Assertion
2. Design
3. Communication
4. Discovery

12. Purpose #1: Assertion

13. 4 Main Purposes of Testing
1. Assertion
We “exercise” production code with test
code to ensure it’s behavior (test harness)

15. class Person
attr_accessor :interests
def initialize
@interests = []
end
end

16. class Person
attr_accessor :interests
def initialize
@interests = []
end
end
describe Person do
before(:each) { @alex = Person.new }
it "should have interests" do
@alex.should respond_to :interests
end
end

17. class Person
attr_accessor :interests
def initialize
@interests = []
end
end
describe Person do
before(:each) { @alex = Person.new }
it "should have interests" do
@alex.should respond_to :interests
end
end

18. Tests are commonly used as a design tool

19. Or as we call it...

20. TDD
Test Driven Development

21. TDD
I love TDD

22. TDD
I love BDD more

23. TDD
Why??

24. TDD
BDD > TDD

25. TDD
BDD is more clear about how and what to test.

26. Contrived Example
class TDD
def when_to_test
"first"
end
def how_to_test
"??"
end
end
class BDD < TDD
def how_to_test
"outside-in"
end
end

27. Why test-first?
I write better code when it’s test-driven

28. Better like how?
Simpler

29. Better like how?
More modular

30. Better like how?
More maintainable

31. Better like how?
More stable

32. Better like how?
More readable

33. Better like how?
MORE BETTER

34. Purpose #2: Design

35. Design

36. Design

37. Design
We can use tests to design and describe the
behavior of software.

38. Design
We can use tests to design and describe the
behavior of software.
But not necessarily HOW...

39. Design
i.e. Behavior Driven Development

40. BDD
“I found the shift from thinking in tests to thinking in
behaviour so profound that I started to refer to TDD as
BDD, or behaviour- driven development.”
-- Dan North, http://dannorth.net/introducing-bdd

41. BDD
BDD is a different way of thinking about testing

42. BDD
Not in terms of tests, but in terms of behavior

43. A cucumber feature
Scenario: Creating a new owner
When I go to the new owner page # create new action and routes
And I fill in the following:
| Name | Alex’s Properties |
| Phone | 111-222-3333 |
| Email | email@alex.com |
And I press "Create"
Then I should see "Owner was successfully created."

44. A cucumber feature
Scenario: Creating a new owner
When I go to the new owner page
And I fill in the following:
| Name | Alex’s Properties | # database migrations, model validations
| Phone | 111-222-3333 | # create action
| Email | email@alex.com |
And I press "Create"
Then I should see "Owner was successfully created."

45. A cucumber feature
Scenario: Creating a new owner
When I go to the new owner page
And I fill in the following:
| Name | Alex’s Properties |
| Phone | 111-222-3333 |
| Email | email@alex.com |
And I press "Create"
Then I should see "Owner was successfully created."
# create show action to view new owner

46. Writing Tests vs Describing Behavior
BDD keeps us grounded in business requirements

47. Writing Tests vs Describing Behavior
The concept of BDD is tightly coupled to agile thinking

48. Writing Tests vs Describing Behavior
Only do what’s necessary to accomplish the
business requirement

49. Writing Tests vs Describing Behavior
Then gather feedback and refactor

50. Writing Tests vs Describing Behavior
So we write more more high-value code

51. Writing Tests vs Describing Behavior
And less code gets thrown out

52. Writing Tests vs Describing Behavior
The difference is subtle, but significant.

53. Purpose #3: Communication

54. Communication
Reading code is hard

55. Communication
Sometimes programmer intent is not so clear...

56. Communication
Tests can be a really useful communication tool

57. Communication
Cucumber greatly facilitates communication
between customer and programmer

58. Communication
But programmers need to communicate too...

59. Communication
Problem: Everyone else’s code is crap...

60. Communication
Tests can help mitigate the WTF factor and
communicate the author’s intent

62. def display_address
[address1, address2].reject { |address| address.nil? }.join(", ")
end

63. def display_address
[address1, address2].reject { |address| address.nil? }.join(", ")
end
it "should display the first part of the street address if it exists" do
@demographic.display_address.should == "123 Main St"
end
it "should display the first and second street addresses if they exist" do
@demographic.address2 = "Apt 2"
@demographic.display_address.should == "123 Main St, Apt 2"
end
it "should display an empty string if neither exist" do
@demographic.address1 = @demographic.address2 = nil
@demographic.display_address.should == ""
end

64. Communication
Tests usually communicate business requirements
much better than production code

65. Communication
We can facilitate programmer communication by
using good practices in test code

66. Communication
So we need some “good testing practices”

67. To that end...
Well-named tests are important in test code as
well as production code...

69. describe User, '#new' do
before :each do
@user = Factory.build(:user)
end
it 'should send an email when saved' do
lambda {
@user.save
}.should change(ActionMailer::Base.deliveries, :size)
end
end

70. describe User, '#new' do
before :each do
@user = Factory.build(:user)
end
it 'should send an email when saved' do
lambda {
@user.save
}.should change(ActionMailer::Base.deliveries, :size)
end
end
Intended behavior is pretty clear

71. it "should not display the same clinic more than once" do
clinics = @user.find_all_clinics_by_practice(@user.practice)
clinics.should == clinics.uniq
end

72. it "should not display the same clinic more than once" do
clinics = @user.find_all_clinics_by_practice(@user.practice)
clinics.should == clinics.uniq
end
Intended behavior is pretty clear

73. Good Testing Conventions
It’s easy to be lazy with naming , but good naming is
about communication.

74. Good Testing Conventions
Test methods should be short, concise and targeted

75. describe Post do
it "should successfully save" do
@post = Post.new :title => "Title", :body => "profound words..."
@post.save.should == true
@post.permalink.should_not be_blank
@post.comments.should_not be_nil
@post.comments.should respond_to :build
end
end

76. X
describe Post do
it "should successfully save" do
@post = Post.new :title => "Title", :body => "profound words..."
@post.save.should == true
@post.permalink.should_not be_blank
@post.comments.should_not be_nil
@post.comments.should respond_to :build
end
end
This is no good.

77. describe Post do
it "should successfully save" do
@post = Post.new :title => "Title", :body => "profound words..."
@post.save.should == true
@post.permalink.should_not be_blank
@post.comments.should_not be_nil
@post.comments.should respond_to :build
end
end

78. describe Post do
it "should successfully save" do
@post = Post.new :title => "Title", :body => "profound words..."
@post.save.should == true
@post.permalink.should_not be_blank
@post.comments.should_not be_nil
@post.comments.should respond_to :build
end
end
Too much is being tested.

79. describe Post do
it "should successfully save" do
@post = Post.new :title => "Title", :body => "profound words..."
@post.save.should == true
@post.permalink.should_not be_blank
@post.comments.should_not be_nil
@post.comments.should respond_to :build
end
end
More than one object being tested
Too much is being tested.

80. A better solution
describe Post do
before :each do
@post = Post.new :title => "Title", :body => "profound words..."
end
it "should successfully save" do
@post.save.should == true
end
it "should create a permalink" do
@post.permalink.should_not be_blank
end
it "should create a comments collection" do
@post.comments.should_not be_nil
end
end

81. Communication Recap
In test code aim for short, concise and clean methods

82. Communication Recap
One assertion per test method (if possible)

83. Communication Recap
Single Responsibility Principle

84. Writing good tests makes it much easier to refactor

85. Good Testing Principles
• Descriptive naming
• Single Responsibility
• Short test methods => readable
• Prefer conciseness and readability over DRY

86. A quick aside...
If you feel like reading some really beautiful
communicative code, take a look at sinatra.
github.com/sinatra/sinatra

87. WARNING!!!

88. Prepare yourself; that was the last of the fun stuff.

89. Software is more than just greenfield projects

90. Legacy code is part of life.

91. So let’s talk about how to test it.

92. But’s first let’s clarify what we mean by “legacy code”

93. For purposes of this
talk...
Legacy code is code without tests.
- Michael Feathers, Working Effectively with Legacy Code

94. Purpose #4: Discovery

95. Generally, we need to do one of two things
when working with legacy code:
1. Refactor
2. Alter behavior

96. Characterization Testing
We use characterization tests when we need
to make changes to untested legacy code

97. Characterization Testing
We need to discover what the code is doing
before we can responsibly change it.

98. Characterization Testing
Let’s start with a real world refactoring example...

99. To refactor is to improve the design of code
without changing it’s behavior

100. def update
@medical_history = @patient.medical_histories.find(params[:id])
@medical_history.taken_date = Date.today if @medical_history.taken_date.nil?
success = true
conditions = @medical_history.existing_conditions_medical_histories.find(:all)
params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end
respond_to do |format|
if @medical_history.update_attributes(params[:medical_history]) && success
format.html {
flash[:notice] = 'Medical History was successfully updated.'
redirect_to( patient_medical_histories_url(@patient) ) }
format.xml { head :ok }
format.js # update.rjs
else
format.html { render :action => "edit" }
format.xml { render :xml => @medical_history.errors, :status => :unprocessable_entity }
format.js { render :text => "Error Updating History", :status => :unprocessable_entity}
end
end
end

101. Characterization Testing
Lot’s of violations here:
1. Fat model, skinny controller
2. Single responsibility
3. Not modular
4. Really hard to fit on a slide

102. This is what I want to focus on
params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end

103. Characterization Testing
I want to refactor in the following ways:
1. Push this code into the model
2. Extract logic into separate methods

104. Characterization Testing
We need to write some characterization
tests and get this action under test

105. Characterization Testing
This way we can rely on an automated
testing workflow to for feedback

106. describe MedicalHistoriesController, "PUT update" do
before :each do
@user = Factory(:practice_admin)
@patient = Factory(:patient_with_medical_histories, :practice => @user.practice)
@medical_history = @patient.medical_histories.first
@condition1 = Factory(:existing_condition)
@condition2 = Factory(:existing_condition)
stub_request_before_filters @user, :practice => true, :clinic => true
params = { :conditions =>
{ "condition_#{@condition1.id}" => "true",
"condition_#{@condition2.id}" => "true" },
:id => @medical_history.id,
:patient_id => @patient.id
}
put :update, params
end
it "should successfully save a collection of conditions" do
@medical_history.existing_conditions.should include @condition1
@medical_history.existing_conditions.should include @condition2
end
end

107. Start by extracting this line
params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end

108. describe StringExtensions, "#extract_last_number" do
it "should respond to #extract_last_number" do
"test_string_123".should respond_to :extract_last_number
end
it "should return numbers included in a string" do
"condition_123_yes".extract_last_number.should == 123
end
it "should return the last number included in a string" do
"condition_777_123_yes".extract_last_number.should == 123
end
it "should return nil if there are no numbers in a string" do
"condition_yes".extract_last_number.should == nil
end
it "should return nil if the string is empty" do
"".extract_last_number.should == nil
end
it "should return a number" do
"condition_234_yes".extract_last_number.should be_instance_of Fixnum
end
end

109. module StringExtensions
def extract_last_number
result = self.to_s.scan(/(d+)/).last
result ? result.last.to_i : nil
end
end
String.send :include, StringExtensions

110. module StringExtensions
def extract_last_number
result = self.to_s.scan(/(d+)/).last
result ? result.last.to_i : nil
end
end
String.send :include, StringExtensions

111. i.e. conditions.find(:all)
params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end

112. params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end

113. def update_conditions(conditions_param = {})
conditions_param.each_pair do |key, value|
condition_id = key.extract_last_number # is extended in lib/reg_exp_helpers.rb
create_or_update_condition(condition_id, value)
end
end
private
def create_or_update_condition(condition_id, value)
condition = existing_conditions_medical_histories.find_by_existing_condition_id(condition_id)
condition.nil? ? create_condition(condition_id, value) : update_condition(condition, value)
end
def create_condition(condition_id, value)
existing_conditions_medical_histories.create(
:existing_condition_id => condition_id,
:has_condition => value
)
end
def update_condition(condition, value)
condition.update_attribute(:has_condition, value) unless condition.has_condition == value
end

114. def update
@medical_history = @patient.medical_histories.find(params[:id])
@medical_history.taken_date = Date.today if @medical_history.taken_date.nil?
#
# edit the existing conditions
#
success = true
conditions = @medical_history.existing_conditions_medical_histories.find(:all)
@medical_history.update_conditions(params[:conditions])
respond_to do |format|
if @medical_history.update_attributes(params[:medical_history]) && success
format.html {
flash[:notice] = 'Medical History was successfully updated.'
redirect_to( patient_medical_histories_url(@patient) ) }
format.xml { head :ok }
format.js # update.rjs
else
format.html { render :action => "edit" }
format.xml { render :xml => @medical_history.errors, :status
=> :unprocessable_entity }
format.js { render :text => "Error Updating History", :status
=> :unprocessable_entity}
end
end

115. We started with this, in the controller...
params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end

116. We finished with this, in the model
def update_conditions(conditions_param = {})
conditions_param.each_pair do |key, value|
create_or_update_condition(key.extract_last_number, value)
end
end

117. It’s not perfect, but refactoring must be done in small steps

118. We started with this, in the controller...
params[:conditions].each_pair do |key,value|
condition_id = key.to_s[10..-1].to_i
condition = conditions.detect {|x| x.existing_condition_id == condition_id }
if condition.nil?
# create the existing_conditions_medical_conditions
success = @medical_history.existing_conditions_medical_histories.create(
:existing_condition_id => condition_id, :has_condition => value) && success
elsif condition.has_condition != value
success = condition.update_attribute(:has_condition, value) && success
end
end

119. Legacy Code
We can identify a few common problems
when working with untested legacy code.

120. Legacy Code
1. Lack of sane design principles
2. Dependency hell
3. Unknown calling code

121. Legacy Code
“...in legacy code, often all bets are off.”
- Michael Feathers, Working Effectively with Legacy Code

122. Legacy Code
How do we protect against dependencies we
don’t know about?

123. Ideal Scenario
In the ideal scenario, you know all the places
from which a particular API is being invoked

124. Ideal Scenario
Resolving calling code dependencies is trivial

125. More Likely Scenario
However, this is not likely, especially for larger apps

126. More Likely Scenario
Unfortunately, much of the discussion around
this issue assumes awareness of calling code

127. More Likely Scenario
This is an unfortunate assumption

128. More Likely Scenario
Frequent Offender: Rails controllers

129. Example
Solution: Direct known calling code elsewhere

130. Example
Treat your app like a public API

131. Example
Deprecate it gradually

132. We want to alter
some behavior here Calling Code
index.erb
PatientsControllerV2#index
PatientsController#index Known calls
show.erb
phantom ajax call Unknown calls

133. We want to alter
some behavior here Calling Code
index.erb
PatientsControllerV2#index Known calls
show.erb
PatientsController#index phantom ajax call Unknown calls

134. class PatientsController < ApplicationController
def find_by_name
@patients = []
if params[:name] then
@patients = @practice.patients.search(params[:name], nil)
elsif params[:last_name] and params[:first_name]
@patients = @practice.patients.find( :all,
:conditions => [ 'last_name like ? and first_name like ?', params[:last_name] + '%',
params[:first_name] + '%' ],
:order => 'last_name, first_name' )
end
respond_to do |format|
format.json { render :json => @patients.to_json(:methods => [
:full_name_last_first, :age, :home_phone, :prefered_phone ]),
:layout => false
}
end
end
def index
@patients = @practice.patients.search(params[:search], params[:page])
respond_to do |format|
format.html { render :layout => 'application' } # index.html.erb
format.xml { render :xml => @patients }
format.json { render :json => @patients.to_json(:methods =>
[ :full_name_last_first, :age ]), :layout => false }
end
end
end

135. class V2::PatientsController < ApplicationController
def index
@patients = @practice.patients.all_paginated([], [], params[:page])
respond_to do |format|
format.html { render :layout => 'application', :template => 'patients/index' }
end
end
end

136. class PatientsController < ApplicationController
def index
logger.warn "DEPRECATION WARNING! Please use /v2/patients"
HoptoadNotifier.notify(
:error_class => "DEPRECATION",
:error_message => "DEPRECATION WARNING!: /patients/index invoked",
:parameters => params
)
@patients = @practice.patients.search(params[:search], params[:page])
respond_to do |format|
format.html { render :layout => 'application' } # index.html.erb
format.xml { render :xml => @patients }
format.json { render :json => @patients.to_json(:methods =>
[ :full_name_last_first, :age ]), :layout => false }
end
end
end

137. Further Resources