Creating JUnit test cases for classes of the SIP Communicator.


#1

Is it possible for new graduates to get involved in this project?

Of course Muzammil.

I'm replying to the list as everyone could contribute here and getting as many unit tests as possible is crucial for the project.

Now there are two major kinds of tests that one could add.

The simplest ones would be to just get a class and right a JUnit test case for it. This is not going to always be trivial. To test some of the methods in the SIP pacakge classes for example, you'd need to provide a dummy successor of SipManager.

Take the processOK message in the Register processing for example. You'd need to hand it a client transaction and an OK response. You can forge those easily using the jain-sip ri. Then u need sth like this

SipManager localManager = new SipManager()
{
  processUnregistered(...)
  {
    ... put ur assert statements here
  }
  
  processRegistered(...)
  {
    ... put ur assert statements here
  }
}

The second line of testing that we'll need would be more like functional tests. This one is more complicated but could prove to be very important and effective for the project.It consists in the following:

A test case would have to launch SIPCommunicator make it register against a dummy registrar (a junit test case on the local machine ) that would analyse the register request for correctness and reply with a fixed response. The sip-communicator side test would then test whether the application has responded appropriately.

Then we should have the sip-communicator make a call against another junit test which would first send a busy response then accept the second call and every time the client side would verify that the sip-communicator has reacted properly.

I believe this could be very very effective in the long term. We should think about a more general architecture of a test framework that does this.

_ANYONE_ is welcome to comment and contribute!

Cheers
Emil


#2

Hi there..
I was working with sip-comm for quite a time. Great work Emil!

I was playing around with nist sip stack and sip-comm. But it seems like
different sip service providers may come up with different set of
requirements set up in the header and some other requirements that might
need tweaking of the stack aswell.

The scenario Emil described is very significant and we may end up making a
set of rules of any dialog which would be in certain 'contexts'. So- the
response giving machanism may consult those rules which may come as a
defined state at a higher level.

So- I believe it's not a bad time to think about a tool which would analyze
any sip request-response and will interact as specified being a SIP UA. And
I believe sip-comm is a real active project and ppl will contribute.

Anyways- that's all my perspective.

  -- Reza

···

----- Original Message -----

From: "Emil Ivov" <emil_ivov@yahoo.com>

To: "Muzammil Hussain" <muzammil@alumni.usc.edu>
Cc: <emcho@dev.java.net>; <dev@sip-communicator.dev.java.net>
Sent: Friday, August 27, 2004 8:15 AM
Subject: [sip-comm-dev] Re: Creating JUnit test cases for classes of the SIP
Communicator.

> Is it possible for new graduates to get involved in this project?

Of course Muzammil.

I'm replying to the list as everyone could contribute here and getting
as many unit tests as possible is crucial for the project.

Now there are two major kinds of tests that one could add.

The simplest ones would be to just get a class and right a JUnit test
case for it. This is not going to always be trivial. To test some of the
methods in the SIP pacakge classes for example, you'd need to provide a
dummy successor of SipManager.

Take the processOK message in the Register processing for example. You'd
need to hand it a client transaction and an OK response. You can forge
those easily using the jain-sip ri. Then u need sth like this

SipManager localManager = new SipManager()
{
processUnregistered(...)
{
... put ur assert statements here
}

processRegistered(...)
{
... put ur assert statements here
}
}

The second line of testing that we'll need would be more like functional
tests. This one is more complicated but could prove to be very important
and effective for the project.It consists in the following:

A test case would have to launch SIPCommunicator make it register
against a dummy registrar (a junit test case on the local machine ) that
would analyse the register request for correctness and reply with a
fixed response. The sip-communicator side test would then test whether
the application has responded appropriately.

Then we should have the sip-communicator make a call against another
junit test which would first send a busy response then accept the second
call and every time the client side would verify that the
sip-communicator has reacted properly.

I believe this could be very very effective in the long term. We should
think about a more general architecture of a test framework that does

this.

_ANYONE_ is welcome to comment and contribute!

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Nice reflection Reza! Yes you are right!

Actually there is a responder tool from NIST that works with the previos version of the stack. It does some pattern matching upon incoming requests and sends a response accordingly. It might be a bit too heavy for us but i like the idea.
There is a pattern matching functionality in the jain-sip stack (nist-sip-1.2). Ranga promised to put up a basic example and upload it on cvs so we might start from there and implement a set of abstract classes that do pattern matching, junit asserts and responding. We should keep the thing as simple as possible. It is supposed to be testing the SIP Communitor for bugs and we should keep it real flat and obvious to avoid bugs and not try to produce an architectural masterpiece.

I'll try and put up some examples but not before a week cos I'll be out in vacation for a week. So if anyone would like to add some code - go ahead - i'll take it into account

Cheers
Emil

Reza Khan wrote:

···

Hi there..
I was working with sip-comm for quite a time. Great work Emil!

I was playing around with nist sip stack and sip-comm. But it seems like
different sip service providers may come up with different set of
requirements set up in the header and some other requirements that might
need tweaking of the stack aswell.

The scenario Emil described is very significant and we may end up making a
set of rules of any dialog which would be in certain 'contexts'. So- the
response giving machanism may consult those rules which may come as a
defined state at a higher level.

So- I believe it's not a bad time to think about a tool which would analyze
any sip request-response and will interact as specified being a SIP UA. And
I believe sip-comm is a real active project and ppl will contribute.

Anyways- that's all my perspective.

  -- Reza

----- Original Message ----- From: "Emil Ivov" <emil_ivov@yahoo.com>
To: "Muzammil Hussain" <muzammil@alumni.usc.edu>
Cc: <emcho@dev.java.net>; <dev@sip-communicator.dev.java.net>
Sent: Friday, August 27, 2004 8:15 AM
Subject: [sip-comm-dev] Re: Creating JUnit test cases for classes of the SIP
Communicator.

Is it possible for new graduates to get involved in this project?

Of course Muzammil.

I'm replying to the list as everyone could contribute here and getting
as many unit tests as possible is crucial for the project.

Now there are two major kinds of tests that one could add.

The simplest ones would be to just get a class and right a JUnit test
case for it. This is not going to always be trivial. To test some of the
methods in the SIP pacakge classes for example, you'd need to provide a
dummy successor of SipManager.

Take the processOK message in the Register processing for example. You'd
need to hand it a client transaction and an OK response. You can forge
those easily using the jain-sip ri. Then u need sth like this

SipManager localManager = new SipManager()
{
processUnregistered(...)
{
... put ur assert statements here
}

processRegistered(...)
{
... put ur assert statements here
}

The second line of testing that we'll need would be more like functional
tests. This one is more complicated but could prove to be very important
and effective for the project.It consists in the following:

A test case would have to launch SIPCommunicator make it register
against a dummy registrar (a junit test case on the local machine ) that
would analyse the register request for correctness and reply with a
fixed response. The sip-communicator side test would then test whether
the application has responded appropriately.

Then we should have the sip-communicator make a call against another
junit test which would first send a busy response then accept the second
call and every time the client side would verify that the
sip-communicator has reacted properly.

I believe this could be very very effective in the long term. We should
think about a more general architecture of a test framework that does

this.

_ANYONE_ is welcome to comment and contribute!

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net