Comments on: Integrating FitNesse with Spring http://agileshrugged.com/blog/?p=33 Thoughts about Agile Software Development in the Real World. (and some other stuff). Wed, 01 Sep 2010 12:44:00 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Nayan Hajratwala http://agileshrugged.com/blog/?p=33&cpage=1#comment-663 Nayan Hajratwala Fri, 18 Apr 2008 02:02:01 +0000 http://agileshrugged.com/blog/?p=33#comment-663 Thanks for your response, Darren -- I'll have to take a look at suite fixture again. Thanks for your response, Darren — I’ll have to take a look at suite fixture again.

]]> By: Darren Bishop http://agileshrugged.com/blog/?p=33&cpage=1#comment-656 Darren Bishop Thu, 17 Apr 2008 14:56:39 +0000 http://agileshrugged.com/blog/?p=33#comment-656 Hi, I followed your comment left on 'The magic ingredient for the FitNesse, Spring and Hibernate TDD soup' to your blog. It sounds like you missed a gem when you skipped past the SuiteFixture. You should have really played with it; while I am yet to perfect it, it is very useful in managing test runs. I would typically load the Spring context in a SuiteFixture derived class if, for example, the validity of the Spring configuration (I'm really talking about the system/application under test now) is within the scope of the test. Then for each test case, I inject what is needed from the Spring context, again, typically calling testCaseFixture.setSystemUnderTest(someSpringBean). This works reasonably well for me, however I do have issues with Fixture life-cycle management (automatic setUp and tearDown), but I am not sure if that is a problem related to what we discuss here. I'll have to look into that transaction stuff next, sounds v.useful. BTW, I/we use FitLibrary, just in case that holds any significance. Best, Darren Hi,

I followed your comment left on ‘The magic ingredient for the FitNesse, Spring and Hibernate TDD soup’ to your blog.

It sounds like you missed a gem when you skipped past the SuiteFixture. You should have really played with it; while I am yet to perfect it, it is very useful in managing test runs. I would typically load the Spring context in a SuiteFixture derived class if, for example, the validity of the Spring configuration (I’m really talking about the system/application under test now) is within the scope of the test. Then for each test case, I inject what is needed from the Spring context, again, typically calling testCaseFixture.setSystemUnderTest(someSpringBean).

This works reasonably well for me, however I do have issues with Fixture life-cycle management (automatic setUp and tearDown), but I am not sure if that is a problem related to what we discuss here. I’ll have to look into that transaction stuff next, sounds v.useful.

BTW, I/we use FitLibrary, just in case that holds any significance.

Best, Darren

]]>