>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?
>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
Thanks!
Bruno
From: Andy Seaborne <[email protected]>
To: [email protected]
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
