<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <tt>Folks,<br>
      <br>
      the current state is<br>
      <br>
      + demos<br>
      &nbsp; + api<br>
      &nbsp; + internals<br>
      &nbsp; + legacy<br>
      &nbsp; + spec<br>
      + testsuite<br>
    </tt><tt>&nbsp; + api<br>
    </tt><tt>&nbsp; + benchmark<br>
      &nbsp; + domain <br>
      &nbsp; + integration<br>
      &nbsp; + smoke<br>
      &nbsp; + spec <br>
      &nbsp; + stress<br>
      <br>
      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<br>
      <br>
      + (demos removed) <br>
    </tt><tt>+ testsuite<br>
    </tt><tt></tt><tt>&nbsp; + benchmark<br>
      &nbsp; + domain <br>
      &nbsp; + integration<br>
      &nbsp; + smoke<br>
      &nbsp; + stress<br>
      <br>
      #1 demos removed<br>
      <br>
      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.<br>
      <br>
      #2 Collapse testsuite api+spec into integration<br>
      <br>
      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. </tt><tt>Test cases should be
      organised in packages according to their functional area. There
      may be test packages that reference jiras (e.g. <a
href="https://github.com/tdiesler/jboss-as/tree/master/testsuite/integration/src/test/java/org/jboss/as/testsuite/integration/as835">as835</a>).<br>
      <br>
      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.<br>
      <br>
      cheers<br>
      -thomas<br>
    </tt><br>
    <tt><br>
    </tt><br>
    <pre class="moz-signature" cols="72">-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 
</pre>
  </body>
</html>