>Treating JDBC as “just another adapter” would be purity for purity’s sake.
I suggest to use "integration" term as soon as the test requires "setup of external" system. For instance, if a test requires "live mysql", then it is an integration test. If a test can be executed against embedded db, then it can be a unit test. >2. This will mean that 90% or more of tests in an adapter are flagged >integration tests. Doesn’t seem quite right. We can continue run JDBC tests against hsqldb _and_ reuse the same tests (e.g. via inheritance) in the integration suite to test queries against mongo, mysql, etc. > We can’t declare those as integration tests. They should be declared as > parameterized tests. I suggest using "hsqldb unit test" and a set of integration tests for mongo/mysql/etc. >1. Is there a way to move a test from regular to integration without >moving/copying code (e.g. by adding an annotation?) We might want to move a >test to integration for performance reasons. I don’t want to move/copy code >for that. Manen convention is to use *Test.java for unit tests and *IT.java for integration tests. Do you think we would need to move code often? Vladimir
