> Paolo
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/q95I0s1r80g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Posting rules: http://cukes.info/posting-rules.html---
You received this message because you are subscribed to the Google Groups "Cukes" group.To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/q95I0s1r80g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cukes+un...@googlegroups.com.
I'm already working on this, aiming at using spring framework bean initialization procedure: something I never didi before but I'm pretty sure is somewhere in there :)
EITHER:public class MySteps {@Injectprivate MyData myField;// snip}OR:public class MySteps {private MyData myField;@Injectpublic MySteps(MyData data) { myField = data; }// snip}Shouldn't we aim for the same behaviour in the Spring integration?
EITHER:public class MySteps {@Injectprivate MyData myField;// snip}OR:public class MySteps {private MyData myField;@Injectpublic MySteps(MyData data) { myField = data; }// snip}Shouldn't we aim for the same behaviour in the Spring integration?Here we should IMHO distinguish between the two types of dependencies. First type is beans defined in the tested spring context (via @ContextConfiguration or @ContextHierarchy sprint test annotation). I guess the initial message in this topic was about such case. Constructor injection does not seem to be supported by Spring's SpringJUnit4ClassRunner either, so I would not consider lack of this functionality as a major loss.What is much more interesting for the cucumber tests is the second type of the dependency - injection of the StepDef files. It is not supported by the Spring implementation at the moment. Looks like it was or intended to be supported via the custom cucumber.runtime.java.spring.SpringFactory#applicationContext , but at least since the transition to the Spring's TestContextManager, this custom context doesn't seem to have any effect (together with GlueCodeScope and GlueCodeContext).
My cucumber tests at work rely heavily on the feature of StepDefs injection and I had to opt for the PicoContainer-driven cucumber for the time being. I tried to hack around the cucumber-jvm SpringFactory, and the best result was so far to load test contexts mentioned at @ContextConfiguration into the cucumber's SpringFactory#applicationContext and register StepDefs there, but this smells hacky and besides the functionality of DirtiesContextTestExecutionListener and ServletTestExecutionListener from the org.springframework.test.context.TestContextManager#DEFAULT_TEST_EXECUTION_LISTENER_CLASS_NAMES should be replicated.I believe the problem with the Spring transactional hooks might also be related to this discussion, see https://github.com/cucumber/cucumber-jvm/pull/649 .
AFAIK, to get StepDefs injection to work (in v1.1.4-v1.1.6), the step definition classes to be injected need either:
- to have the @Component annotation, or
- to declared as beans in the xml file specified in the @ContextConfiguration annotation (usually "classpath:cucumber.xml").