Menu
▾
▴
springframework-developer
|
From: Keith D. <ke...@in...> - 2005-04-05 17:21:29
|
I am running into issues preparing a simple flow execution test sample for the phonebook app. Specifically I need the following: - 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? - 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. Keith Keith Donald Interface21 - http://www.springframework.com <http://www.springframework.com/> - Spring Training, Consulting and Support - "From the Source" |
|
From: Rod J. <ro...@in...> - 2005-04-06 10:55:01
|
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 |
|
From: Keith D. <ke...@in...> - 2005-04-06 13:14:00
|
>I don't quite understand what you want here. Can you please be more >specific? How would you drive this option? 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 |
|
From: Rod J. <ro...@in...> - 2005-04-07 13:14:52
|
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 ____________________________________________________ |
|
From: Colin S. <col...@ex...> - 2005-04-07 13:38:24
|
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 > |
