Can You Hear Me Now? Tackling Telephony Testing

  • 366 views
Uploaded on

This presentation was given by Ben Klang as part of Lone Star Ruby Conference 6

This presentation was given by Ben Klang as part of Lone Star Ruby Conference 6

More in: Technology , Spiritual
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
366
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Can You Hear Me Now? Tackling Testing Telephony Ben Klang bklang@mojolingo.comFriday, August 10, 12
  • 2. How Telephony Testing Is DifferentFriday, August 10, 12
  • 3. How Telephony Testing Is Different • Apps are long-running codeFriday, August 10, 12
  • 4. How Telephony Testing Is Different • Apps are long-running code • Inputs may be more constrained (DTMF)Friday, August 10, 12
  • 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)Friday, August 10, 12
  • 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 concurrentlyFriday, August 10, 12
  • 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)Friday, August 10, 12
  • 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 EventsFriday, August 10, 12
  • 9. How Telephony Testing Is FamiliarFriday, August 10, 12
  • 10. How Telephony Testing Is Familiar • Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rakeFriday, August 10, 12
  • 11. How Telephony Testing Is Familiar • Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake • Still draw lines between M, V and CFriday, August 10, 12
  • 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 importantFriday, August 10, 12
  • 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 importantFriday, August 10, 12
  • 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 RubyFriday, August 10, 12
  • 15. Philosophy: SRPFriday, August 10, 12
  • 16. Philosophy: SRP • Single Responsibility PrincipleFriday, August 10, 12
  • 17. Philosophy: SRP • Single Responsibility Principle • If you need to use “and” to describe the purpose of a class, you are probably breaking this ruleFriday, August 10, 12
  • 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 testableFriday, August 10, 12
  • 19. SRP ExampleFriday, August 10, 12
  • 20. SRP Example • Class purpose: “To schedule calls and to place them”Friday, August 10, 12
  • 21. SRP Example • Class purpose: “To schedule calls and to place them” • Testing requires mocking methods within the same classFriday, August 10, 12
  • 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 mechanismFriday, August 10, 12
  • 23. Philosophy: Tell, Don’t AskFriday, August 10, 12
  • 24. Philosophy: Tell, Don’t Ask • Tell an object to do its workFriday, August 10, 12
  • 25. Philosophy: Tell, Don’t Ask • Tell an object to do its work • Don’t ask for its state then ask it to do somethingFriday, August 10, 12
  • 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 SRPFriday, August 10, 12
  • 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 SRPFriday, August 10, 12
  • 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 SRPFriday, August 10, 12
  • 29. Philosophy: Prefer/Share ImmutableFriday, August 10, 12
  • 30. Philosophy: Prefer/Share Immutable • Methods should only use passed-in dataFriday, August 10, 12
  • 31. Philosophy: Prefer/Share Immutable • Methods should only use passed-in data • Avoid instance vars or other shared stateFriday, August 10, 12
  • 32. Philosophy: Prefer/Share Immutable • Methods should only use passed-in data • Avoid instance vars or other shared state • Especially helpful with concurrent codeFriday, August 10, 12
  • 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 easierFriday, August 10, 12
  • 34. Prefer/Share Immutable ExampleFriday, August 10, 12
  • 35. Prefer/Share Immutable ExampleFriday, August 10, 12
  • 36. Prefer/Share Immutable ExampleFriday, August 10, 12
  • 37. Prefer/Share Immutable ExampleFriday, August 10, 12
  • 38. Levels of TestingFriday, August 10, 12
  • 39. Levels of Testing IntegrationFriday, August 10, 12
  • 40. Levels of Testing Integration FunctionalFriday, August 10, 12
  • 41. Levels of Testing Integration Functional UnitFriday, August 10, 12
  • 42. Levels of TestingFriday, August 10, 12
  • 43. Levels of Testing • Integration TestingFriday, August 10, 12
  • 44. Levels of Testing • Integration Testing • End-to-EndFriday, August 10, 12
  • 45. Levels of Testing • Integration Testing • End-to-End • Provide predefined inputsFriday, August 10, 12
  • 46. Levels of Testing • Integration Testing • End-to-End • Provide predefined inputs • Verify outputsFriday, August 10, 12
  • 47. Levels of Testing • Integration Testing • End-to-End • Provide predefined inputs • Verify outputs • Mock as little as possibleFriday, August 10, 12
  • 48. Integration Testing Tools for TelephonyFriday, August 10, 12
  • 49. Integration Testing Tools for Telephony • sipp: sipp.sourceforge.netFriday, August 10, 12
  • 50. Integration Testing Tools for Telephony • sipp: sipp.sourceforge.net • Loadbot: github.com/mojolingo/ahn-loadbotFriday, August 10, 12
  • 51. Integration Testing Tools for Telephony • sipp: sipp.sourceforge.net • Loadbot: github.com/mojolingo/ahn-loadbot • Cucumber-VoIP: github.com/benlangfeld/cucumber-voipFriday, August 10, 12
  • 52. Functional TestingFriday, August 10, 12
  • 53. Functional Testing • Test just one unit in isolationFriday, August 10, 12
  • 54. Functional Testing • Test just one unit in isolation • Typical unit is a single classFriday, August 10, 12
  • 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 stateFriday, August 10, 12
  • 56. Unit TestingFriday, August 10, 12
  • 57. Unit Testing • Most common form of testingFriday, August 10, 12
  • 58. Unit Testing • Most common form of testing • Test that a given unit (typically: method) behaves the way you expectFriday, August 10, 12
  • 59. Unit Testing • Most common form of testing • Test that a given unit (typically: method) behaves the way you expect • Make sure to test:Friday, August 10, 12
  • 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 inputsFriday, August 10, 12
  • 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 inputsFriday, August 10, 12
  • 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 ConditionsFriday, August 10, 12
  • 63. Unit Testing ExampleFriday, August 10, 12
  • 64. Unit Testing ExampleFriday, August 10, 12
  • 65. Testing ConcurrencyFriday, August 10, 12
  • 66. Testing Concurrency • Design with a concurrency model or libraryFriday, August 10, 12
  • 67. Testing Concurrency • Design with a concurrency model or library • Celluloid, EventMachineFriday, August 10, 12
  • 68. Testing Concurrency • Design with a concurrency model or library • Celluloid, EventMachine • Use State Machines to guarantee sequenceFriday, August 10, 12
  • 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 mocksFriday, August 10, 12
  • 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 timeoutFriday, August 10, 12
  • 71. Testing Concurrency https://github.com/benlangfeld/countdownlatchFriday, August 10, 12
  • 72. Testing Concurrency https://github.com/benlangfeld/countdownlatchFriday, August 10, 12
  • 73. http://adhearsion.com/conference/2012Friday, August 10, 12
  • 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 @benlangfeldFriday, August 10, 12