-
由 kohsuke 提交于
Merged revisions 24854,24862,24946,25411,25418-25419,25478,25699,25701,25770,25832,25834,26401-26404 via svnmerge from https://www.dev.java.net/svn/hudson/branches/test-result-refactor ........ r24854 | bshine | 2009-12-22 12:52:32 -0800 (Tue, 22 Dec 2009) | 82 lines Generalize the junit-specific TestResult class into AbstractTestResult, and allow plugins to contribute test result parsers that generate AbstractTestResult subclasses. In order to support the increasing variety of test result file formats, we have added two extension points: * AbstractTestResult: a class that represents a general concept of a test result, without any language or implementation specifics. * AbstractTestResultParser: an API for parsing test result files and producing an instance of a concrete subclass of AbstractTestResult AbstractModelObject \ TestObject \ AbstractTestResult is-a ExtensionPoint \ |-- CaseResult | |-- SimpleCaseResult | |-- TabulatedResult \ |-- ClassResult | |-- MetaTabulatedResult \ |-- TestResult | |-- PackageResult AbstractTestResultParser is-a ExtensionPoint \ JUnitParser We have refactored the JUnit result publishing system so that it is "just" a subclass of AbstractTestResult. We have promoted functionality into AbstractTestResult from TestResult; we have also promoted jelly resources from TestResult up to AbstractTestResult. Together, these changes make it possible -- without much code -- to add a test result parser and a test result publisher that can participate in the test result ecosystem. See, for instance, TrivialTestResult, with its two supporting classes, TrivialTestResultAction and TrivialTestResultRecorder. We have moved the format-agnostic classes in the test result system into the hudson.tasks.test package, from hudson.tasks.junit: TestObject MetaTabulatedResult TabulatedResult We have attempted at every step to preserve backwards compatibility both with the existing APIs and with test results stored by earlier versions of Hudson. Numerous tests verify that the old APIs and historical data are still readable; all of the tests in hudson.tasks.junit operate on stored builds and test results created by Hudson around version 1.320. These tests have been created and expanded to exercise the HTML ui and the XML api of the test result publishing system, as well as the underlying java logic. hudson.tasks.junit.CaseResultTest hudson.tasks.junit.JUnitParserTest hudson.tasks.junit.JUnitResultArchiverTest hudson.tasks.junit.TestResultLinksTest hudson.tasks.junit.TestResultPublishingTest This checkin also includes several smaller changes that were enacted in the course of this work: Added convenience/utility methods - HudsonTestCase.java Added a read-only textbox. - core/src/main/resources/lib/form/readOnlyTextbox.jelly Added a standalone builder that touches all files in the workspace. - TouchBuilder.java Added a test: testUnwrappedLongString - src/test/java/hudson/model/ApiTest.java ........ r24862 | bshine | 2009-12-22 17:30:04 -0800 (Tue, 22 Dec 2009) | 1 line Recreate the hudson.tasks.junit.TestObject class, and adapt the TestResultAction.Data class to be friendly to the refactoring. This makes the claim plugin and the junit-attachments plugin compile and pass tests against this branch. ........ r24946 | bshine | 2009-12-24 21:59:14 -0800 (Thu, 24 Dec 2009) | 1 line Getting rid of some TODOs that don't apply anymore. The TODOs that remain are meaningful. ........ r25411 | kohsuke | 2010-01-05 18:14:15 -0800 (Tue, 05 Jan 2010) | 3 lines Cosmetic change. It's not necessary to define our own constant for empty list when there's already one in JDK. I also think creating and wasting singleton list as needed is probably better use of memory than having a singleton list tied in memory for every CaseResult. It improves cognitive overhead for people reading the code, and modern GCs are very good at handling short-lived objects, and I don't see this method called in a busy loop. ........ r25418 | kohsuke | 2010-01-05 18:37:17 -0800 (Tue, 05 Jan 2010) | 1 line pushed the get/setDescription implemention up to the AbstractTestResultAction. I believe the default implementation is sufficient for most purposes, and typical subtypes don't want to bother with the details that descriptions are actually persisted by the owning Action instead of in TestObjects. ........ r25419 | kohsuke | 2010-01-05 18:59:29 -0800 (Tue, 05 Jan 2010) | 1 line we should allow the parse method to be called outside of the build, so this should be TaskListener. ........ r25478 | kohsuke | 2010-01-07 11:44:34 -0800 (Thu, 07 Jan 2010) | 14 lines The ExtensionPoint interface primarily serves as a marker to call attention of the plugin developers as to where to hook into Hudson. Since the act of implementing AbstractTestResultParser naturally make them to implement AbstractTestResult, I'm removing the ExtensionPoint marker from this abstract class. The all() method is removed after the following discussion: >> - I propose we remove AbstractTestResult.all(). I don't think being >> able >> to enumerate AbstractTestResult subtypes buy us anything, since those >> can only be instantiated by parsers that intimately know how to >> instantiate them properly. Or did I miss the purpose of this? > > I put in the all method because it was suggested by the wiki: > "You also need to define the static "all" method..." > http://wiki.hudson-ci.org/display/HUDSON/Defining+a+new+extension+point > so I don't have a problem with removing it. ........ r25699 | bshine | 2010-01-11 16:34:12 -0800 (Mon, 11 Jan 2010) | 1 line Removed a test that exercised AbstractTestResult.all(), because that API has been removed. ........ r25701 | bshine | 2010-01-11 17:05:40 -0800 (Mon, 11 Jan 2010) | 1 line Don't test getDescription() on a TrivialTestResult because the TrivialTestResult doesn't actually implement a description. ........ r25770 | bshine | 2010-01-13 11:52:27 -0800 (Wed, 13 Jan 2010) | 1 line Added a failing test to demonstrate bug HUDSON-5246, inter-build diffs for junit test results are wrong. ........ r25832 | bshine | 2010-01-14 13:50:15 -0800 (Thu, 14 Jan 2010) | 1 line The id field was accidentally declared here; it was also declared in hudson.tasks.test.TestObject. This id field here is always hidden by the id field in the more-concrete TestObject. Therefore, I'm removing this field. ........ r25834 | bshine | 2010-01-14 13:55:10 -0800 (Thu, 14 Jan 2010) | 5 lines Fixes bugs with getPreviousResult: HUDSON-5269 TestResult.getPreviousResult returns null when it shouldn't HUDSON-5246 test-result-refactor branch: inter-build diffs for junit test results are wrong ........ r26401 | kohsuke | 2010-01-25 17:24:51 -0800 (Mon, 25 Jan 2010) | 7 lines renamed: AbstractTestResultParser -> TestResultParser AbstractTestResult -> TestResult This discussion is in http://n4.nabble.com/Review-requested-Test-Result-Refactoring-td978100.html#a978100 The conclusion of this renaming proposal isn't clear, but I'm assuming it's OK. ........ r26402 | kohsuke | 2010-01-25 17:27:57 -0800 (Mon, 25 Jan 2010) | 1 line elsewhere in Hudson it's the "display name" that indicates a human readable name that programs don't try to interpret. ........ r26403 | kohsuke | 2010-01-25 17:31:38 -0800 (Mon, 25 Jan 2010) | 1 line typo ........ r26404 | kohsuke | 2010-01-25 17:35:41 -0800 (Mon, 25 Jan 2010) | 1 line doc improvement. ........ git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@26406 71c3de6d-444a-0410-be80-ed276b4c234a
92ca98c4