<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 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>
<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>
<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 > JUnit Test" instead of "Run As > JUnit Plugin
Test". I guess Infinitest can rely on that, can't it?<br>
<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>
<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>