[jbosstools-dev] Eclipse plugins testing structure

[Aurelien Pupier]

Hi,

comments inlined

Le 1/27/2016 11:53 AM, Mickael Istria a écrit :
> On 01/27/2016 11:16 AM, Aurelien Pupier wrote:
>> 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.
>>
>> If reusable, the logic can be moved to a dedicated utility test plugin.
> 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.

Considering this code as first citizen, it seems to me an acceptable 
effort ;-)

>
>> On the other hand, some integration tests should be able to detect that.
> 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.
>
>>> The QE people could tell you their opinion on what's more important 
>>> between fast tests, and longer tests that are closer from production.
>>> 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.
>> Not planned to have them as a replacement. I already created the 
>> structure to write also higher integration tests.
> 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?

Because my issue is not the build. It is my development environment.

>
>> 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.
> 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?
Yes Infinitest can rely on it but it means that you are able to launch 
as "JUnit test" and so not starting the workbench.

>
> 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.

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.
It seems to me that only tests launched with surefire will be able and 
ensured - to run with Junit test.

> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 
Aurelien Pupier
Senior Software Engineer in JBoss Fuse Tooling Team
@apupier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160201/b3448c13/attachment.html