Spring @DirtiesContext annotation issue

[AlanFoster]

Hi there!

Firstly, I've got to thanks for CucumberJvm - it's really great! Good job on it :)

I was playing about with Hibernate/Spring and CucumberJvm and I noticed that @DirtiesContext doesn't seem to do anything when applied to the Cucumber test runner - it works when running the SpringJUnit4ClassRunner runner though

The use case is : I'm using @DirtiesContext in order to tear down all of the autowired beans that have been 'dirtied' by each feature scenario

Any advice on a work around for this, or if there's planned support for this? :)

Cheers
Alan

[aslakhellesoy]

Hi Alan,

You are the first to request this. This might be related to #448 - I'm not familiar enough with Spring to tell.

In general, if you want a new feature you have to fork the project, add what you want and send a pull request. Would you be interested in helping out with that?

[paoloambrosio]

Hi Alan,

are you really altering the application context (by adding/changing bean definitions) or do you simply want your beans to be recreated for each scenario (scenario scope for the bean)?

Paolo

[AlanFoster]

Thanks for the replies guys :)

@aslakhellesoy I wish I could help out with this one! I'm not really a Spring expert either I'm afraid :(

@paoloambrosio Nope, I don't register any new beans in the application context.
I have an created an instance of a datasource in spring which is then injected into the hibernate session factory - Example application-context.cfg extract

 <jdbc:embedded-database id="dataSource">
        <jdbc:script location="classpath:schema.sql"/>
        <jdbc:script location="classpath:test-data.sql"/>
    </jdbc:embedded-database>

And in each scenario the dataSource's is inserted into/deleted from, which impacts the next scenario

I have also tried other ways of manually making the ApplicationContext dirty during the '@AfterScenario' method, but I didn't have much luck with that either :(

I would love for there to be an easy way to solve this problem, but sadly I'm not a spring expert to be able to contribute a solution.

I would love to hear any feedback on this issue though :)

Alan

[paoloambrosio]

Normally you would use the "cucumber-glue" scope to specify that a bean should be recreated every scenario. The jdbc:embedded-database tag does not support scope declaration though. The DataSource is created using the EmbeddedDatabaseBuilder class. Unfortunately I don't think it can be used in an XML bean file, but you should be able to use a @configuration class:

@Configuration
public class DatabaseBeans {

    @Bean // perhaps (destroyMethod = "shutdown") ?
    @Scope("cucumber-glue")
    public DataSource datasource() {
        return new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.HSQL)
                .addScript("classpath:schema.sql")
                .addScript("classpath:test-data.sql")
                .build();
    }

}

Take a look at this blog post as well: http://blog.springsource.org/2011/02/14/spring-3-1-m1-introducing-profile/

[AlanFoster]

Thank you for the help @paoloambrosio, setting the scope to be 'cucumber-glue' on the dataSource bean was the solution in the end!
I managed to get it working with the XML too :)

For other people that may see this, this was the XML used in the end

    <!-- Note the 'scope="cucumber-glue"' attribute -->
    <bean id="dataSource" scope="cucumber-glue" class="org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseFactoryBean" >
        <property name="databaseType" value="H2"/>
        <property name="databasePopulator">
            <bean class="org.springframework.jdbc.datasource.init.ResourceDatabasePopulator">
                <property name="scripts">
                    <list>
                        <value>classpath:schema.sql</value>
                        <value>classpath:test-data.sql</value>
                    </list>
                </property>
            </bean>
        </property>
    </bean>

It's good to know there was a simple solution; It was certainly a 'gotcha' for me haha

[AlanFoster]

I'll close this issue for now, but feel free to re-open it if you think it it should be linked to #448, as suggested by @aslakhellesoy

Cheers :)

[AlanFoster]

For anyone passing through via Google, there is also an example of this in the Cucumber books :)

[aslakhellesoy]

@AlanFoster what book are you referring to? The Cucumber Book doesn't cover Cucumber-JVM.

[AlanFoster]

@aslakhellesoy Cucumber Recipes has examples of Java, Scala, etc using CucumberJVM :)

[aslakhellesoy]

@AlanFoster I thought that was the book you were referring to :-)

[jmilkiewicz]

Hi

@AlanFoster According to current version (1.1.5) @DirtiesContext works (is applied correctly) only when it is specified on StepDefinition class but not on a Step Definition (method level). Internally Spring Factory creates Spring TestContextManager for each Step Definition class and use the latter as test class (like junit test class). By doing that all registered TestExecutionListners (responsible for DI, DirtyContexts) are run against Step Definition class. The current implementation of cucumber SpringObject does not run all methods of TestExecutionListeners, i.e beforeTestMethod, afterTestMethod are skipped and only beforeTestClass, prepareTestInstance, afterTestClass are executed

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.