Hi, I think you’re mixing two concerns here - one is the steps matching, the other the programming one.
The steps matching layer should be only concerned with matching the textual steps with the methods and the signature should reflect the parameters you chose in the textual layer. This should then delegate to a service layer in which the methods have signatures closely matching the functionality they provide. The Context object should live in the steps matching layer and provide the parameters that are used to access the service programming layer. The steps layer should be as thin as possible. Have a look at the examples - they show how these two layers can interact effectively. Cheers > On 18 May 2016, at 18:36, Laura Ruiz <[email protected]> wrote: > > Thanks for your answer, mauro! > > Look, the reason why we want this is basically good programming practices. > The code is clearer if you can understand what a method needs as input just > by looking its signature. > So far you can look at the method signature and know about the parameters > that are explicit in the step, but to know about the parameters obtained from > the context you need to go into the body of the method. > > We'd like to make these input explicit. So we implemented an aspect that > would take parameters from the context and inject them into the method by > reading its annotations. > > As I said, the problem we have is that JBehave doesn't accept this, as the > number of parameters of the step and the number of parameters in the actual > method are different. > So I'd like to know if there's some way to force JBehave to ignore these > extra parameters by marking them with an annotation or something similar. > > Is it clearer now? > > > On Wednesday, May 18, 2016 at 12:22:18 PM UTC+2, mauro.talevi wrote: > Hi, > > The context is a user defined object so it is not known to JBehave. > > If you want to inject parameters in methods you could use the @Named > annotation, specifying the name-value pairs in the Meta: section. > > That said, it's not clear why you'd want to do this, as the values of the > Context will be already accessible without injection in the signature. > > Could you explain your usecase better? > > On 17 May 2016, at 20:05, Laura Ruiz <[email protected] <javascript:>> > wrote: > >> Hi there, >> >> I'm currently working with JBehave and we implemented a Context object where >> we store data that we need to share between different steps. >> >> Now, we are considering some improvements on this, like explicitly passing >> this data to the methods that implement these steps. >> >> Imagine you have a first step which will create a user and store its >> credentials into the Context. >> These credentials are needed in the second step. We would like to have some >> kind of annotation that allowed us to implement our step like this: >> >> @When("...some step definition which includes some $parameterFromStep") >> public void someMethod(String parameterFromStep, >> @FromContext("userCredentials") String userCredentials) { ... } >> >> >> We tried to implement some logic that would take the parameter from the >> Context and pass it to the method. The problem with this is that JBehave >> doesn't find a method matching this step, as the method has the wrong number >> of parameters (it expects 1 but the method has 2). >> >> So my question is: Is there any way of doing this with the current >> implementation? Is there any way to force JBehave, for example, ignore the >> parameters that are annotated? >> >> I would really appreciate some guidance on this. Let me know if something is >> something needs extra clarifications, please. >> >> Thank you guys. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "JBehave User" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/jbehave-user/0fae230a-b5f6-4dc8-95ff-d3f4bb500ad1%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jbehave-user/0fae230a-b5f6-4dc8-95ff-d3f4bb500ad1%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "JBehave User" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/jbehave-user/6f890c66-d546-46c1-98fa-1e1714ffeb67%40googlegroups.com > > <https://groups.google.com/d/msgid/jbehave-user/6f890c66-d546-46c1-98fa-1e1714ffeb67%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "JBehave User" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/jbehave-user/345FEBE4-3C17-43D4-A715-809B15E66151%40aquilonia.org. For more options, visit https://groups.google.com/d/optout.
