On Jul 17, 2012, at 2:54 AM, Aristedes Maniatis wrote: > Without written steps on how to run the tests, are we confident that all the > right tests are run before release?
We do have written steps: http://cayenne.apache.org/running-unit-tests.html > What level of compatibility are we expecting with sqlite? Do we have a > document on what is expected to work and what will break? I've never used it > directly so I don't really know its capabilities, but ideally we should have > a list of known issues. > > Would we be able to disable some tests when running against sqlite so that > the others pass? Not sure how easy or hard that might be. In our unit tests we have something called org.apache.cayenne.unit.UnitDbAdapter that makes a clumsy attempt to sort out databases by supported features (individual tests would do "if ! adapter.supportsFeatureX() return"). It works for real DB's where the differences are not that great. When half of the metadata is not available and half of the SQL spec is not implemented, as in the case with SQLite, it just doesn't "scale" in complexity. I guess going forward it would be good to have something annotation-based for instance. E.g. placing this on test methods: @ExcludeDB("db1", "db2"), and then building a report about feature compatibility based on these annotations. Having said that, I really have no concern about SQLite. We let people read and write data from it, but otherwise I could care less about it. "Real" DBs is another story, we need to make sure that all (most) the tests pass. So your idea of having Oracle, PostgreSQL and others on Jenkins is a great one (although I suspect the infra won't be very excited about it). Andrus
