4. How Telephony Testing Is Different
• Apps are long-running code
• Inputs may be more constrained (DTMF)
5. How Telephony Testing Is Different
• Apps are long-running code
• Inputs may be more constrained (DTMF)
• Or they may be less constrained (IM, Voice)
6. 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
7. 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)
8. 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
10. How Telephony Testing Is Familiar
• Same Tooling: rspec, mocha, cucumber,
factory_girl, guard, rcov, rake
11. How Telephony Testing Is Familiar
• Same Tooling: rspec, mocha, cucumber,
factory_girl, guard, rcov, rake
• Still draw lines between M, V and C
12. 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
13. 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
14. 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
17. Philosophy: SRP
• Single Responsibility Principle
• If you need to use “and” to describe the
purpose of a class, you are probably
breaking this rule
18. 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
20. SRP Example
• Class purpose: “To
schedule calls and to
place them”
21. SRP Example
• Class purpose: “To
schedule calls and to
place them”
• Testing requires mocking
methods within the same
class
22. 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
32. Philosophy: Prefer/Share Immutable
• Methods should only use passed-in data
• Avoid instance vars or other shared state
• Especially helpful with concurrent code
33. 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
55. Functional Testing
• Test just one unit in isolation
• Typical unit is a single class
• Test function of class
but do not make
assertions about
internal state
58. Unit Testing
• Most common form of testing
• Test that a given unit (typically: method)
behaves the way you expect
59. Unit Testing
• Most common form of testing
• Test that a given unit (typically: method)
behaves the way you expect
• Make sure to test:
60. 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
61. 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
62. 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
68. Testing Concurrency
• Design with a concurrency model or library
• Celluloid, EventMachine
• Use State Machines to guarantee sequence
69. 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
70. 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
74. Can You Hear Me Now?
Tackling Testing Telephony Ben Klang
bklang@mojolingo.com
spkr8.com/t/12971 @bklang Github/Twitter
Thanks to Ben Langfeld for his
assistance with this presentation
@benlangfeld