Does anyone have any comments on the note below? I added the notes to the bug so that they could be tracked, but I am looking for feedback comments or best practices. You assistance is appreciated.
On Sun, Sep 1, 2013 at 9:43 AM, Claude Warren (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/JENA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755681#comment-13755681] > > Claude Warren commented on JENA-380: > ------------------------------------ > > > I have been working on migrating the unit tests to JUnit4.11 and think I > have a design that works and meets the requirements/goals stated above. > > My strategy for building the new Junit 4.11 tests is: > 1. Tag the source tree and check it out. > 2. Migrate all tests from Junit 3.x to 4.11 while moving them to packages > that match the packages of the class under test. > 3. For interfaces the tests must take a parameter so that implementers can > easily run/extended the standard tests against their implementation. > 4. For complex interfaces (e.g. ones that return other interfaces defined > in Jena) test suites must be constructed that will test all of the returned > interface. > 5. Reuse the classes implemented for current testing where appropriate > (e.g. com.hp.hpl.jena.graph.RecordingListener) > 6. Mock classes for which a testing implementation does not currently > exist where required. (e.g. a mock TransactionHandler ). > 7. Diff the tag of the current trunk (assuming that new tests have been > added) > 8. Add new tests to account for the diff. > 9. Repeat 7 through 9 until there are no changes. > 10. Work with development team to ensure orderly transition to new tests. > 11. possibly redo steps 7 through 9 to account for any possibly missed > changes. > 12. Document how to extend the classes to make life easier for > implementers. > > I have not tagged the source tree yet and am looking through the existing > tests to ensure that I understand how to convert the patterns that have > been used to the 4.11 version. To that end I have the following (also in > the README in the new-test branch at /src/test/java/com/hp/hpl/jena/graph) > > Interface tests are built so that developers may test that implementations > meet the contract > set out in the interface and accompanying documentation. > > The major items under test use an instance of the GraphProducerInterface > to create the graph > being tested. An implementation of GraphProducerInterface must track all > the tests created > during the test and close all of them when requested. There is an > AbstractGrapProducer that > handles most of that functionality but requires a createNewGraph() > implementation. > > TESTS > ===== > > Interface tests are noted as Abstract(INTERFACENAME)Test. Tests generally > extend the > AbstractGraphProducerUser class. This class handles cleaning up all the > graphs at the end of > the tests and provides a hook for implementers to plug in their > GraphProducerInterface. > > In general to implement a test requires a few lines of code as is noted in > the example below > where the new Foo graph implementation is being tested. > > <code> > public class FooGraphTest extends AbstractGraphTest { > > // the graph producer to use while running > GraphProducerInterface graphProducer = new > FooGraphTest.GraphProducer(); > > @Override > protected GraphProducerInterface getGraphProducer() { > return graphProducer; > } > > // the implementation of the graph producer. > public static class GraphProducer extends AbstractGraphProducer { > @Override > protected Graph createNewGraph() { > return new FooGraph(); > } > } > > } > </code> > > SUITES > ====== > > Test suites are named as Abstract(INTERFACENAME)Suite. Suites contain > several tests that > excersize all of the tests for the components of the object under test. > For example the graph > suite includes tests for the graph iteself, the reifier, finding literals, > recursive subgraph > extraction, event manager, and transactions. Running the suites is a bit > more complicated then > running the tests. > > Suites are created using the JUnit 4 @RunWith(Suite.class) and > @Suite.SuiteClasses({ }) > annotations. This has several effects that the developer should know > about: > 1. The suite class does not get instantiated during the run. > 2. The test class names must be known at coding time (not run time) as > they are listed in the > annotation. > 3. Configuration of the tests has to occur during the static > initialization phase of class > loading. > > To meet these requirements the AbstractGraphSuite has a static variable > that holds the instance > of the GraphProducerInterface and a number of local static implementations > of the Abstract tests that > implement the "getGraphProducer()" method by returning the static > instance. The names of the > local graphs are then used in the @Suite.SuiteClasses annotation. This > makes creating an > instance of the AbstractGraphSuite for a graph implementation fairly > simple as is noted below. > > <code> > public class FooGraphSuite extends AbstractGraphSuite { > > @BeforeClass > public static void beforeClass() { > setGraphProducer(new GraphProducer()); > } > > public static class GraphProducer extends AbstractGraphProducer { > @Override > protected Graph createNewGraph() { > return new FooGraph(); > } > } > > } > </code> > > Note that the beforeClass() method is annotated with @BeforeClass. the > @BeforeClass causes it to be run once before any of the test methods in the > class. This will set the static > instance of the graph producer before the suite is run so that it is > provided to the enclosed > tests. > > > Migrate core tests to junit4 > > ---------------------------- > > > > Key: JENA-380 > > URL: https://issues.apache.org/jira/browse/JENA-380 > > Project: Apache Jena > > Issue Type: Task > > Components: Jena > > Affects Versions: Jena 2.10.0 > > Reporter: Claude Warren > > Assignee: Claude Warren > > Priority: Minor > > > > Many of the tests for jena core are junit3 suites. I would like to > start a process of migrating them to junit 4 and rework them so that when > compiling in the Eclipse IDE clicking on the failed test will take you to > the failed test while maintaining the current test names. I would expect > some test names to change based upon changes in functionality. > > The goals of this change are : > > 1) Move to junit 4 > > 2) Ensure that when the entire package is run as a junit test all tests > succeed. (i.e. valid default tests) > > 3) Continue to provide test classes that can be utilized by implementers > of interfaces. > > 4) Extract utility/helper code into utility/helper classes to simplify > the test inheritance tree. > > 5) Move the test classes into the same package name as the classes they > test. Currently we have x.foo for the implementation classes and > x.foo.test for the test classes. > > The process would be: > > 1) build a number of sub tasks under this change to deliver smaller > changes. The smaller changes will be based on the package names and that > can be delivered incrementally. > > 2) once all tests are in junit4 perform a sweep across the test code > base looking for any junit 3 classes that remain. Verify that their > testing functionality has been replaced by other code and remove them. > > The result will be a complete review of all the core tests and a > migration to junit 4 and annotated tests. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/user.php?cla...@xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
