On Apr 21, 2009, at 6:31 AM, Tom Eyckmans wrote:
Hi All,
I'm working on the native test framework integration of Gradle and
we are currently looking into some details regarding forking.
What we currently plan to do is always fork the test execution in a
separate VM and only fork once (default). Possibly have multiple
forked VMs either to speed up test execution or for testing with
different option sets (other environment variables / classpath/ ...).
Currently we don't plan to support unforked execution ( forking
provides the cleanest test environment and to protect the build
process ).
I don't see use cases for non-forked execution. A smaller footprint
might have been an argument in the past but I don't think this is
relevant nowadays. So we should support only forked execution. If
someone comes up with a good use case we can always change it later.
Some questions:
- does anybody use per-test forking? use-cases?
I think fork-per-test is the cleanest way to run tests. It follows the
usually best practice of having a fresh fixture per test. A good
example are classes which depend on system properties. The tests will
need to change the system properties in various ways to tests this
class. In a non-forked-per-test have environment you have to pay
attention to reset the changes to the system properties in the
tearDown method.
It is also the default for ant. So we must support it. Otherwise
people migrating from Ant to Gradle might run into failing tests that
did not fail before.
In our Gradle build we don't use fork-per-test because of performance
issues. We have many Groovy unit test and the Groovy startup time
slows the test execution significantly down with fork-per-test. With
Java only tests this is a different story.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
