<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    I think the main problem is that the goals of each module are
    undocumented.<br>
    <br>
    On 06/10/2011 09:38 AM, Thomas Diesler wrote:
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <tt>Folks,<br>
        <br>
        the current state is<br>
        <br>
        + demos<br>
      </tt></blockquote>
    Targeted at users.<br>
    For use in documentation.<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &nbsp;
        + api<br>
      </tt></blockquote>
    Using JBoss API.<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &nbsp;
        + internals<br>
      </tt></blockquote>
    (Bogus)<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &nbsp;
        + legacy<br>
      </tt></blockquote>
    (Bogus)<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &nbsp;
        + spec<br>
      </tt></blockquote>
    Using spec API.<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> +
        testsuite<br>
      </tt><tt>&nbsp; + api<br>
      </tt></blockquote>
    Targeted at users.<br>
    More extensive JBoss API testing.<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> </tt><tt>&nbsp;
        + benchmark<br>
        &nbsp; + domain <br>
        &nbsp; + integration<br>
      </tt></blockquote>
    Targeted at us.<br>
    Anything is allowed in the integration tests, so you'll find me
    doing stuff which is not allowed by spec or even advised to users.<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &nbsp;
        + smoke<br>
      </tt></blockquote>
    Targeted at us.<br>
    Anything is allowed.<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &nbsp;
        + spec <br>
      </tt></blockquote>
    Targeted at users.<br>
    More extensive spec API testing.<br>
    <br>
    The demos should be run during a testsuite run. Relying on some sort
    of re-usage in smoke is not enough. Re-using bits in
    integration/smoke should not be an issue.<br>
    <br>
    Last but not least, all tests must be documented.<br>
    A failing undocumented test is allowed to be deleted on the spot.<br>
    <br>
    Carlo<br>
    <blockquote cite="mid:4DF1C9EB.1030205@jboss.com" type="cite"><tt> &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>&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
          moz-do-not-send="true"
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>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
jboss-as7-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>