<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    comments inlined<br>
    <br>
    <div class="moz-cite-prefix">Le 1/27/2016 11:53 AM, Mickael Istria a
      écrit :<br>
    </div>
    <blockquote cite="mid:56A8A1BD.6050908@redhat.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 01/27/2016 11:16 AM, Aurelien
        Pupier wrote:<br>
      </div>
      <blockquote cite="mid:56A898F3.9070408@redhat.com" type="cite">About

        using fragments, the only drawback I'm aware of is that one
        cannot add a dependency to a fragment from their plugin. So it's
        not possible for other tests to reuse some logic that is inside
        a fragment. In the spirit of "treating tests as 1st class
        citizen", I believe it's generally better to allow composition
        of test bundles and to make them regular bundles.<br>
        <br>
        If reusable, the logic can be moved to a dedicated utility test
        plugin.<br>
      </blockquote>
      Yes, but it requires an effort in moving the code to the right
      plugin or turning fragment into a bundle everytime one identifies
      something to reuse; whereas using bundles only doesn't require any
      effort from the "producer" side.<br>
    </blockquote>
    <br>
    Considering this code as first citizen, it seems to me an acceptable
    effort ;-)<br>
    <br>
    <blockquote cite="mid:56A8A1BD.6050908@redhat.com" type="cite"> <br>
      <blockquote cite="mid:56A898F3.9070408@redhat.com" type="cite">On
        the other hand, some integration tests should be able to detect
        that.<br>
      </blockquote>
      That would require writing some additional integration tests,
      whereas the current approach to run "unit" tests inside a
      workbench provide that verification without additional thing to
      write.<br>
      <br>
      <blockquote cite="mid:56A898F3.9070408@redhat.com" type="cite">
        <blockquote cite="mid:56A89139.2040308@redhat.com" type="cite">
          The QE people could tell you their opinion on what's more
          important between fast tests, and longer tests that are closer
          from production.<br>
          I guess it all depends, as always: we could imagine the unit
          test running in plain Java to verify only their logic, but it
          shouldn't become a replacement to some integration test to
          verify that the logic also works in the right context.<br>
        </blockquote>
        Not planned to have them as a replacement. I already created the
        structure to write also higher integration tests.<br>
      </blockquote>
      If, during automated tests/build, you run both unit tests and then
      start a workbench to run integration tests, then you pay the price
      of the workbench startup anyway. So why not running those unit
      tests in the workbench?<br>
    </blockquote>
    <br>
    Because my issue is not the build. It is my development environment.<br>
    <br>
    <blockquote cite="mid:56A8A1BD.6050908@redhat.com" type="cite"> <br>
      <blockquote cite="mid:56A898F3.9070408@redhat.com" type="cite">When

        running locally, I may want to run only unit tests first. 
        Without launching the OSGi platform it will be faster. It will
        also allow to use some tools such as Infinitest to have
        continuous feedback while developing.<br>
      </blockquote>
      I don't know much of Infinitest, but I believe it doesn't rely on
      how Maven runs tests. Eclipse already provide the ability to run a
      test class in a bundle in plain Java without starting the
      workbench; it's "Run As &gt; JUnit Test" instead of "Run As &gt;
      JUnit Plugin Test". I guess Infinitest can rely on that, can't it?<br>
    </blockquote>
    Yes Infinitest can rely on it but it means that you are able to
    launch as "JUnit test" and so not starting the workbench.<br>
    <br>
    <blockquote cite="mid:56A8A1BD.6050908@redhat.com" type="cite"> <br>
      Just to be clear, I'm not saying it's wrong to change that; I'm
      more wonderint how much profitable is it, what changing test
      structure would provide better than the current one does. The
      Infinitest story seems the only one "worth it" IMO, and it doesn't
      seem to be correlated to tycho-surefire vs maven-surefire.<br>
    </blockquote>
    <br>
    InfiniTest or only launching test of a single plugin very fast (less
    than a second versus tens seconds) it is the difference between
    keeping concentrated on the task and have our brain switching to
    another idea.<br>
    It seems to me that only tests launched with surefire will be able
    and ensured - to run with Junit test.<br>
    <br>
    <blockquote cite="mid:56A8A1BD.6050908@redhat.com" type="cite">
      <div class="moz-signature">-- <br>
        Mickael Istria<br>
        Eclipse developer at <a moz-do-not-send="true"
          href="http://www.jboss.org/tools">JBoss, by Red Hat</a><br>
        <a moz-do-not-send="true"
          href="http://mickaelistria.wordpress.com">My blog</a> - <a
          moz-do-not-send="true" href="http://twitter.com/mickaelistria">My
          Tweets</a></div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
jbosstools-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Aurelien Pupier
Senior Software Engineer in JBoss Fuse Tooling Team
@apupier</pre>
  </body>
</html>