<div dir="ltr">Hi everybody,<br><br>I wake up this thread because following this discussion and several point to point discussions, I gave a presentation @ EclipseCon France about the importance of &quot;unit tests which are not launching the Workbench or an OSGi platform&quot;.<br><br>Here is the recording: <a href="https://www.youtube.com/watch?v=IGkFy2H-d60&amp;index=33&amp;list=PLy7t4z5SYNaRJff0KBMbubOaj8gevvML4">https://www.youtube.com/watch?v=IGkFy2H-d60&amp;index=33&amp;list=PLy7t4z5SYNaRJff0KBMbubOaj8gevvML4</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 7:43 PM, Mickael Istria <span dir="ltr">&lt;<a href="mailto:mistria@redhat.com" target="_blank">mistria@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div>On 02/01/2016 07:25 PM, Aurelien Pupier
      wrote:<br>
    </div>
    </span><blockquote type="cite"><span class="">Le
      1/27/2016 11:53 AM, Mickael Istria a écrit :<br>
      </span><span class=""><blockquote type="cite">
        
        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&#39;t require any effort from the &quot;producer&quot; side.<br>
      </blockquote>
      Considering this code as first citizen, it seems to me an
      acceptable effort ;-)<br>
    </span></blockquote>
    Do you put your actual &quot;first citizen&quot; business code into fragments
    too?<span class=""><br>
    <br>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote 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&#39;t know much of Infinitest, but I believe it doesn&#39;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&#39;s &quot;Run As &gt; JUnit Test&quot; instead of &quot;Run As &gt;
        JUnit Plugin Test&quot;. I guess Infinitest can rely on that, can&#39;t
        it?<br>
      </blockquote>
      Yes Infinitest can rely on it but it means that you are able to
      launch as &quot;JUnit test&quot; and so not starting the workbench.<br>
    </blockquote></span>
    Yes, and if you&#39;re able to do it from the Eclipse IDE for your test
    class, isn&#39;t it enough?<br>
    So in your IDE, you can run &quot;unit tests&quot; without the
    workbench/Platform actually started, just the API available; and
    with Maven and tycho-surefire-plugin, you get a Platform/workbench
    started, like it will happen in real-life, to find real issues that
    wouldn&#39;t happen in plain Java environment.<span class=""><br>
    <br>
    <blockquote type="cite">
      <blockquote type="cite">
        Just to be clear, I&#39;m not saying it&#39;s wrong to change that; I&#39;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 &quot;worth it&quot; IMO, and it
        doesn&#39;t seem to be correlated to tycho-surefire vs
        maven-surefire.<br>
      </blockquote>
      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>
    </blockquote></span>
    I believe this sentence illustrates our divergence: you mainly think
    about tests as a tool for the developer, and they have to be fast
    for the developer to use them. That&#39;s right.<br>
    I see them as an armor for the application, I want them to find as
    many bugs possible in the actual environment where the code will
    actually run, and if it has a cost for the developer, so be it, as
    long as tests are still run and checked by continuous integration.
    That&#39;s right too.<br>
    <br>
    Overall, both are right and useful. Depending on the test, you might
    want one or the other.<br>
    <br>
    What&#39;s possible and that seems like the best thing to me is to have
    the unit-tests in a bundle that run fast with maven-surefire-plugin,
    and have integration tests in another bundle also running the
    unit-test suite (+ some other tests) with tycho-surefire-plugin. So
    you get the best of both: unit tests are run fast and keep running
    fast because they are automatically tested using plain JUnit and
    maven-surefire-plugin; and you also have them running as part of the
    integration tests to also detect bugs that depend on the Eclipse
    runtime mechanism.<br>
    WDYT?<span class=""><br>
    <div>-- <br>
      Mickael Istria<br>
      Eclipse developer at <a href="http://www.jboss.org/tools" target="_blank">JBoss,
        by Red Hat</a><br>
      <a href="http://mickaelistria.wordpress.com" target="_blank">My blog</a> - <a href="http://twitter.com/mickaelistria" target="_blank">My Tweets</a></div>
  </span></div>

<br>_______________________________________________<br>
jbosstools-dev mailing list<br>
<a href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Aurelien Pupier<div>Senior Software Engineer in JBoss Fuse Tooling team</div><div>@apupier</div></div></div>
</div>