Mike poses an interesting question. Should we add transaction boundaries to all the tests? I think there are 3 choices: 1) do not add transactions and developers like Mike will have problems with environments that require transactions. 2) add a switch that allows transactions to be enabled for the test and have the TestingModelFactory specify if it is on or off. 3) turn on transactions in the tests by default. The assumption here is that all Model implementations will support the transaction calls. 4) use the Model.supportsTransactions() method to determine if the transaction should be used within the test.
I would lean toward 3 or 4. Claude On Thu, Aug 1, 2013 at 5:09 PM, Mike Grove <[email protected]> wrote: > I'm just getting back to this, thanks for the pointers. Thanks to Claude's > references, I got the Model & Graph tests patterns off his usage running > and I fail most of them since it looks like most if not all changes to the > Model/Graph are made sans-transaction. > > I took a brief look at the code, and it did not seem like there was a bit > flipped that would enable them for tests. I can put autoCommit type > functionality into the code if need be, but that seemed less than ideal. > > Thanks. > > Mike > > > On Mon, Mar 25, 2013 at 11:00 AM, Andy Seaborne <[email protected]> wrote: > > > Michael, > > > > Most of the testing gets done on the graph-level object, Model and > Dataset > > are just wrapper, Dataset particularly is quite a thin wrapper. That, > and > > a lot of the coverage is by being used in other places. > > > > com.hp.hpl.jena.sparql.core.**AbstractTestDataset > > com.hp.hpl.jena.sparql.core.**AbstractDatasetGraphTests > > > > com.hp.hpl.jena.graph.test.**AbstractTestGraph > > com.hp.hpl.jena.sparql.graph.**AbstractTestGraph2 > > > > com.hp.hpl.jena.tdb.**migrateAbstractTestTransaction**. > > > > (hmm - the package name theer is a bit of a clue ...) > > > > Andy > > > > > > On 25/03/13 14:17, Claude Warren wrote: > > > >> Michael, > >> > >> I just spent some time reworking the Model tests in 2.10 so that they > can > >> be run by other implementations of Model. As far as I know there has > not > >> been any similar work for dataset. > >> > >> see > >> http://svn.apache.org/repos/**asf/jena/trunk/jena-core/src/** > >> test/java/com/hp/hpl/jena/rdf/**model/test/TestPackage.java< > http://svn.apache.org/repos/asf/jena/trunk/jena-core/src/test/java/com/hp/hpl/jena/rdf/model/test/TestPackage.java > > > >> > >> for an example of how to implement the TestingModelFactory and plug it > >> into > >> the testing framework. > >> > >> As I recall there is a directory of testing files that need to be > included > >> (there is a defect for this that I have not had a chance to work on > yet). > >> > >> https://github.com/Claudenw/**JenaSecurity/blob/master/** > >> JenaSecurity/src/test/java/**org/xenei/jena/security/** > >> contract/model/TestPackage.**java< > https://github.com/Claudenw/JenaSecurity/blob/master/JenaSecurity/src/test/java/org/xenei/jena/security/contract/model/TestPackage.java > > > >> Shows how I used the tests in a 3rd party package. > >> > >> Claude > >> > >> On Mon, Mar 25, 2013 at 12:18 PM, Mike Grove <[email protected]> > >> wrote: > >> > >> I am wondering what would be the best choice to see if a custom > >>> Model/Dataset worked as expected? I have some custom tests, but I'm > sure > >>> those are a bit short on coverage. So if there was some way I could > >>> re-use > >>> the same tests Jena uses, that'd be helpful. > >>> > >>> Thanks. > >>> > >>> Michael > >>> > >>> > >> > >> > >> > > > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
