Your SlideShare is downloading. ×

Can You Hear Me Now? Tackling Telephony Testing

423

Published 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

Published in: Technology, Spiritual
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
423
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
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

×