[GOOS] 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

Post by 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!
--
---
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
For more options, visit https://groups.google.com/d/optout.

[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.


El domingo, 20 de noviembre de 2016, 19:55:02 (UTC+1), Steven Solomon

Post by 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
On Sun, Nov 20, 2016 at 1:14 PM, Miguel Casal Guillán <

Post by 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!
--
---
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
<javascript:>.
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

Post by 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.

[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.


El domingo, 20 de noviembre de 2016, 20:03:53 (UTC+1), Steve Freeman

Post by 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

Post by 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.

Post by Miguel Casal Guillán
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.

Post by Miguel Casal Guillán
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.

[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]

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...


El domingo, 20 de noviembre de 2016, 19:14:41 (UTC+1), Miguel Casal Guillán

Post by 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!

[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

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...
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!
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
For more options, visit https://groups.google.com/d/optout.