<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello Mickael,<br>
    <br>
    <div class="moz-cite-prefix">Le 1/27/2016 10:43 AM, Mickael Istria a
      écrit :<br>
    </div>
    <blockquote cite="mid:56A89139.2040308@redhat.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 01/27/2016 10:28 AM, Aurelien
        Pupier wrote:<br>
      </div>
      <blockquote cite="mid:56A88DD9.9030802@redhat.com" type="cite">
        <pre wrap="">Hi,</pre>
      </blockquote>
      Hi Aurelien!<br>
      <blockquote cite="mid:56A88DD9.9030802@redhat.com" type="cite">
        <pre wrap="">Did I misunderstood something?
Are there counterpoints to use fragments and maven-surefire-plugin?
Are there other examples which are matching more closely to my usecase 
in jboss tools codebase?</pre>
      </blockquote>
      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>
    </blockquote>
    <br>
    If reusable, the logic can be moved to a dedicated utility test
    plugin.<br>
    <br>
    <blockquote cite="mid:56A89139.2040308@redhat.com" type="cite"> <br>
      About maven-surefire (plain Java) vs tycho-surefire
      (OSGi/Eclipse), so far, we do not test the code of JBoss Tools
      outside of the "Eclipse" context. We can debate about the meaning
      of "unit tests", but what you see can be seen as "unit tests
      running in integration context". Our experience with some other
      parts of JBoss Tools have been that the difference of behavior
      between inside or outside of Eclipse can be important. So our
      policy has been so far to test everything with
      tycho-surefire-plugin to make sure what we're testing isn't too
      far from what will actually happen in production.<br>
    </blockquote>
    <br>
    important difference of behavior which can be important is a good
    argument. On the other hand, some integration tests should be able
    to detect that.<br>
    <br>
    <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>
    <br>
    <blockquote cite="mid:56A89139.2040308@redhat.com" type="cite"> I
      would say that as long as Eclipse is the *only* deployment context
      for a piece of code, then starting unit tests inside Eclipse is
      fine. Also, for fast unit tests, then they are neglictable
      compared to starting up the OSGi Platform. So if we want to start
      an OSGi platform anyway for integration tests, it seems simpler to
      run those tests inside that Platform.<br>
      <br>
    </blockquote>
    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>
    <br>
    <br>
    <blockquote cite="mid:56A89139.2040308@redhat.com" type="cite"> HTH<br>
      <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>