Eric Pugh wrote:
I've had this challenge as well. It seems wrong to have unit tests awayI do agree with you that testing with dbUnit crosses the line between real unit tests and integration tests.
from the unit. However, really you could think of those tests are
"functional" or "Technology Compatiblity Kit" type of tests.
But I think the issue of sharing base abstract test code has its virtues even in cases that do real unit tests, maybe in the pure domain areas ...
The DAO tests are focused (I'm guessing) mainly on verifing that the
DAO's for multiple implementations work the same with all providers.
And then, for whatever provider specific code you have, those are in
unit tests bundled in the provider project. So, if you have a
prototype-tck project, then it doesn't look so bad!
ok
I indeed think that I will keep my first thought of haven a separate project for the tests, which could then be depended upon by the concrete implementations of my DAOs.Check out Fulcrum Security where I have multiple providers and I verify they work regardless of provider: http://jakarta.apache.org/turbine/fulcrum/fulcrum-security-api/xref/org/ apache/fulcrum/security/model/test/package-summary.html
I just tossed the tests into the security-api project which in retrospect was icky, and I would have liked to have kept it totally separate. Individual projects just extend the abstract test classes to provide the startup and shutdown. Although, I think I like your approach better, but I wanted an all java solution...
Thanks for the answer,
cu,
-- Laurent
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
