search

oscarxie / android-test-kit

Automatically exported from code.google.com/p/android-test-kit
0 stars 0 forks source link

Enhancement: Please add support for XML output #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Because your system has a hard requirement to use the new test runner, it will 
be unusable in our Continuous Integration environment without having to go back 
and write a custom parser or merging something like the Polidea test runner in 
and then building your project myself (once you fix the build problems that is).

Please save me and countless others who use Jenkins for their build server a 
lot of time by baking it in directly.

Here's a reference of the XML test runner I called out above:
https://code.google.com/p/the-missing-android-xml-junit-test-runner/source/brows
e/

Original issue reported on code.google.com by rucoll...@ubermind.com on 14 Nov 2013 at 7:08

GoogleCodeExporter commented 9 years ago 
Issue 100 has been merged into this issue.

Original comment by vale...@google.com on 23 Oct 2014 at 9:41

GoogleCodeExporter commented 9 years ago 
@rucoll I agree they should add support for XML output, but in the mean time I 
would recommend the Log Parser Plugin for Jenkins as a temporary fix.  It's not 
ideal but at least you can get a Jenkins' build to fail when espresso throws an 
error.

Original comment by jabKnows...@gmail.com on 14 Jan 2015 at 5:49

GoogleCodeExporter commented 9 years ago 
It looks like it should be possible to do this by attaching a RunListener. I 
haven't been able to find an existing implementation though.

RunListener: 
http://junit.sourceforge.net/javadoc/org/junit/runner/notification/RunListener.h
tml

Original comment by chris.va...@laterooms.com on 10 Mar 2015 at 5:10

GoogleCodeExporter commented 9 years ago 
The problem with Espresso 2.0 and RunListeners, as opposed to TestListeners, is 
that they have no callback for test errors (only for test failures). Anyway, if 
you're looking for a RunListener-based XML report writer, have a look at 
https://github.com/barrypitman/JUnitXmlFormatter.

Original comment by sschuberth on 10 Mar 2015 at 7:35

GoogleCodeExporter commented 9 years ago 
JUnit4 treats test errors as test failures, so the extra callback shouldn't be 
needed as long as AndroidJUnitRunner conforms to this.

If you want test errors to be shown differently to test failures, you could do 
this in your RunListener by just checking whether the Throwable that caused a 
failure extends AssertionError.

I haven't had chance to check whether AndroidJUnitRunner treats test errors as 
failures - and whether it does this for all tests or just for JUnit4-style 
tests.

Original comment by chris.va...@laterooms.com on 11 Mar 2015 at 9:54

GoogleCodeExporter commented 9 years ago 
The gradle plugin now does this for us: 
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Running-tests

Original comment by vale...@google.com on 30 Mar 2015 at 9:07

GoogleCodeExporter commented 9 years ago 
@6 Could you clarify what "now" means? Which version of the Gradle plugin 
introduces that feature? I cannot find it in the release notes at 
http://tools.android.com/tech-docs/new-build-system/.

Original comment by sschuberth on 31 Mar 2015 at 8:16

GoogleCodeExporter commented 9 years ago 
gradle support is not enough - XML output for "adb.exe shell am instrument" is 
needed as well!

Original comment by ohad...@gmail.com on 19 Aug 2015 at 2:34