<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <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>
    <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>
    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>
    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>
    HTH<br>
    <div class="moz-signature">-- <br>
      Mickael Istria<br>
      Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
        by Red Hat</a><br>
      <a href="http://mickaelistria.wordpress.com">My blog</a> - <a
        href="http://twitter.com/mickaelistria">My Tweets</a></div>
  </body>
</html>