Hmm. I got rid of the cleanup threads easily enough, but it didn't
really affect the memory usage. That's what I get for not using a
profiler. At least things are easier to read in the debugger
without all of those extra threads :-)
On 9/6/07, Mike Kienenberger <mkienen..mail.com> wrote:
> > Why do you want all of that mocking stuff?
>
> Because what you described is an integration test, not a unit test :-)
>
> I have both -- the integration tests running against an in-memory
> hsqldb instance and unit tests running without needing to hit a
> database. However, running my integration tests still takes around
> 15 minutes.
>
> Configuring efficient integration tests is much more tricky. You
> either recreate everything which makes things take another order of
> magnitude to run, or you try to "clean up" the important record tables
> in setup.
>
> Configuring a unit test using mock objects is much faster -- you just
> configure your MockDAO to respond to expected method calls and poll it
> afterward to see if the expected method calls were called correctly.
>
> My other issue with integration tests is that I'm using Cayenne 1.1.4,
> and every setup() call to initialize Configuration creates a new
> PoolManagerCleanup thread which won't time out for 60 seconds. That
> makes my integration tests memory intensive -- currently about 1.4Gb
> of memory is required to run some 650+ tests. I just spent a couple
> of hours trying to figure out a nicer way to deal with this, but I
> haven't done so yet. I probably will need to subclass
> DriverDataSourceFactory and PoolManager.
>
> On 9/6/07, Tore Halset <halse..vv.ntnu.no> wrote:
> > 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 - 15:59:15 EDT