Also it just occurred to me that DataContext is the only place where
DataObject instantiation happens. So how about creating a testing
subclass of DataContext that override all methods that internally
call private static method "newDataObject".
Internally an overridden method may transform the name according to
some rule. E.g. from createAndRegisterNewObject:
...
String objClassName = entity.getClassName();
DataObject dataObject = null;
try {
dataObject = DataContext.newDataObject("Test" + objClassName);
}
catch (Exception ex) {
throw new CayenneRuntimeException("Error instantiating object.",
ex);
}
Andrus
On Jul 1, 2005, at 12:18 PM, Andrus Adamchik wrote:
> I just started reading this thread, sorry if any of this has been
> mentioned already... Anyway, I can see two solutions:
>
> 1. Use external object that generates random test data and injects
> it to the DataObject via the setters. IIRC CRUD tester by Mikaël
> Cluseau does that:
>
> http://objectstyle.org/cayenne/lists/cayenne-devel/2005/06/0036.html
>
>
> 2. Use class generator. But use a custom template for TEST _DO
> class. You will end up with two sets of superclasses - one for test
> DO and one for real DO (did anyone mention this already?). This
> solution takes advantage of the fact that Cayenne entity model is
> external to Java.
>
> I guess the limitation with (2) is that Eclipse may get confused.
> But if you don't have to call your extra test methods outside of
> generated class (do you?), you can make the whole thing
> transparently with Ant.
>
> Andrus
>
>
>
> On Jun 30, 2005, at 3:04 PM, Kevin Menard wrote:
>
>> Yet another for the experts out there :-)
>>
>> I have a DataObject. I'd like to subclass it for a test class I'm
>> writing. The subclass is quite trivial -- it simply has a static
>> var that it increments so I can encapsulate feeding unique values
>> to the DataObject. So, the subclass really only overrides the
>> DataObject's constructors, passing up some unique values. I
>> guess what it's doing is irrelevant -- it's just sufficient to
>> know it's not mucking with the DB.
>>
>> Cayenne doesn't seem to like trying to commit this DO, since the
>> subclass isn't registered in the mapping file. Is there any way
>> around this, other than restructure my tests? It would seem as
>> though if the subclass were not trying to persist any additional
>> information, that Cayenne should be happy. Or does this all fall
>> under the VI work that Mike has been doing?
>>
>> Thanks,
>> Kevin
>>
>>
>>
>
>
>
This archive was generated by hypermail 2.0.0 : Fri Jul 01 2005 - 12:31:23 EDT