Hello.
My junit setup creates a database with all its tables and basic
schema and then all of the cayenne-related tests operate on that
temporary db. It is pretty much like cayenne junit tests before the
move to maven, but a bit simpler. The junit tests are started when a
developer wants to and periodically on our development server. It
tests everything with both PostgreSQL and Derby.
Why do you want all of that mocking stuff?
- Tore.
On Sep 5, 2007, at 17:10, Mike Kienenberger wrote:
> 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) <de..ayenne.apache.org> 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.
>>
>>
>
This archive was generated by hypermail 2.0.0 : Thu Sep 06 2007 - 14:24:55 EDT