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
