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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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) <[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. > > >> > > >> > > > > > > > >
