There's a few different ways to look at this. It's true that Cayenne doesn't easily support application unit testing.
However, I'm not sure it's entirely appropriate to do so. What I do is use a DAO pattern for my database operations. Then I mock up a DAO rather than the entire database layer. It's far easier to mock up "myTestingDAO.findUserByUserName()" than to mock up SelectQuery, DataNode, DataMap, DataContext, etc. I haven't quite reached this point in all of my projects, but my goal is to generate Interfaces for each of my Entities. If I have a User entity, then I create a User interface and use that exclusively outside of my DAO. The DAO returns User interface objects rather than User data objects. This then allows me to create a MockUser simply by implementing the User interface. For projects where I don't have entity interfaces, I subclass the User DataObject instead. This isn't quite as clean or workable, but it does help so long as you override every method. For creating Mock objects, I use the cayenne code generator the same way I use it for the DataObjects. I'm finding that there are still some places where integration testing is necessary to catch problems. In Cayenne 1.1.4, I've had an issue where I tried to create a local copy of a modified or a transient object and then commit an object with a relationship to it -- those kinds of problems can only be detected when using the real database layer unless your mock layer knows the quirks. On 9/4/07, Marcin Skladaniec (JIRA) <[email protected]> wrote: > Simplify (junit) testing in cayenne > ----------------------------------- > > Key: CAY-862 > URL: https://issues.apache.org/cayenne/browse/CAY-862 > Project: Cayenne > Issue Type: New Feature > Components: Cayenne Core Library > Affects Versions: 3.0 > Environment: All > Reporter: Marcin Skladaniec > Assignee: Andrus Adamchik > > > Junit tests are becoming very important once the project reaches a certain > point. Cayenne has dozens of junit tests but writing a junit test for cayenne > based application is not easy at all. > > For me the main trouble is when there is no need to fetch or commit something > (like testing GUI or lifecycle events). I tried to reproduce the tests found > in cayenne,but always ended up with problems with mocking up the context, > datachannel, entityResolver, altering the configuration to point to > different db etc. > > To solve that my idea was that one might specify a package in the > CayenneModeler, this package will than be populated with generated a set of > _MockupXXX extends XXX (like _MockupArtist extends Artist, _MockupPainting > extends Painting etc.) and a MockupDataContext etc. There could be a second > set of _MockupEntities for ROP client. > > Another thing is to specify the testing environment with ease. I think there > should be also a possibility to create a "testing" DataNode pointing to a > different database than deployment, and for the DataMap could be related to > the real or testing DataNode at the same time. To choose the testing > environment a system param like -Dcayenne.testing=TRUE could be utilised. > I might have missed something here: is there a simply way of having two > DataNodes for one DataMap ? > > I think that simplified testcase writing feature would be a great advantage > for Cayenne over any other ORM. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
