tackling testing telephony

Post on 18-Dec-2014

68 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Tackling Testing Telephony presented by Ben Klang, Mojo Lingo, at Lone Star Ruby Conference 2012

TRANSCRIPT

Can You Hear Me Now?

Tackling Testing TelephonyBen Klang

bklang@mojolingo.com

How Telephony Testing Is Different

How Telephony Testing Is Different

•Apps are long-running code

How Telephony Testing Is Different

•Apps are long-running code

• Inputs may be more constrained (DTMF)

How Telephony Testing Is Different

•Apps are long-running code

• Inputs may be more constrained (DTMF)

•Or they may be less constrained (IM, Voice)

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

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)

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

How Telephony Testing Is Familiar

How Telephony Testing Is Familiar

•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake

How Telephony Testing Is Familiar

•Same Tooling: rspec, mocha, cucumber, factory_girl, guard, rcov, rake

•Still draw lines between M, V and C

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

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

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

Philosophy: SRP

Philosophy: SRP

•Single Responsibility Principle

Philosophy: SRP

•Single Responsibility Principle

• If you need to use “and” to describe the purpose of a class, you are probably breaking this rule

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

SRP Example

SRP Example•Class purpose: “To schedule calls and to place them”

SRP Example•Class purpose: “To schedule calls and to place them”

•Testing requires mocking methods within the same class

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

Philosophy: Tell, Don’t Ask

Philosophy: Tell, Don’t Ask

•Tell an object to do its work

Philosophy: Tell, Don’t Ask

•Tell an object to do its work

•Don’t ask for its state then ask it to do something

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

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

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

Philosophy: Prefer/Share Immutable

Philosophy: Prefer/Share Immutable

•Methods should only use passed-in data

Philosophy: Prefer/Share Immutable

•Methods should only use passed-in data

•Avoid instance vars or other shared state

Philosophy: Prefer/Share Immutable

•Methods should only use passed-in data

•Avoid instance vars or other shared state

•Especially helpful with concurrent code

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

Prefer/Share Immutable Example

Prefer/Share Immutable Example

Prefer/Share Immutable Example

Prefer/Share Immutable Example

Levels of Testing

Levels of Testing

Integration

Levels of Testing

Integration

Functional

Levels of Testing

Integration

Functional

Unit

Levels of Testing

Levels of Testing

• Integration Testing

Levels of Testing

• Integration Testing

•End-to-End

Levels of Testing

• Integration Testing

•End-to-End

•Provide predefined inputs

Levels of Testing

• Integration Testing

•End-to-End

•Provide predefined inputs

•Verify outputs

Levels of Testing

• Integration Testing

•End-to-End

•Provide predefined inputs

•Verify outputs

•Mock as little as possible

Integration Testing Tools for Telephony

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

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

• Loadbot:github.com/mojolingo/ahn-loadbot

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

• Loadbot:github.com/mojolingo/ahn-loadbot

• Cucumber-VoIP:github.com/benlangfeld/cucumber-voip

Functional Testing

Functional Testing

•Test just one unit in isolation

Functional Testing

•Test just one unit in isolation

•Typical unit is a single class

Functional Testing

•Test just one unit in isolation

•Typical unit is a single class

•Test function of classbut do not makeassertions about internal state

Unit Testing

Unit Testing

•Most common form of testing

Unit Testing

•Most common form of testing

•Test that a given unit (typically: method) behaves the way you expect

Unit Testing

•Most common form of testing

•Test that a given unit (typically: method) behaves the way you expect

•Make sure to test:

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

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

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

Unit Testing Example

Unit Testing Example

Testing Concurrency

Testing Concurrency

•Design with a concurrency model or library

Testing Concurrency

•Design with a concurrency model or library

•Celluloid, EventMachine

Testing Concurrency

•Design with a concurrency model or library

•Celluloid, EventMachine

•Use State Machines to guarantee sequence

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

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

Testing Concurrency

https://github.com/benlangfeld/countdownlatch

Testing Concurrency

https://github.com/benlangfeld/countdownlatch

Can You Hear Me Now?

Tackling Testing Telephony Ben Klangbklang@mojolingo.com@bklang Github/Twitterspkr8.com/t/12971

Thanks to Ben Langfeld for his assistance with this presentation@benlangfeld

top related