I am probably stating the obvious, this needs to be explained in the wiki, too, so people
can easily contribute tests.
Great stuff!
On 10/06/2011 10:38, Thomas Diesler wrote:
Folks,
the current state is
+ demos
+ api
+ internals
+ legacy
+ spec
+ testsuite
+ api
+ benchmark
+ domain
+ integration
+ smoke
+ spec
+ stress
some of these modules are empty. It is hard to find the "right location" for
new tests. The
demos are not self verifying. Instead I propose a simplified structure like this
+ (demos removed)
+ testsuite
+ benchmark
+ domain
+ integration
+ smoke
+ stress
#1 demos removed
The artefacts in the various demos modules are currently reused by testsuite modules
(mainly
smoke). demos are collapsed into smoke. I believe a well documented smoke testsuite can
serve the purpose of demos and be a standalone deliverable. To be standalone you need to
add
a mvn repository entry to smoke/pom.xml. Users can download this as a binary and run
'mvn
test' on it. Test cases should be organised in packages according to their functional
area.
It is guaranteed that the demos work because the smoke tests run on every build. Smoke
tests
should be well documented.
#2 Collapse testsuite api+spec into integration
The integration testsuite should only have dependencies on spec and api modules. Where
this
is not the case (i.e. a test depends on internal impl) the dependency could be flagged
and
an api module could be made available. Test cases should be organised in packages
according
to their functional area. There may be test packages that reference jiras (e.g. as835
<
https://github.com/tdiesler/jboss-as/tree/master/testsuite/integration/sr...>).
The main motivation is, that it is intuitively clear where to put a test. Even more
importantly, where to look for already existing test coverage.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx