Can You Hear Me Now? Tackling Telephony Testing
•
0 j'aime•625 vues
The document discusses testing for telephony applications. It notes that telephony apps are long-running with both constrained and unconstrained inputs, as well as external call interactions happening concurrently. Testing approaches include integration testing using tools like sipp and Cucumber-VoIP, functional testing of single classes, and unit testing of methods with various input types. It recommends designing for concurrency, using state machines, and mocking dependencies for testing concurrency.
Recommandé
Contenu connexe
Similaire à Can You Hear Me Now? Tackling Telephony Testing
Similaire à Can You Hear Me Now? Tackling Telephony Testing (10)
Plus de Adhearsion Foundation
Plus de Adhearsion Foundation (10)
Dernier
Dernier (20)
Can You Hear Me Now? Tackling Telephony Testing
- 1. Can You Hear Me Now? Tackling Testing Telephony Ben Klang bklang@mojolingo.com Friday, August 10, 12
- 2. How Telephony Testing Is Different Friday, August 10, 12
- 3. How Telephony Testing Is Different • Apps are long-running code Friday, 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 concurrently Friday, 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 Events Friday, August 10, 12
- 9. How Telephony Testing Is Familiar Friday, August 10, 12
- 10. How Telephony Testing Is Familiar • Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake Friday, 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 C Friday, 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 important Friday, 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 important Friday, 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 Ruby Friday, August 10, 12
- 15. Philosophy: SRP Friday, August 10, 12
- 16. Philosophy: SRP • Single Responsibility Principle Friday, 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 rule Friday, 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 testable Friday, August 10, 12
- 19. SRP Example Friday, 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 class Friday, 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 mechanism Friday, August 10, 12
- 23. Philosophy: Tell, Don’t Ask Friday, August 10, 12
- 24. Philosophy: Tell, Don’t Ask • Tell an object to do its work Friday, 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 something Friday, 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 SRP Friday, 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 SRP Friday, 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 SRP Friday, August 10, 12
- 29. Philosophy: Prefer/Share Immutable Friday, August 10, 12
- 30. Philosophy: Prefer/Share Immutable • Methods should only use passed-in data Friday, August 10, 12
- 31. Philosophy: Prefer/Share Immutable • Methods should only use passed-in data • Avoid instance vars or other shared state Friday, 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 code Friday, 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 easier Friday, August 10, 12
- 34. Prefer/Share Immutable Example Friday, August 10, 12
- 35. Prefer/Share Immutable Example Friday, August 10, 12
- 36. Prefer/Share Immutable Example Friday, August 10, 12
- 37. Prefer/Share Immutable Example Friday, August 10, 12
- 38. Levels of Testing Friday, August 10, 12
- 39. Levels of Testing Integration Friday, August 10, 12
- 40. Levels of Testing Integration Functional Friday, August 10, 12
- 41. Levels of Testing Integration Functional Unit Friday, August 10, 12
- 42. Levels of Testing Friday, August 10, 12
- 43. Levels of Testing • Integration Testing Friday, August 10, 12
- 44. Levels of Testing • Integration Testing • End-to-End Friday, August 10, 12
- 45. Levels of Testing • Integration Testing • End-to-End • Provide predefined inputs Friday, August 10, 12
- 46. Levels of Testing • Integration Testing • End-to-End • Provide predefined inputs • Verify outputs Friday, August 10, 12
- 47. Levels of Testing • Integration Testing • End-to-End • Provide predefined inputs • Verify outputs • Mock as little as possible Friday, August 10, 12
- 48. Integration Testing Tools for Telephony Friday, August 10, 12
- 49. Integration Testing Tools for Telephony • sipp: sipp.sourceforge.net Friday, August 10, 12
- 50. Integration Testing Tools for Telephony • sipp: sipp.sourceforge.net • Loadbot: github.com/mojolingo/ahn-loadbot Friday, 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-voip Friday, August 10, 12
- 52. Functional Testing Friday, August 10, 12
- 53. Functional Testing • Test just one unit in isolation Friday, August 10, 12
- 54. Functional Testing • Test just one unit in isolation • Typical unit is a single class Friday, 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 state Friday, August 10, 12
- 56. Unit Testing Friday, August 10, 12
- 57. Unit Testing • Most common form of testing Friday, August 10, 12
- 58. Unit Testing • Most common form of testing • Test that a given unit (typically: method) behaves the way you expect Friday, 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 inputs Friday, 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 inputs Friday, 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 Conditions Friday, August 10, 12
- 63. Unit Testing Example Friday, August 10, 12
- 64. Unit Testing Example Friday, August 10, 12
- 65. Testing Concurrency Friday, August 10, 12
- 66. Testing Concurrency • Design with a concurrency model or library Friday, August 10, 12
- 67. Testing Concurrency • Design with a concurrency model or library • Celluloid, EventMachine Friday, August 10, 12
- 68. Testing Concurrency • Design with a concurrency model or library • Celluloid, EventMachine • Use State Machines to guarantee sequence Friday, 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 mocks Friday, 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 timeout Friday, August 10, 12
- 71. Testing Concurrency https://github.com/benlangfeld/countdownlatch Friday, August 10, 12
- 72. Testing Concurrency https://github.com/benlangfeld/countdownlatch Friday, 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 @benlangfeld Friday, August 10, 12