http://shining.isti.cnr.it/WEBPAPER/BMS_ASSE07.pdf
3 Testing Orchestrations
This section discusses the possibilities of performing testing over web service
compositions speci¯ed with orchestrations. We advocate the two well-known
levels of testing: unit and integration. The remaining of this section assumes
that no information about the behaviour of the partners is available (i.e., there
is no de¯nition of the choreography of the composition).
3.1 Unit testing
We recall that unit testing is intended to ¯nd bugs on the implementation of a
particular unit (or basic component), and it is performed after the unit has been
implemented. There are two main approaches for testing units: (i) speci¯cation-
based or black-box testing, in which test cases are generated from the speci¯-
cation of the unit without any knowledge about its implementation, and (ii)
implementation-based or white-box testing, in which test cases are selected by
taking advantage of the actual code that implements the speci¯cation.
An orchestrator is a program (or code) that de¯nes the behaviour of a particu-
lar partner, hence, it can be seen just as unit of code. Therefore, any orchestrator
can be taken as a unit. Moreover, if the orchestration is considered just as the
speci¯cation of the composite service then the test suite generated from such
speci¯cation is part of the black-box unit testing plan. This is case when the or-
chestration is actually coded in a language di®erent from the speci¯cation. For
instance, a bpel speci¯cation coded as a Java program. However, since orches-
trations are executable speci¯cations, they can be considered as the actual code
of the services, e.g., a bpel speci¯cation is a piece of code that can be executed
by any bpel engine. In this case, the activity of generating test cases from the
orchestrator is white-box testing, but what we actually test is the speci¯cation,
since we assume the implementation of the orchestration engine to be correct.
In other words, we assume that the software that will execute our speci¯cation
is correct and, hence, that the execution of a correct speci¯cation produces the
correct behaviour. This contrasts with the ¯rst case, in which we actually test
the implementation by assuming the speci¯cation to be correct. We remark that
testing orchestrations is two-fold:
{ Functional black-box testing of implementations: when the orchestrator is
being implemented in a language di®erent from the speci¯cation language.
{ Functional white-box testing of the speci¯cation: when the description of the
orchestrator coincides with its implementation.
Test case generation Test case generation from orchestration can be done
by applying the principles introduced by white-box testing of code, particularly,
test generation from control and data °ow abstractions of the code, as described
6
Receive : sendData(BP;W;BS)
invoke : ans := subscribed(P)
if ans = ok
then
else
flow reply Not subscribed
invoke : ans := fwd(BP;W;BS) invoke : ans := account(P; now)
reply processing
3 Testing Orchestrations
This section discusses the possibilities of performing testing over web service
compositions speci¯ed with orchestrations. We advocate the two well-known
levels of testing: unit and integration. The remaining of this section assumes
that no information about the behaviour of the partners is available (i.e., there
is no de¯nition of the choreography of the composition).
3.1 Unit testing
We recall that unit testing is intended to ¯nd bugs on the implementation of a
particular unit (or basic component), and it is performed after the unit has been
implemented. There are two main approaches for testing units: (i) speci¯cation-
based or black-box testing, in which test cases are generated from the speci¯-
cation of the unit without any knowledge about its implementation, and (ii)
implementation-based or white-box testing, in which test cases are selected by
taking advantage of the actual code that implements the speci¯cation.
An orchestrator is a program (or code) that de¯nes the behaviour of a particu-
lar partner, hence, it can be seen just as unit of code. Therefore, any orchestrator
can be taken as a unit. Moreover, if the orchestration is considered just as the
speci¯cation of the composite service then the test suite generated from such
speci¯cation is part of the black-box unit testing plan. This is case when the or-
chestration is actually coded in a language di®erent from the speci¯cation. For
instance, a bpel speci¯cation coded as a Java program. However, since orches-
trations are executable speci¯cations, they can be considered as the actual code
of the services, e.g., a bpel speci¯cation is a piece of code that can be executed
by any bpel engine. In this case, the activity of generating test cases from the
orchestrator is white-box testing, but what we actually test is the speci¯cation,
since we assume the implementation of the orchestration engine to be correct.
In other words, we assume that the software that will execute our speci¯cation
is correct and, hence, that the execution of a correct speci¯cation produces the
correct behaviour. This contrasts with the ¯rst case, in which we actually test
the implementation by assuming the speci¯cation to be correct. We remark that
testing orchestrations is two-fold:
{ Functional black-box testing of implementations: when the orchestrator is
being implemented in a language di®erent from the speci¯cation language.
{ Functional white-box testing of the speci¯cation: when the description of the
orchestrator coincides with its implementation.
Test case generation Test case generation from orchestration can be done
by applying the principles introduced by white-box testing of code, particularly,
test generation from control and data °ow abstractions of the code, as described
6
Receive : sendData(BP;W;BS)
invoke : ans := subscribed(P)
if ans = ok
then
else
flow reply Not subscribed
invoke : ans := fwd(BP;W;BS) invoke : ans := account(P; now)
reply processing
No comments:
Post a Comment