This document discusses testing telephony applications. It notes that telephony applications are long-running code with inputs that may be more or less constrained, and many things can happen concurrently. It recommends using the same testing tools like RSpec, but also following principles like single responsibility per class and immutable/shared objects. The document outlines different levels of testing from integration to functional to unit, and provides examples for testing concurrency.

1. Can You Hear Me Now?
Tackling Testing Telephony
Ben Klang
bklang@mojolingo.com

2. How Telephony Testing Is Different

3. How Telephony Testing Is Different
• Apps are long-running code

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

9. How Telephony Testing Is Familiar

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

15. Philosophy: SRP

16. Philosophy: SRP
• Single Responsibility Principle

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

19. SRP Example

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

23. Philosophy: Tell, Don’t Ask

24. Philosophy: Tell, Don’t Ask
• Tell an object to do its work

25. Philosophy: Tell, Don’t Ask
• Tell an object to do its work
• Don’t ask for its state then ask it to do
something

26. 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

27. 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

28. 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

29. Philosophy: Prefer/Share Immutable

30. Philosophy: Prefer/Share Immutable
• Methods should only use passed-in data

31. Philosophy: Prefer/Share Immutable
• Methods should only use passed-in data
• Avoid instance vars or other shared state

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

34. Prefer/Share Immutable Example

35. Prefer/Share Immutable Example

36. Prefer/Share Immutable Example

37. Prefer/Share Immutable Example

38. Levels of Testing

39. Levels of Testing
Integration

40. Levels of Testing
Integration
Functional

41. Levels of Testing
Integration
Functional
Unit

42. Levels of Testing

43. Levels of Testing
• Integration Testing

44. Levels of Testing
• Integration Testing
• End-to-End

45. Levels of Testing
• Integration Testing
• End-to-End
• Provide predefined inputs

46. Levels of Testing
• Integration Testing
• End-to-End
• Provide predefined inputs
• Verify outputs

47. Levels of Testing
• Integration Testing
• End-to-End
• Provide predefined inputs
• Verify outputs
• Mock as little as possible

48. Integration Testing Tools for Telephony

49. Integration Testing Tools for Telephony
• sipp:
sipp.sourceforge.net

50. Integration Testing Tools for Telephony
• sipp:
sipp.sourceforge.net
• Loadbot:
github.com/mojolingo/ahn-loadbot

51. Integration Testing Tools for Telephony
• sipp:
sipp.sourceforge.net
• Loadbot:
github.com/mojolingo/ahn-loadbot
• Cucumber-VoIP:
github.com/benlangfeld/cucumber-voip

52. Functional Testing

53. Functional Testing
• Test just one unit in isolation

54. Functional Testing
• Test just one unit in isolation
• Typical unit is a single class

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

56. Unit Testing

57. Unit Testing
• Most common form of testing

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

63. Unit Testing Example

64. Unit Testing Example

65. Testing Concurrency

66. Testing Concurrency
• Design with a concurrency model or library

67. Testing Concurrency
• Design with a concurrency model or library
• Celluloid, EventMachine

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

71. Testing Concurrency
https://github.com/benlangfeld/countdownlatch

72. Testing Concurrency
https://github.com/benlangfeld/countdownlatch

73. http://adhearsion.com/conference/2012

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