You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by Apache Wiki <wi...@apache.org> on 2009/01/28 16:27:34 UTC

[Ant Wiki] Update of "Proposals/EnhancedTestReports" by PetarTahchiev

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ant Wiki" for change notification.

The following page has been changed by PetarTahchiev:
http://wiki.apache.org/ant/Proposals/EnhancedTestReports

------------------------------------------------------------------------------
  
   * Standard serializable Java types for tests. Must include log entries and exceptions. These can be marshalled over RMI or serialised to text files. Enables a tight coupling of reporting across processes. It is however, hard to maintain stability, especially with OSS code that can be changed by anyone. The limit of these type's use would probably be the junit test runner and ant itself, both from the same point release of Ant.
  
-  * Streamed XHTML with standard class names. Here an inline CSS sheet provides the styles, and tests are streamed to disk as marked up div/span clauses. oes not directly scale well to presenting very large test runs; postprocessing is required. XSL can still generate alternate reports, though the XPath patterns are more complex //div[@class="error"] instead of //error. 
+  * Streamed XHTML with standard class names. Here an inline CSS sheet provides the styles, and tests are streamed to disk as marked up div/span clauses. Does not directly scale well to presenting very large test runs; postprocessing is required. XSL can still generate alternate reports, though the XPath patterns are more complex //div[@class="error"] instead of //error. 
  
   * Atom. Here every test result would be presented as an Atom entry, possibly using streamed XHTML as above. Enables remote systems to poll for changes, and for browsers to present results as is. Does not directly scale well to presenting very large test runs; postprocessing is required. XPath is even more complex. 
  
@@ -75, +75 @@

   * SmartFrog team (SteveLoughran)
   * TestNG: AlexandruPopescu 
   * Maven SureFire: DanFabulich, BrettPorter
+  * Cactus framework: Petar Tahchiev
  
  == Plan and Timetable ==
  
@@ -164, +165 @@

   * list tests by tag
   * list tests by execution time
   * list tests that are partial failures, unfinished
+  * might be a good idea to have a 'sort-by-column' feature. This way you sort columns by test-name, execution-time, test-status, etc. (Petar Tahchiev) 
   * for tests that are published to a web site, integrate with searching (allow a search box in the HTML)
   * list failing tests by exception name
   * For live output, provide an ongoing status page that updates regularly.
@@ -199, +201 @@

  === Integration with Issue Trackers ===
  
  What would this look like? Perhaps and element with URLs to related issues?
+ 
+ Petar Tahchiev: This could be easily integrated with Maven, since Maven keeps track of the Issue Management System in the POM. This way we might only keep the ISSUE # in the xml and the maven surefire-reports plugin can construct the URLs.
+ 
+ === Integration with SCM ===
+ 
+ I would really like the idea of polling some info from the SCM, like for instance the user, who added the test-case(or the test-method). This way if a test is failing and you can't realize why is this happening, you can consult with the guy who wrote the test-case.
  
  
  === Generate Google Charts ===