Hello Claude
Category testing requires that you know all the category tests when you
write your tests.
The contract test finds all the implemented tests. So if we implement a
new test it is automatically picked up. Also the contract test maven
plugin will show us all the interfaces that are missing tests -- actually
the tooling will do that without the maven plugin.
Thanks for clarifying. That makes sense, and also makes me want to
experiment writing some contract tests. I'll spend some hours during the
next days playing with the code in that GitHub repository :)
I did some work awhile back to convert the tests to junit 4 (Under the
new-test branch)
I couldn't find the branch under Jena's Git repo at ASF [1]. Maybe it was
deleted?
The problem was the number of suites that are not supported by junit
4. Many of the suites are written so that they add the tests at runtime
so you don't really know all the tests at compile time (as the annotations
require). I found (or wrote -- I don't recall which) an annotated suite
that would allow you to add tests are runtime -- I'll have to find that
again.
Oh, I also noticed it. This one test suite was the first one that I found
[2] with this pattern. It would be great to have a procedure to follow when
migrating these suites.
The secondary problem is that the number of tests is significant and it
is hard to keep up with newly added tests and changes as development
proceeds.
I can try helping with this. Maybe one or two long development cycles just
to work on this issue. And maybe discuss in the mailing list on a coding
style for new tests - and perhaps update the Wiki with some guideline.
I've created a branch [3] to work on JENA-380. Feel free to commit to this
branch too or to another branch. I'll try to keep it up to date to master
and create one (or few) commits when merging to the master branch.
Thanks!
Bruno
[1] https://git1-us-west.apache.org/repos/asf?p=jena.git;a=summary
[2]
https://github.com/apache/jena/blob/281e655a0cc696b76006a7bda0582662eefd98de/jena-iri/src/test/java/org/apache/jena/iri/TestExample.java#L226
[3]
https://git1-us-west.apache.org/repos/asf?p=jena.git;a=shortlog;h=refs/heads/JENA-380
------------------------------
*From:* Claude Warren <[email protected]>
*To:* Bruno P. Kinoshita <[email protected]>
*Sent:* Sunday, April 19, 2015 6:05 AM
*Subject:* Re: Work on JENA-380
Category testing requires that you know all the category tests when you
write your tests.
The contract test finds all the implemented tests. So if we implement a
new test it is automatically picked up. Also the contract test maven
plugin will show us all the interfaces that are missing tests -- actually
the tooling will do that without the maven plugin.
I did some work awhile back to convert the tests to junit 4 (Under the
new-test branch) The problem was the number of suites that are not
supported by junit 4. Many of the suites are written so that they add the
tests at runtime so you don't really know all the tests at compile time (as
the annotations require). I found (or wrote -- I don't recall which) an
annotated suite that would allow you to add tests are runtime -- I'll have
to find that again.
The secondary problem is that the number of tests is significant and it is
hard to keep up with newly added tests and changes as development proceeds.
Claude
On Sat, Apr 18, 2015 at 1:10 PM, Bruno P. Kinoshita <[email protected]>
wrote:
Hi Claude!
I would like to work with you on this.
That's great! Shortly after writing I started to toy around with the
existing tests. Looks like most of the code using JUnit3 that I found also
have test suites. So probably simply finding "extends TestCase" and
replacing by some annotations won't be enough.
How do you think we can divide the tasks? I don't mind repetitive/manual
tasks at all :-)
I also think that we should develop contract tests for our SPI
interfaces (like graph).
That's new to me, and looks interesting.
But just to see if I understand it correctly, couldn't we achieve the same
with categories [1]? This way, tests for the interface "I" (from the
example in the GitHub repo) could be orthogonally tested with a category
CategoryI. And finally annotate a test suite class with
@RunWith(Categories.class) @IncludeCategory(CategoryI.class)
@SuiteClasses(...).
What would be the advantage of the contract tests over using categories?
Cheers
Bruno
[1] https://github.com/junit-team/junit/wiki/Categories
------------------------------
*From:* Claude Warren <[email protected]>
*To:* [email protected]; Bruno P. Kinoshita <[email protected]>
*Sent:* Saturday, April 18, 2015 11:14 PM
*Subject:* Re: Work on JENA-380
I was working on this awhile back and got pulled away.
I would like to work with you on this. I also think that we should
develop contract tests for our SPI interfaces (like graph).
https://github.com/Claudenw/junit-contracts
On Sat, Apr 18, 2015 at 9:55 AM, Bruno P. Kinoshita <[email protected]>
wrote:
Hi all,
I'm planning to work on JENA-380 [1], migrating tests from JUnit 3 to
JUnit 4, and would like to know if anyone else is working on it.
The issue includes some new structure for tests too, but I intend to
simply remove the old JUnit 3 syntax (e.g. extends TestCase) by
annotations. Later we can work on the remaining of the tasks or close the
issue and open separate issues for each specific task.
Any thoughts?
Bruno
[1] https://issues.apache.org/jira/browse/JENA-380
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com/>
LinkedIn: http://www.linkedin.com/in/claudewarren
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com/>
LinkedIn: http://www.linkedin.com/in/claudewarren
