07.01.2013 Views

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

470 George D<strong>in</strong><br />

16.3.1 Test Build<strong>in</strong>g Blocks<br />

The top-level build<strong>in</strong>g-block of TTCN-3 is the module. A module conta<strong>in</strong>s all<br />

other TTCN-3 constructs, but cannot conta<strong>in</strong> sub-modules. It can import completely<br />

or partially the def<strong>in</strong>itions of other modules. The modules are def<strong>in</strong>ed<br />

with the keyword module.<br />

In our web service example we def<strong>in</strong>e the WebServiceModule. This module<br />

imports all def<strong>in</strong>itions from UtilsModule. The module parameter serviceId is a<br />

parameter which can be configured by the tester at execution and which <strong>in</strong>dicates<br />

the service to be tested (serviceId takes the default value ”0”.<br />

module WebServiceModule {<br />

}<br />

// imports some util functions from another module<br />

import from UtilsModule all;<br />

// module parameter -> the id of the tested service<br />

modulepar { <strong>in</strong>teger serviceId := 0; };<br />

// other def<strong>in</strong>itions ...<br />

The modules can be parameterized; parameters are sets of values that are<br />

supplied by the test environment at runtime. A parameter can be <strong>in</strong>itialized with<br />

a default value which can be changed, later, at execution time.<br />

A module has two parts: the module def<strong>in</strong>ition part and the module control<br />

part. The def<strong>in</strong>ition part conta<strong>in</strong>s the data def<strong>in</strong>ed by that module (functions,<br />

test cases, components, types, templates), which can be used everywhere <strong>in</strong> the<br />

module and can be imported from other modules. The control part is the ma<strong>in</strong><br />

program of the module, which describes the execution sequence of test cases or<br />

functions. It can access the verdicts delivered by test cases and, accord<strong>in</strong>g to<br />

them, can decide the next steps of execution.<br />

We def<strong>in</strong>e, <strong>in</strong> our example, a control part which tests if a D<strong>in</strong>o entry exists <strong>in</strong><br />

the web service database. If the verdict is fail, which means that the entry does<br />

not exist, another test case is started. The float values <strong>in</strong> the execute commands<br />

represent the maximal time the execution environment must wait until the test<br />

cases f<strong>in</strong>ish. If the test case does not f<strong>in</strong>ish <strong>in</strong> the <strong>in</strong>dicated period of time, the<br />

test case is stopped with the verdict <strong>in</strong>conc.<br />

// CONTROL PART<br />

control {<br />

verdicttype v;<br />

v := execute(SeparateSearchFunctionalTest(serviceId), 1.0);<br />

if(v == fail){<br />

v := execute(SeparateAddFunctionalTest(serviceId), 2.0);<br />

}<br />

}

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!