Re: [Springframework-developer] AbstractTransactionalSpringContextTests

[Rod J. <ro...@in...>]

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
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________