- . init - To be called in deployment
- .destroy -To be called in un-deployment
- .undispatched -To get set by the dispatch logic when the operation to deliver the message to cannot be figured out.
The above were designed to support different implementations. Given below are the test cases I used for testing them.
Scenario 1: Checking the constructor\destructor implementation 1
Check if constructor and destructor are called at deployment/un-deployment times using the code below;
Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.
Scenario 2: Checking the constructor\destructor implementation 2
Check if constructor and destructor are called at deployment/un-deployment times when following format is used.
Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.
Scenario 3: Checking the constructor\destructor implementation 3
Check if constructor and destructor are called at deployment /un-deployment times when following format is used.
Expected Result :
- At the deployment time the function foo is called and the log should print "init".
- If you re-deploy, since the service is first undeployed and then deployed, the function foo1 is called following function foo. Therefore the log should print 'destroy' first and 'init' following it.
- If u check the WSDL2 of the service both constructor & de-structor operations should appear there.
Scenario 4: Checking the 'undispatcher' implementation 1
Check if 'undispatched' operation is invoked when a non-existing operation is called when 'undispatched' is given in following manner.
Expected Result :
Access an invalid operation like, https://localhost:7443/services/admin/addNamespace/fooklklllklklklk the 'undispatched should be called.
Scenario 5: Checking the 'undispatcher' implementation 2
Check if 'undispatched' operation is invoked when a non-existing operation is called when 'undispatched' is given in following manner.
Expected Result :
Access an invalid operation like, https://localhost:7443/services/admin/addNamespace/fooklklllklklklk the 'undispatched should be called.
