| I want to give you a QVTo test coverage plugin [message #1298699] |
Wed, 16 April 2014 12:41  |
|
In my team we've made a prototype for an Eclipse plugin that displays information on QVTo test coverage. We want to open source it and give it to you, but I'd like some feedback from you about how to do that properly since there are some issues.
Overview:
We assume test cases are run using Java and JUnit. It works by extending the JUnit launch config in Eclipse. After installing the plugin you can select the QVTo test runner instead of the normal JUnit one in the launch config, and it will collect mapping/etc coverage data and display it in a new view afterwards.
Problem:
We patched the QVTo plugin a little (org.eclipse.m2m.qvt.oml), since we had some specific requirements in our team. 1) We added patch from https://bugs.eclipse.org/bugs/show_bug.cgi?id=430677 (which should be included in the next release anyway) and 2) We added a patch which will automatically include a 3rd party decorator for the evaluation visitor if a specific VM arg is set (code attached to this issue). This patch is then included in our update site with a feature patch for the qvto feature.
Solutions:
1. Leave it as is and give you the update site (and source code)
How bad is it that it adds a patch to QVTo? Would you still use it? This is the ideal option for us. I am a little confused about versioning fo the feature patch though (currently our qvto feature patch is set to 3.1.1, since we wanted it higher than the current feature, 3.3.0). Would anything like the second patch be considered to be accepted into QVTo, or are there better ways to achieve this sort of transparent decoratoration?
2. Add a "compatibility" plugin as well and require that you use a special TransformationExecutor class in your test code.
I think this would work, but maybe the first patch is still required (but that's sort of ok since it'll be included in the next release). It's somewhat more work for us since we'd be maintaining two versions of the tool (the one that we use where the decoration happens automatically and the one with compatibility added) and it's just extra classes that we don't need, but if it's the only reasonable way that others might try it, then we'd like to do it.
More than anything, we are looking for feedback on the tool so that it's actually useful for more people than us, so anyone willing to try it would be appreciated! I'll post a link to the tool source code within a couple days (it needs cleanup), but feedback on any of the above is of interest to us.
Thanks!
Chris
[Updated on: Wed, 16 April 2014 12:43] Report message to a moderator |
|
|
| Re: I want to give you a QVTo test coverage plugin [message #1298743 is a reply to message #1298699] |
Wed, 16 April 2014 13:17  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
A test coverage plugin could certainly be useful. In due course it might
migrate to the OCL framework to be more generally useable.
Patches are bad. If you distribute patched versions that conflict with
official Eclipse versions (including future versions) you may run foul
of "Each Contributor must identify itself as the originator of its
Contribution, if any, in a manner that reasonably allows subsequent
Recipients to identify the originator of the Contribution." So don't. It
will end up being a real pain for you and other users.
Generally you want to work really hard to make your changes acceptable
to the committers and where that is not possible, use your ingenuity
with derived classes and selective copies so that your contribution
works with the standard distribution.
Contributions should be via Bugzilla, as with Bug 430677 which has been
committed.
I suggest splitting your contribution into at least two parts.
a) One or more Bugzillas that adjust core QVTo functionality to enable
your contribution to work
b) One or more Bugzillas for your novel contribution.
The M6 API freeze is past. M7 and the feature freeze is approaching
fast, but it may be possible to get the QVTo core changes in for Luna
allowing you to distribute code coverage outside Eclipse. Code coverage
in Eclipse will probably have to wait for Mars.
Regards
Ed Willink
On 16/04/2014 13:41, Christine Gerpheide wrote:
> In my team we've made a prototype for an Eclipse plugin that displays
> information on QVTo test coverage. We want to open source it and give
> it to you, but I'd like some feedback from you about how to do that
> properly since there are some issues.
>
> Overview:
>
> We assume test cases are run using Java and JUnit. It works by
> extending the JUnit launch config in Eclipse. After installing the
> plugin you can select the QVTo test runner instead of the normal JUnit
> one in the launch config, and it will collect mapping/etc coverage
> data and display it in a new view afterwards.
>
> Problem:
>
> We patched the QVTo plugin a little (org.eclipse.m2m.qvt.oml), since
> we had some specific requirements in our team. 1) We added patch from
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=430677 (which should be
> included in the next release anyway) and 2) We added a patch which
> will automatically include a 3rd party decorator for the evaluation
> visitor if a specific VM arg is set (code attached to this issue).
> This patch is then included in our update site with a feature patch
> for the qvto feature.
>
> Solutions:
>
> 1. Leave it as is and give you the update site (and source code)
> How bad is it that it adds a patch to QVTo? Would you still use it?
> This is the ideal option for us. I am a little confused about
> versioning fo the feature patch though (currently our qvto feature
> patch is set to 3.1.1, since we wanted it higher than the current
> feature, 3.3.0). Would anything like the second patch be considered to
> be accepted into QVTo, or are there better ways to achieve this sort
> of transparent decoratoration?
>
> 2. Add a "compatibility" plugin as well and require that you use a
> special TransformationExecutor class in your test code.
> I think this would work, but maybe the first patch is still required
> (but that's sort of ok since it'll be included in the next release).
> It's somewhat more work for us since we'd be maintaining two versions
> of the tool (the one that we use where the decoration happens
> automatically and the one with compatibility added) and it's just
> extra classes that we don't need, but if it's the only reasonable way
> that others might try it, then we'd like to do it.
>
> More than anything, we are looking for feedback on the tool so that
> it's actually useful for more people than us, so anyone willing to try
> it would be appreciated! I'll post a link to the tool source code
> within a couple days (it needs cleanup), but feedback on any of the
> above is of interest to us.
>
> Thanks!
> Chris
|
|
|
|
Powered by
FUDForum. Page generated in 0.01599 seconds
] 
Search
Help
Register
Login
Home
