Hi Alex, I prefer it, yes. We've extended things like UsingMatchers and UsingMocks for convenience, but I would prefer to avoid extensions of things specific to a particular architecture. It makes it very hard to use them in other frameworks.
For instance, I couldn't untangle Abbot from JUnit so had to write my own Swing harness. There are some people now using that harness independently of JBehave. It's not even really a JBehave class, just something I happened to write alongside it. I would love it if our Spring extensions worked the same way. Cheers, Liz. "Alexandre Martins" <[EMAIL PROTECTED]> 18/06/2007 02:15 Please respond to [email protected] To [email protected] cc Subject Re: [jbehave-dev] Spring extension Hi Liz, sorry for the delay.....I think you can make all those things configuring a spring container a extending UsingSpringContext. But if you prefer Strategy rather than extending, you can use the SpringApplicationContextProvider class inside your tests, easy like this: public class FooBehaviour() extends UsingMatchers { private SpringApplicationContextProvider spring; public void setUp() { this.spring = new SpringApplicationContextProvider( "aplication-context.xml " ); } public void shouldPersistEntity() { Session session = bean( "session" ); Entity entity = session.save(entity); ensureThat(entity.getId()>0); Entity loaded = session.load(entity.getId()); ensureThat(loaded, eq(entity)); } } Cheers, On 6/12/07, Elizabeth Keogh <[EMAIL PROTECTED]> wrote: "Alexandre Martins" <[EMAIL PROTECTED]> wrote on 12/06/2007 15:25:25: > Now related to your lower-level tests for database interaction, I > don't know if I got your idea, but I think you wanna test if your > Hibernate mapping is done rightly, is it? Would you mind send me a > piece of this code? Currently I don't write tests to verify Hibernate, > instead I prefer to write acceptance tests, but I'd like to see what > are you doing. Hi Alex, Client contracts mean I can't send you our code, I'm afraid, but the basic premise is: - Use Spring, get a Hibernate session - Create a domain object, save it - Commit (possibly within an outer transaction, so can rollback after the test) - Load it, check that the reloaded version has the same data as the original. We also check the persistence of relationships between objects. Our behaviour descriptions usually resemble "shouldPersistRelationshipWithChildSheep" and "shouldPersistColourOfWool" (except we're still using JUnit 3, dammit, so it starts with 'test'). My biggest hint is, when you do class equality on Hibernate-loaded objects, use HibernateProxyHelper.getClassWithoutInitializingProxy() - because otherwise, equality depends on lazy-loading, how the object is cached, etc. This also applies to anything in collections, and applies to production code if you do class equality in eg: the .equals() method. That little bug in our code would have been a lot harder to find without these tests! Cheers, Liz. -- Elizabeth Keogh [EMAIL PROTECTED] http://sirenian.livejournal.com http://jbehave.org -- ______________________ Alexandre Martins Nunes http://m.artins.net
