1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!--
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
-->
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii">
<meta http-equiv="Content-Style-Type" content="text/css">
<title>Tuscany SCA Integration Test Databindings</title>
<!-- LINK rel="stylesheet" href="ait.css" type="text/css" -->
<link rel="stylesheet" href="../../css/base.css" type="text/css">
</head>
<body>
<h3>Tuscany SCA Integation Test Databindings </h3>
<h4>Overview</h4>
<p>
This integration test tests the Tuscany SCA databinding implementation by passing various data structures
across various bindings using the supported databindings. There are tests for the individual databindings
which exercise various bindings with the same databinding at client and server ends of each binding. There
is also an integration test which exercises the transformer chains by specifying different databindings at
client and server ends of the binding.
</p>
<p>
In doing this testing it is apparent that there is a lot of repetition in creating client, services, idl and
type for each of the data types for each of the bindings for each of the databindings. To reduce the amount
of effort required to maintain the tests as new types, bindings and databindings are added the test cases
themselves are generated from configuration files.
</p>
<h4>Test Structure</h4>
Databindings/Common - hold files common across all tests <br/>
Databindings/Interop - test the transformer chains with combinations of databindings<br/>
Databindings/sdogen and jaxbgen - test each databindings independently<br/>
<h4>Test Generation</h4>
<p>
To reduce the amount of manual effort involved in building and maintaining tests cases the test cases
themselves are generated at run time using a set of velocity templates. Each test module has a generate.xml
file in the resources/generate directory which tells the generator what to do. The file looks like this.
</p>
<img src="config.png">
<p>
Each <Template> element describes a velocit template to use in the test. The generator process is to expand
each velocity template provided with all of the types specified in the <InputFile> sections.
</p>
<p>
Each <InputFile> element describes a schema file used in the test. It also contains a description of each
data type that will be tested. The generator then arranges for the databinding being tested to generate
appropriate Java classes to represent the type at runtime. The individual databinding tests use the following
flow.
</p>
Create data object at client<br/>
Client passes data object to server<br/>
Server modifies data object<br/>
Server returns modified data object to client<br/>
Client tests that modified data object is as expected<br/>
<p>
Hence the CreateTypeCode, ModifyTypeCode and ResultComparison elements which contain the type specific code
that is used in the tests.
</p>
<h4>The Common Directory</h4>
<p>
The common directory contains the information that is common across all of the tests. This includes the
common velocity templates and the source for the generator that reads the config.xml for each test. Common
also contains all of the data type schema as these are common across all tests. Each test pom is written so
that the contents of the common project are expanded into the tests target directory before the test starts.
In this way all of the common elements are available for the test generation phase and at test runtime.
</p>
<h4>Individual Databinding Tests</h4>
<p>
The individual databinding tests, for example, sdogen and jaxbgen, are mostly empty as their content is
generated at runtime. The configuration and any test specific templates can be found in the resources/generate
directory. Some files are hand crafted for each test and live in their static position in the tests directory
structure.
</p>
<p>
Each test uses the same scenario
</p>
<img src="databinding.png">
<p>
The interface exposed by the greeter service provides a greet method for each data type being tested, for
example,
</p>
<code>
PersonType greetPersonType(PersonType param);<br/>
AttributeComplexType greetAttributeComplexType(AttributeComplexType param);<br/>
AttributeReferenceComplexType greetAttributeReferenceComplexType(AttributeReferenceComplexType param);<br/>
</code>
<p>
These methods are taken from the SDO databinding test and hence PersonType, AttributeComplexType, etc. will
have been generated by the SDO static type generator.
</p>
<p>
Hence this tests a single databinding across a variety of data types and a variety of bindings. New bindings
be tested by extending the composite. Be datatypes can be tested by updating the confix.xml file.
</p>
<h4>Databinding Interoperability Tests</h4>
<p>
This test uses the generated client, services and types from the individual databinding tests. It does not
regenerate them and you will see a dependency in the interop test pom on the other databinding tests. Is also
has some generate elements because the composite file must currently have import statements for all of the
SDO factories required during tested.
</p>
<p>
The scenario used here is,
</p>
<img src="interop.png">
<p>
A chain of components is built up for each binding. Each component, drawn from the the inidividual databinding
tests, tests the full range of datatypes. The client components are designed so that they can be chained together
and so tranformations across different databindings is tests. The service component simply changes the data
content and returns it as before.
</p>
<h4>Building And Running The Tests</h4>
<p>
The tests can be built by doing the following.
</p>
<code>
cd sca/itest/databindings <br/>
mvn
</code>
<p>
The only modification to this process is required if a new input file is added to the tests suite. In this
case you will need to edit the config.xml files as appropriate but run mvn twice. This may sound a little
odd but currently the sdo test uses its pom file to generate the require SDO types. As the test is self
generating the pom file will not be updated to include the new type file until the second time it's run. The
aim is at some point to remove this feature from the pom.
</p>
</body>
</html>
|
