Re: [Springframework-developer] AbstractTransactionalSpringContextTests

[Colin S. <col...@ex...>]

As I read Keith's requirements, that's not quite what he was looking for 
in terms of the optional use of transactions. Most of the time the same 
context will be used for tests with and without transactions. So because 
the transactionManager property is there in the base class, there will 
always be a transactionManager even for tests that don't want it.

What would probably work is if there was a boolean switch (default on) 
to use transactions or not use them. However I still see some issues. If 
AbstractFlowExecutionTests does extend 
AbstractTransactionalSpringContextTests, that would mean that if 
somebody doesn't ever want transactions and has no transaction manager 
in the context, they must always turn off dependency checking. This 
might be ok, but is sort of suboptimal.


Rod Johnson wrote:

> Keith
>
> I've added a dependencyCheck property in 
> AbstractDependencyInjectionSpringContextTests.
>
> I've modified AbstractTransactionalSpringContextTests to not use 
> transactions if no PlatformTransactionManager is available. This will 
> only work if dependency checking is off.
>
> Please test this out and let me know if it fits your needs. I don't 
> have time today to do full testing myself.
>
> If it's fine, let me know and I'll complete the documentation for the 
> new features and improve the Javadoc overall.
>
> Rgds
> Rod
>
>>
>> Ideally I'd like to be able to test the Phonebook sample flows, or 
>> any other
>> flows, by extending AbstractTransactionalSpringContextTests, without 
>> being
>> *required* to set a transaction manager and run in the context of a 
>> TX.  In
>> other words, I'd like it to be configurable.  If it's not made 
>> configurable,
>> I'm only left with two options:
>> 1. Scale up Phonebook (or any other flow) to work with a 
>> transactional data
>> source
>> 2. Have a duplicate AbstractFlowExecutionTests hierarchy that just 
>> extends
>> from DependencyInjectedContextTests
>>
>> Neither of these are that great IMO.  The former means I can really only
>> integration test flows that need TX's (yes that will probably be the
>> majority, but...) or I have to mock out the TX Manager.  The latter 
>> means I
>> duplicate flow integration test code, to extend from two different base
>> classes.
>>
>> Keith
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of
>> Rod Johnson
>> Sent: Wednesday, April 06, 2005 6:55 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer]
>> AbstractTransactionalSpringContextTests
>>
>> Keith
>>
>> I will try to make any required enhancements today.
>>
>>
>>> - the ability to DISABLE dependency checking by object for the 
>>> autowired test - sometimes defaults really do make sense, why always 
>>> require a set method to be called for each public setter?
>>
>>
>> I've added a dependencyCheck property which you can call in a 
>> constructor. I've preserved the default dependency checking, which I 
>> think is useful.
>>
>>
>>> - the ability to turn off/on transaction management - right now 
>>> AbstractFlowExecutionTests is runnable only in the context of a 
>>> database transaction.  While this is great and all, if I want to 
>>> integration test flows outside of any transactional context, I'm 
>>> screwed.  I can't exactly subclass DependencyInjectedContextTests, 
>>> as I still WANT THE OPTION of being able to test flows in a 
>>> transaction context - for the flows that demand it.  But the current 
>>> structure doesn't give me that choice.
>>
>>
>> I don't quite understand what you want here. Can you please be more 
>> specific? How would you drive this option?
>>
>> Rgds
>> Rod
>