Testing VoIP calls

[Miguel Casal Guillán]

Hi all!

I've been discussing with a mate in the office on how to apply the GOOS approach (mocks and outside-in) to a calling/messaging application that he's writing in Swift.

What would be the simplest end to end test? Maybe a call without voice? Just sending the appropriate signals and receive some kind of ACK to know if the call was stablished. By the way, we are learning about VoIP technologies because our company makes money on these technologies and we have our own SIP infrastructure.

Right now he has written some unit tests for the adapter classes that convert application data in XML suitable for the library that actually makes the call, but for testing the call itself (to me that is the acceptance test) he has to load the application in a real device.

Thanks!

[Steven Solomon]

Hey Miguel,

I imagine that you would have a FakeVOIPServer locally that would conform to the same interface as the real one but exposes endpoints where you can query the bytes sent to it. There would also be a set of contract tests that both the fake and real server pass, so you can have confidence that they are behaviorally equivalent to one another.

This strategy is very similar to what is demonstrated with the FakeXMPServer in the book.

Does that make sense?

Thanks 

Steve

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Freeman]

How familiar are you with the environment? It's possible that the best thing you could do now is some end-to-end spikes to explore the landscape. Once you have a better view, you could go back and implement test-driven (remembering to throw away the spike!).

S

[James Richardson]

I would have the end-to-end test set up a SIP endpoint, so the test case
is called by the application you're testing.

As you have all the infrastructure in-house this should be easy.

Something like:

SIPEndpoint endpoint =
internalInfrastructure.createRandomDialledNumber()
assertThat(endpoint.incomingCallCount(), equalTo(0));

DialledNumber dn = endpoint.dialledNumber();
// fiddle with application you're testing, you can use the DN you got
here...

assertWithinTimeout(seconds(1), endpoint.incomingCallCount(),
equalTo(1));

endpoint.release();


where SIPEndpoint and DialledNumber are just some classes you write in
your application to help you deal with the infrastructure....


Hope I understood you correctly.

James

[Miguel Casal Guillán]

My friend is reading the book right now. Let's see when he reaches that part if it's exactly what he wants.

Thx.

[Miguel Casal Guillán]

Well, is our environment and we can play with it as long as we have time to invest on this. Right now we kind of test the calls in a manual way but I imagine it would be possible to arrange some tests at least just for knowing if a call can be stablished. Other params related to QoS have to be extracted from database or CDRs.

[Miguel Casal Guillán]

We've been thinking about how to test this stuff and we came up with several ideas. Basically looking for side effects after making the call to judge if it was ok or not. For example, trigger a call and after some timeout go to the database where we log info about the calls and look for that particular one. If we had a better setup we could have a specific SIP proxy that does some extra logging before handling the call in order to help us testing, maybe exposing that data through a simple API. Even more fancy stuff can be analyzed about a call just connecting to some monitor tools we are currently using.

The good thing about those tests, even if we need time to build them properly, is that we could run them several times a day and not only when releasing. It would be another defense line to notice if the client apps are having problems...

[Steve Freeman]

This sounds promising and covers an important point, that infrastructure for testing often proves useful in production.

A couple of suggestions. Is there anywhere you can put some event distribution so you can get notified of the change? Otherwise, perhaps a combination of rapid polling and a timeout. You want to avoid fixed waits because they slow down successful test runs.

And a layer of indirection to expose just what you need is nearly always a good idea.

S

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.