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
