The basic strategy is fairly simple: figure out how the call flow should work, define the variations, and then code it.
- Define the participants. We usually talk in terms of A, B, and C. As in “A calls B, B rings, B picks up”, etc.
- Define the roles of the participants. In the example above, A would be the originator, B would be the terminator. In a call waiting script, you would define the “controller”.
- Define the “happy path” call flow. This is the sequence of events that occurs in a normal occurrence of this call. Think about what you’re testing, and don’t add extraneous events to the flow — that will come later. In the A-B example above, you’d assume that A wasn’t busy, B didn’t misdial, A actually answered and didn’t have forwarding on. Everything “just works”.
- For each step in the flow, break it down into more and more detail until there is a method on the CallGenerator or PhonePort objects for each action you’ve described. For example, “B detects ringing” corresponds to a method on the PhonePort object.
- Consider some variants — still “happy” path, but variations on the flow in the previous step. This might include B-calls-A, or in a call waiting script, multiple flashes between the two held parties.
- Consider edge cases: what happens to the A-B flow when B is busy? Should this be considered as part of the call waiting script, or maybe we need another script to verify we get a busy tone or even voicemail. In general, most of the ideas in this step will result in a new script.
- Consider some crazy variants. Maybe we’re writing a script to verify that busy tone is generated for incoming calls when the line is busy. “Crazy” might include having D, E, F, G, and H call A all at the same time, each line expecting to hear a busy tone. These will also probably result in new scripts, but if you write the happy path script well, you will be able to reuse it for the crazy script.
Related posts:
