Home » Eclipse Projects » Buckminster dev » Setup / tear down for JUnit plugin tests
| Setup / tear down for JUnit plugin tests [message #499871] |
Tue, 24 November 2009 12:17  |
 Michal Ruzicka
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
Hi,
This is a re-post of my previous post to eclipse.tools.buckminster, as
this newsgroup is probably the more appropriate.
I'm having problems with running JUnit plug-in tests which happen to
need GUI in a headless environment with Buckminster's junit command.
The problem is that there is no X server running at the time when the
framework supposed to execute the tests is launched. This naturally
results in an early exit of the framework before any tests are executed.
I was able to solve the problem for plain (non plug-in) JUnit tests by
starting / stopping Xvfb (a virtual framebuffer X server which runs
entirely in background without any need for real display or input
devices) in @BeforeClass / @AfterClass annotated methods.
This solution unfortunately does not work for the JUnit plug-in tests as
the framework (and GUI) is attempted to be started earlier than the
@BeforeClass / @AfterClass methods from any test class are called.
A working solution would be to add some kind of setup / tear down
functionality to the Buckminster's junit command. I'm willing to
implement it but I'd like to discuss possible options first. So here are
some question for you to comment on:
1) Should the implementation just allow to specify a command to execute
prior to launching the tests, or should it rather require a java class
implementing the setup / tear down functionality.
2) If the class is required, should it implement an interface devised
for the setup / tear down purpose, or should it rather use annotations
(perhaps the JUnit 4 @BeforeClass / @AfterClass annotations)?
3) If the class is required, then specifying it means specifying the
class itself plus the classpath where the class is found. A classpath is
much easier specified in an ant script that on a command line which
leads me to the question: Shouldn't there be a <bukminster.junit> ant
task companion to the Buckminster's junit command?
4) In case the ant task was implemented, should the junit command be
extended to support the setup / tear down at all given that using it
(specifying the classpath) would be a hassle anyway?
Thanks in advance for your comments,
regards,
Michal
|
|
|
| Re: Setup / tear down for JUnit plugin tests [message #500265 is a reply to message #499871] |
Wed, 25 November 2009 14:20  |
Achim Demelt
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
Michal,
I favor solution 1) because I think this is an environment issue that should
not be dealt with in Java code. In fact, I'd even argue that providing a
(virtual) X server is out of scope of the Buckminster build process.
Instead, I regard this as a requirement that the build host must meet,
similar to a requirement that the build host must provide a JDK 1.5.x.
That said, I have no problems with adding -setUp <command> and -tearDown
<command> arguments to the junit command if you consider this a frequent use
case.
Cheers,
Achim
Michal Ruzicka wrote:
> Hi,
> This is a re-post of my previous post to eclipse.tools.buckminster, as
> this newsgroup is probably the more appropriate.
>
> I'm having problems with running JUnit plug-in tests which happen to
> need GUI in a headless environment with Buckminster's junit command.
>
> The problem is that there is no X server running at the time when the
> framework supposed to execute the tests is launched. This naturally
> results in an early exit of the framework before any tests are executed.
>
> I was able to solve the problem for plain (non plug-in) JUnit tests by
> starting / stopping Xvfb (a virtual framebuffer X server which runs
> entirely in background without any need for real display or input
> devices) in @BeforeClass / @AfterClass annotated methods.
> This solution unfortunately does not work for the JUnit plug-in tests as
> the framework (and GUI) is attempted to be started earlier than the
> @BeforeClass / @AfterClass methods from any test class are called.
>
> A working solution would be to add some kind of setup / tear down
> functionality to the Buckminster's junit command. I'm willing to
> implement it but I'd like to discuss possible options first. So here are
> some question for you to comment on:
>
> 1) Should the implementation just allow to specify a command to execute
> prior to launching the tests, or should it rather require a java class
> implementing the setup / tear down functionality.
>
> 2) If the class is required, should it implement an interface devised
> for the setup / tear down purpose, or should it rather use annotations
> (perhaps the JUnit 4 @BeforeClass / @AfterClass annotations)?
>
> 3) If the class is required, then specifying it means specifying the
> class itself plus the classpath where the class is found. A classpath is
> much easier specified in an ant script that on a command line which
> leads me to the question: Shouldn't there be a <bukminster.junit> ant
> task companion to the Buckminster's junit command?
>
> 4) In case the ant task was implemented, should the junit command be
> extended to support the setup / tear down at all given that using it
> (specifying the classpath) would be a hassle anyway?
>
> Thanks in advance for your comments,
> regards,
> Michal
|
|
| |
| How to improve mapping rules in the Aggregator [message #502241 is a reply to message #499871] |
Mon, 07 December 2009 11:55 |
Karel Brezina
Messages: 68
Registered: July 2009 |
Member |
|
|
Hi,
lately, we've been discussing two aggregator issues. Some of us (I'd
even say most of us :-) ) think that:
1) MappedUnit should be replaced with a MapRequest (id and version would
be replaced by id pattern and version range)
2) MappedUnit and MapRule have much more in common than just IUReference
and should be merged together as a MapRequest
I'm proposing to replace MappedUnit and MapRule with the following
structure:
class MapRequest
{
IUType iuType;
String idPattern;
VersionRange versionRange;
boolean exclude;
List<Configuration> applyToConfigurations;
}
enum IUType
{
ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
}
This model is more general, but proper UI would make it easy to use. It
wouldn't be more complicated to use the aggregator. In some aspects, it
would be even easier. Anyway, it would be open for more advanced features.
Major advantages:
- versions of mapped units don't have to be updated every time MDRs are
updated
- it's easier to add more complex exclusion/inclusion rules
- easier implementation (getting rid of proxy references to IU)
Some basic actions:
- d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
created. iuType, idPattern and min. version of the range would be set
according to the selected IU, max. version would be set to infinity,
exclude would be set to false, applyToConfigurations would be empty
- d&d + Ctrl - it would create the same MapRequest, but exclude would be
set to true
The aggregator would have to provide some special actions (views) to
show how the request (or group of requests) would be resolved on the
first level.
Do you see any problems with the model I'm proposing? Do you have any
further improvements? Perhaps, do you thing that the current solution is
better?
There are several issue that would be affected by this change (293774,
293083, 293073, 292324), so I'd like to figure out, if there is a will
to improve the aggregator this way.
Regards,
Karel
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502254 is a reply to message #502241] |
Mon, 07 December 2009 13:26 |
|
Hi Karel,
I see one immediate problem. That is the 'idPattern' in combination with the 'versionRange'. It is a problem because
there cannot be a clear rule that selects the best fit. I would much rather see a explicit 'id' then a 'pattern'. A
MapRequest that replaces a MappedUnit must always appoint exactly one IU (well, or zero if the mapping cannot be resolved).
I think the URI resolution in our ecore model could be rewritten to actually resolve version ranges without too much effort.
A rule is somewhat different then a MapRequest in my view. A rule can apply to zero or many mapped things, or even to a
whole aggregation. It all depends on what the rule describes. Ideally, I think rules should be expressed as p2QL query
expressions so that it's possible to say things like "exclude all translation fragments" or "exclude IU's that include
this property". Using p2QL to define the scope for the rule would also give us pattern matching for free.
To summarize, I think it's important to keep MapRequest and Rule separate and that a MapRequest conceptually resovles to
one single IU (best fit) whereas rules are much more open.
- thomas
On 2009-12-07 12:55, Karel Brezina wrote:
> Hi,
>
> lately, we've been discussing two aggregator issues. Some of us (I'd
> even say most of us :-) ) think that:
>
> 1) MappedUnit should be replaced with a MapRequest (id and version would
> be replaced by id pattern and version range)
> 2) MappedUnit and MapRule have much more in common than just IUReference
> and should be merged together as a MapRequest
>
> I'm proposing to replace MappedUnit and MapRule with the following
> structure:
>
> class MapRequest
> {
> IUType iuType;
> String idPattern;
> VersionRange versionRange;
> boolean exclude;
> List<Configuration> applyToConfigurations;
> }
>
> enum IUType
> {
> ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
> }
>
> This model is more general, but proper UI would make it easy to use. It
> wouldn't be more complicated to use the aggregator. In some aspects, it
> would be even easier. Anyway, it would be open for more advanced features.
>
> Major advantages:
> - versions of mapped units don't have to be updated every time MDRs are
> updated
> - it's easier to add more complex exclusion/inclusion rules
> - easier implementation (getting rid of proxy references to IU)
>
> Some basic actions:
> - d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
> created. iuType, idPattern and min. version of the range would be set
> according to the selected IU, max. version would be set to infinity,
> exclude would be set to false, applyToConfigurations would be empty
> - d&d + Ctrl - it would create the same MapRequest, but exclude would be
> set to true
>
> The aggregator would have to provide some special actions (views) to
> show how the request (or group of requests) would be resolved on the
> first level.
>
> Do you see any problems with the model I'm proposing? Do you have any
> further improvements? Perhaps, do you thing that the current solution is
> better?
>
> There are several issue that would be affected by this change (293774,
> 293083, 293073, 292324), so I'd like to figure out, if there is a will
> to improve the aggregator this way.
>
> Regards,
> Karel
|
|
|
| Re: How to improve mapping rules in the Aggregator [message #502255 is a reply to message #502241] |
Mon, 07 December 2009 13:28 |
Karel Brezina
Messages: 68
Registered: July 2009 |
Member |
|
|
Sorry, the preceding entry got under this thread by mistake. I resent
it, so please replay to the new one.
Karel
Karel Brezina napsal(a):
> Hi,
>
> lately, we've been discussing two aggregator issues. Some of us (I'd
> even say most of us :-) ) think that:
>
> 1) MappedUnit should be replaced with a MapRequest (id and version would
> be replaced by id pattern and version range)
> 2) MappedUnit and MapRule have much more in common than just IUReference
> and should be merged together as a MapRequest
>
> I'm proposing to replace MappedUnit and MapRule with the following
> structure:
>
> class MapRequest
> {
> IUType iuType;
> String idPattern;
> VersionRange versionRange;
> boolean exclude;
> List<Configuration> applyToConfigurations;
> }
>
> enum IUType
> {
> ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
> }
>
> This model is more general, but proper UI would make it easy to use. It
> wouldn't be more complicated to use the aggregator. In some aspects, it
> would be even easier. Anyway, it would be open for more advanced features.
>
> Major advantages:
> - versions of mapped units don't have to be updated every time MDRs are
> updated
> - it's easier to add more complex exclusion/inclusion rules
> - easier implementation (getting rid of proxy references to IU)
>
> Some basic actions:
> - d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
> created. iuType, idPattern and min. version of the range would be set
> according to the selected IU, max. version would be set to infinity,
> exclude would be set to false, applyToConfigurations would be empty
> - d&d + Ctrl - it would create the same MapRequest, but exclude would be
> set to true
>
> The aggregator would have to provide some special actions (views) to
> show how the request (or group of requests) would be resolved on the
> first level.
>
> Do you see any problems with the model I'm proposing? Do you have any
> further improvements? Perhaps, do you thing that the current solution is
> better?
>
> There are several issue that would be affected by this change (293774,
> 293083, 293073, 292324), so I'd like to figure out, if there is a will
> to improve the aggregator this way.
>
> Regards,
> Karel
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:26:38 GMT 2024
Powered by FUDForum. Page generated in 0.03704 seconds |
] 
Search
Help
Register
Login
Home
