Upload
mojo-lingo
View
68
Download
0
Embed Size (px)
DESCRIPTION
Tackling Testing Telephony presented by Ben Klang, Mojo Lingo, at Lone Star Ruby Conference 2012
Citation preview
Can You Hear Me Now?
Tackling Testing TelephonyBen Klang
How Telephony Testing Is Different
How Telephony Testing Is Different
•Apps are long-running code
How Telephony Testing Is Different
•Apps are long-running code
• Inputs may be more constrained (DTMF)
How Telephony Testing Is Different
•Apps are long-running code
• Inputs may be more constrained (DTMF)
•Or they may be less constrained (IM, Voice)
How Telephony Testing Is Different
•Apps are long-running code
• Inputs may be more constrained (DTMF)
•Or they may be less constrained (IM, Voice)
•Lots of things are happening concurrently
How Telephony Testing Is Different
•Apps are long-running code
• Inputs may be more constrained (DTMF)
•Or they may be less constrained (IM, Voice)
•Lots of things are happening concurrently
•External call interactions (conf, barge)
How Telephony Testing Is Different
•Apps are long-running code
• Inputs may be more constrained (DTMF)
•Or they may be less constrained (IM, Voice)
•Lots of things are happening concurrently
•External call interactions (conf, barge)
•XMPP Events
How Telephony Testing Is Familiar
How Telephony Testing Is Familiar
•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake
How Telephony Testing Is Familiar
•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake
•Still draw lines between M, V and C
How Telephony Testing Is Familiar
•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake
•Still draw lines between M, V and C
•Good class design is important
How Telephony Testing Is Familiar
•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake
•Still draw lines between M, V and C
•Good class design is important
How Telephony Testing Is Familiar
•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake
•Still draw lines between M, V and C
•Good class design is important
• It’s Just Ruby
Philosophy: SRP
Philosophy: SRP
•Single Responsibility Principle
Philosophy: SRP
•Single Responsibility Principle
• If you need to use “and” to describe the purpose of a class, you are probably breaking this rule
Philosophy: SRP
•Single Responsibility Principle
• If you need to use “and” to describe the purpose of a class, you are probably breaking this rule
•SRP is key to making classes testable
SRP Example
SRP Example•Class purpose: “To schedule calls and to place them”
SRP Example•Class purpose: “To schedule calls and to place them”
•Testing requires mocking methods within the same class
SRP Example•Class purpose: “To schedule calls and to place them”
•Testing requires mocking methods within the same class
•Non-trivial work to swap calling mechanism
Philosophy: Tell, Don’t Ask
Philosophy: Tell, Don’t Ask
•Tell an object to do its work
Philosophy: Tell, Don’t Ask
•Tell an object to do its work
•Don’t ask for its state then ask it to do something
Philosophy: Tell, Don’t Ask
•Tell an object to do its work
•Don’t ask for its state then ask it to do something
•Works Hand-in-Hand with SRP
Philosophy: Tell, Don’t Ask
•Tell an object to do its work
•Don’t ask for its state then ask it to do something
•Works Hand-in-Hand with SRP
Philosophy: Tell, Don’t Ask
•Tell an object to do its work
•Don’t ask for its state then ask it to do something
•Works Hand-in-Hand with SRP
Philosophy: Prefer/Share Immutable
Philosophy: Prefer/Share Immutable
•Methods should only use passed-in data
Philosophy: Prefer/Share Immutable
•Methods should only use passed-in data
•Avoid instance vars or other shared state
Philosophy: Prefer/Share Immutable
•Methods should only use passed-in data
•Avoid instance vars or other shared state
•Especially helpful with concurrent code
Philosophy: Prefer/Share Immutable
•Methods should only use passed-in data
•Avoid instance vars or other shared state
•Especially helpful with concurrent code
• ... but makes testing in general easier
Prefer/Share Immutable Example
Prefer/Share Immutable Example
Prefer/Share Immutable Example
Prefer/Share Immutable Example
Levels of Testing
Levels of Testing
Integration
Levels of Testing
Integration
Functional
Levels of Testing
Integration
Functional
Unit
Levels of Testing
Levels of Testing
• Integration Testing
Levels of Testing
• Integration Testing
•End-to-End
Levels of Testing
• Integration Testing
•End-to-End
•Provide predefined inputs
Levels of Testing
• Integration Testing
•End-to-End
•Provide predefined inputs
•Verify outputs
Levels of Testing
• Integration Testing
•End-to-End
•Provide predefined inputs
•Verify outputs
•Mock as little as possible
Integration Testing Tools for Telephony
Integration Testing Tools for Telephony• sipp:sipp.sourceforge.net
Integration Testing Tools for Telephony• sipp:sipp.sourceforge.net
• Loadbot:github.com/mojolingo/ahn-loadbot
Integration Testing Tools for Telephony• sipp:sipp.sourceforge.net
• Loadbot:github.com/mojolingo/ahn-loadbot
• Cucumber-VoIP:github.com/benlangfeld/cucumber-voip
Functional Testing
Functional Testing
•Test just one unit in isolation
Functional Testing
•Test just one unit in isolation
•Typical unit is a single class
Functional Testing
•Test just one unit in isolation
•Typical unit is a single class
•Test function of classbut do not makeassertions about internal state
Unit Testing
Unit Testing
•Most common form of testing
Unit Testing
•Most common form of testing
•Test that a given unit (typically: method) behaves the way you expect
Unit Testing
•Most common form of testing
•Test that a given unit (typically: method) behaves the way you expect
•Make sure to test:
Unit Testing
•Most common form of testing
•Test that a given unit (typically: method) behaves the way you expect
•Make sure to test:•Valid inputs
Unit Testing
•Most common form of testing
•Test that a given unit (typically: method) behaves the way you expect
•Make sure to test:•Valid inputs• Invalid inputs
Unit Testing
•Most common form of testing
•Test that a given unit (typically: method) behaves the way you expect
•Make sure to test:•Valid inputs• Invalid inputs•Error Conditions
Unit Testing Example
Unit Testing Example
Testing Concurrency
Testing Concurrency
•Design with a concurrency model or library
Testing Concurrency
•Design with a concurrency model or library
•Celluloid, EventMachine
Testing Concurrency
•Design with a concurrency model or library
•Celluloid, EventMachine
•Use State Machines to guarantee sequence
Testing Concurrency
•Design with a concurrency model or library
•Celluloid, EventMachine
•Use State Machines to guarantee sequence
•Mock non-blocking dependent operations with blocking mocks
Testing Concurrency
•Design with a concurrency model or library
•Celluloid, EventMachine
•Use State Machines to guarantee sequence
•Mock non-blocking dependent operations with blocking mocks
•Always provide a timeout
Testing Concurrency
https://github.com/benlangfeld/countdownlatch
Testing Concurrency
https://github.com/benlangfeld/countdownlatch
http://adhearsion.com/conference/2012
Can You Hear Me Now?
Tackling Testing Telephony Ben [email protected]@bklang Github/Twitterspkr8.com/t/12971
Thanks to Ben Langfeld for his assistance with this presentation@benlangfeld