On Oct 31, 2008, at 5:06 PM, Peter Niederwieser wrote:
Hello Hans,
hdockter wrote:
I don't know how the JetBrains guys hook into into this for there Ant
Teamcity runner.
I've read that they use a patched Ant JUnit task.
hdockter wrote:
What we want to do for 0.6 is to rewrite our Test task to natively
run the tests. Then we can provide listeners for test execution.
Do you plan to provide test isolation similar to Ant's/Maven's fork
mode? If
yes, will I be able to register a test execution listener even if
the tests
are run in a different VM?
I don't know how. But we have to make this possible as forking is the
(sensible) default.
A different approach would be to parse JUnit's XML report, but I'd
prefer to
avoid that if possible. What do you think?
This is what the teamcity guys have answered, when I have asked them
how to get test report when doing a shell build (like we do right now
with the gradle wrapper).
Here is there answer:
----
TeamCity does not rely on test reports in xml format. The tests are
reported in real-time without waiting for the xmls to be generated.
This approach has a drawback of mandatory support for the test runner.
Can you please describe why do you need to rely on the xml reports?
If the tests are run by Ant, TeamCity listeners can be pushed into the
script to report tests on-the-fly.
There is also a possibility to report test manually using
specially-formatted stdout output. You can find more on this in the
documentation: http://www.jetbrains.net/confluence/display/TCD3/Build
+Script+Interaction+with+TeamCity
We have a feature filed to parse junit xml reports and report tests
from it. You can vote for /watch the issue: http://jetbrains.net/
tracker/issue/TW-4819
----
So XML parsing will be supported in the future out-of-the-box by
teamcity.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
