Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] Setup / tear down for JUnit plugin tests

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



Back to the top