Looking good so far Andy! I had a look at the imports and Eclipse is doing a great job!
By the way, do you have a custom coding style for Eclipse? I noticed that the Fix imports kept the space between the last character and the ";" character. If you could share your Eclipse coding style I'd start using too to ease merging of patches. The branch isn't building yet as there are other references to the old package [1]. But after fixing some locally-only in assembler files, some tests like TestTDBAssembler start passing again, so looks like the rest of the process won't give much trouble (hopefully :) CheersBruno [1] https://gist.github.com/kinow/fa054b93df33bc12fb0d From: Andy Seaborne <a...@apache.org> To: dev@jena.apache.org Sent: Friday, April 24, 2015 4:36 AM Subject: Re: Start Jena3 On 22/04/15 23:26, Bruno P. Kinoshita wrote: >> For my stuff, "Test*" are sets of tests, "TS_*" are those >> grouped>together (e.g. by package) and "TC_*" are top level >> collections of TS_* surefire runs all TS_, TC_ are run inside >> Eclipse. > > > So after the migration, "Test*" will be used for classes with @Test > annotated tests. TS_ for classes annotated with @RunWith(Suite.class) > and @SuiteClasses({$CLASSES_IN_PACKAGE}), and TC_ for classes that > are also test suites, but may include tests in more than one > package? Some tests don't use "test*" when they are @Test -- Junit3 required it, Junit4 is just style. There may be lots of "@Test test*" in ARQ because it's converted. The Test/TS_/TC_ convention isn't something deep; I have found it convenient to work with sets of tests, not just run the whole lot all the time. More so when the test suite gets a bit slow. > > >> I took a very quick look - is AbstractTestPackage just not added >> anywhere? And the constructor for AbstractModelTestBase? > > > That was the last part I worked on the branch I think. I had a quick > look at the addTest method and its Javadoc and assumed it was > mimicking the default behavior of JUnit test suites. Looking again > now, it clearly has some specific code for Jena, and would likely > break some tests once I had fixed the build errors (that happened > before in another package). > > > I was also trying to make AbstractModelTestBase a simple object and > not extend TestCase anymore. The classes with annotated @Test methods > must have a public no arguments constructor. My idea was to add a > setModelFactory method and try to initialize the model factory with a > @BeforeClass or @Before. But that's still a WIP, as I haven't really > assessed the impact of this change yet. > > >> Doing it bottom up, means conversion can be done one package at a >> time so the system is buildable - indeed, if it's bite-sized (one >> coding session) chunks, it might as well go direct to master with >> regular pushes. >> >> My picture was of an incremental approach would be to convert all >> JUnit3 "public void test*" to JUnit4 @Test, then do the >> TestSuites. > > > I was trying to both convert TestCase to @Test annotated methods, and > to replace the static TestSuite suite methods by classes annotated > with @RunWith. Once Jena3 is ready, I will start migrating tests to > JUnit4 @Test first, and then will start working on the test suites. > > > Would this be the default workflow for simple JUnit3 classes with > vanilla test suites? > https://gist.github.com/kinow/a7c1f3af857830d4dffc Re: gistfile2.java I think it's : public static junit.framework.Test suite() { return new JUnit4TestAdapter(ASimpleTestCase.class) ; } and ASimpleTestCase need not extend JUnit3 TestCase. It might put a extra one level node in the tests tree in Eclipse. Caution: that's what I think it is, may not be the best way, and it's been a while since I looked properly! If so, then can step3 be skipped and go to pure Junit4 ASimpleTestCase and have public static junit.framework.Test suite() { TestSuite ts = new TestSuit ts.addTest(new JUnit4TestAdapter(ASimpleTestCase.class)) ; ts.addTest(new JUnit4TestAdapter(MoreTests.class)) ; ... } ? Just a thought. Andy > > > Thanks! Bruno > > > From: Andy Seaborne <a...@apache.org> To: dev@jena.apache.org Sent: > Thursday, April 23, 2015 4:07 AM Subject: Re: Start Jena3 > > On 22/04/15 04:30, Bruno P. Kinoshita wrote: >>> That would not be ideal unless you have the process scripted. I >>> don't want to create rework. >> Actually that might help. In the first commits I was still just >> getting my feet wet and understanding the current test harness, >> but now I already would have to review some of my previous >> commits. >> >> I've found a few patterns that I would like to document, e.g. the >> TestPackage suite found in the core module, some test suite >> classes being prefixed with TS_, and easy ways to convert several >> classes at once by starting by a parent class like JenaTestBase. >> I'd prefer that you worked on the Jena3 branch, told me if there >> was any testing or anything else that I could do to help, and then >> once it has been merged into master, I would restart the work on >> JENA-380. > > For my stuff, "Test*" are sets of tests, "TS_*" are those grouped > together (e.g. by package) and "TC_*" are top level collections of > TS_* surefire runs all TS_, TC_ are run inside Eclipse. > >> Side note: The only scripting that I have in place for now, is >> some shell scripting (grep, find, etc) to find classes that have to >> be ported. But I would like to run some other code/script in the >> future that could find the following: "Classes under the >> src/main/test directory, with a public method which name starts >> with test, has no parameters and doesn't contain the @Test >> annotation". I missed to annotate a few JUnit3 test methods, and a >> script like that could help me to review my changes before >> committing the code. Is anybody aware of how to do that in a simple >> and quick way? I know that is doable with some reflection and Java >> code, but if there was a simple Groovy script, sed/awk/regexes >> shell, or something easy to run, that would be very helpful too. >> >>> Anything I can do to help? >> Reviewing and testing my changes later would be grand! > > I took a very quick look - is AbstractTestPackage just not added > anywhere? And the constructor for AbstractModelTestBase? > > My picture was of an incremental approach would be to convert all > JUnit3 "public void test*" to JUnit4 @Test, then do the TestSuites. > > Doing it bottom up, means conversion can be done one package at a > time so the system is buildable - indeed, if it's bite-sized (one > coding session) chunks, it might as well go direct to master with > regular pushes. > > The bridge JUnit4TestAdapter converts classes or @Test to Junit3 > TestSuites so it'll fit in the JUnit3 framework but still work. > > The other bridge, @RunWith(AllTests.class), can be used to start > with JUnit4 at the top and convert downwards. > > Once "JUnit4-ified", then looking at improving coverage and > contracts can proceed in a Junit4 environment. Doing both at once > seems like quite a big single step. > > > There is some old junk manifest driven stuff around in. That'll be > deleted in Jena3 - the packages are unused and only in jena2 for > absolute compatibility): com.hp.hpl.jena.n3(.turtle). > > (( I found some unused Junit3 junk in ARQ which I'll now go and zap > ASAP. It might be the result of (semi-)automatic conversion of the > ARQ tests but it has left unused "extends TestSuite" > > > )) > >> I'll use SonarQube and Surefire reports to count the number of >> tests and the coverage before and after the changes in JENA-380. >> But since the changes in JENA-380 will be orthogonal, involving >> several modules (in special core, iri and arq), the more eyes we >> can get to review and make sure that no tests have been disabled or >> broken, the merrier. If you, Rob, Claude, and all, could inspect >> modules that you are familiar with, and tell me if the tests seem >> to be working correctly, that would be of great help. How does that >> sound? >> >> ThanksBruno > > Andy > > > > >
