[Anthill-pro] Re: Can AHP3 slurp up junit tests?

[Jason Dillon]

On Nov 29, 2006, at 8:02 AM, Eric Minick wrote:
> As for the slurping, the report is working both locally and in my  
> test environment.

Are each of your TEST-*.xml files in the same directory?  As in:

     /TEST-a.xml
     /TEST-b.xml

or in different directories, as in:

     /foo/target/surefire-reports/TEST-a.xml
     /bar/target/surefire-reports/TEST-b.xml

I am quite sure the later will not work with an inclusion pattern  
like "**/target/surefire-reports/TEST-*.xml"... as I have tried it a  
few times and it won't work.

I had to add another post-process to basically:

         ant.copy(todir: "reports/surefire", flatten: true) {
             fileset(dir: ".") {
                 include(name: "**/target/surefire-reports/TEST-*.xml")
             }
         }

Then use an include pattern like "TEST-*.xml" in the "reports/ 
surefire" directory.  This tells me that however you are finding the  
XML inputs for the report generation is only working off of a single  
directory, not an entire tree (which is why the "flatten: true" works.

NOTE: This pattern "**/target/surefire-reports/TEST-*.xml" does  
appear to pick up all of the report files to be delivered to the  
server... as I do see the right number of files added to the zip  
(from the logs, have not actually peeped at the zip itself, but I  
assume your logs are reporting the correct numbers).


> Would it be possible for you to zip up the test results directory  
> structure of your and shoot it over to me? I'd be happy to set up a  
> little test project that just tries to load them and see where  
> things are tripping up.

You can see the exact set of files, by using that above pattern, with:

svn co http://svn.apache.org/repos/asf/geronimo/specs/trunk specs
cd specs
mvn install


> We're actually doing an XML parse rather than XSLT. The report  
> generation would be better as XSLT but that's a distraction anyway.  
> The real nifty part is that the data is decently exposed to the  
> API. While you can include test information in notifications, that  
> might also be XSLTable. What isn't is making decisions based on the  
> data. There's a little example at the bottom of the Integrating  
> JUnit tutorial in the docs that shows how to send out seperate  
> notifications for failing tests or tests that are not running  
> quickly enough (indicating functional rather than unit).

Okay, how does your XML parse find the files it is going to process  
for the report?  I hope its not a simple java.io.File.listFiles() off  
of a directory.  I had expected it to re-use that pattern I had given  
the report configuration, using an ant-like FileScanner or something.

--jason