Specifying Additional Packages for Test Suite

344 views
Skip to first unread message

Manish Bellani

unread,
Apr 5, 2012, 1:43:13 PM4/5/12
to Cukes
Hello Everyone,

We have been doing ATDD utilizing the Cucumber-JVM and love the
simplicity and flexibility of the framework. I have a specific
question about the package scanning. Back when i was creating a POC
for my company with RC16 there was a annotation @Feature that let you
add additional packages that cucumber would scan for running your
scenario. I found it very useful for defining common step definitions
or even common hooks that span multiple scenarios/features e.g.,
capturing screens shots at the end of each Scenrio.

As of release 1.0.0 i no longer see that annotation is there an
alternative for that? I see Cucumber.Options has the features options
but no packages.

Here's what i had used in the
@Feature(packages={"com.corp.common"}, value = "com/corp/dashboard")
What this did was that in addition to scanning com.corp.dashboard it
also scanned com.corp.common to pick up any common step definition.

Your help is much appreciated.

Thanks
Manish

aslak hellesoy

unread,
Apr 5, 2012, 2:07:26 PM4/5/12
to cu...@googlegroups.com
On Thu, Apr 5, 2012 at 6:43 PM, Manish Bellani <manish....@gmail.com> wrote:
> Hello Everyone,
>
> We have been doing ATDD utilizing the Cucumber-JVM and love the
> simplicity and flexibility of the framework.

I'm glad to hear that!

> I have a specific
> question about the package scanning. Back when i was creating a POC
> for my company with RC16 there was a annotation @Feature that let you
> add additional packages that cucumber would scan for running your
> scenario. I found it very useful for defining common step definitions
> or even common hooks that span multiple scenarios/features e.g.,
> capturing screens shots at the end of each Scenrio.
>
> As of release 1.0.0 i no longer see that annotation is there an
> alternative for that? I see Cucumber.Options has the features options
> but no packages.
>

Try this:

@Cucumber.Options(glue = {"cucumis.sativus", "cucurbita.foetidissima"})

Aslak

> Here's what i had used in the
> @Feature(packages={"com.corp.common"}, value = "com/corp/dashboard")
> What this did was that in addition to scanning com.corp.dashboard it
> also scanned com.corp.common to pick up any common step definition.
>
> Your help is much appreciated.
>
> Thanks
> Manish
>

> --
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>

Manish Bellani

unread,
Apr 5, 2012, 2:53:07 PM4/5/12
to Cukes
Thanks a lot Aslak, it works great. It used to work different with
@Feature annotation though, as it would look in the default package
and the additional glue that you provide. I currently see following
implementation of the addGlue method

private void addGlue(Cucumber.Options options, Class clazz,
List<String> args) {
if (options != null && options.glue().length != 0) {
for (String glue : options.glue()) {
args.add("--glue");
args.add(glue);
}
} else {
args.add("--glue");
args.add(packagePath(clazz));
}
}

It may be naive and i do not understand the complete design of
Cucumber-JVM or the reason why it was done that way. But do you think
it would be ok to refactor it to following?

private void addGlue(Cucumber.Options options, Class clazz,
List<String> args) {
args.add("--glue");
args.add(packagePath(clazz));
if (options != null && options.glue().length != 0) {
for (String glue : options.glue()) {
args.add("--glue");
args.add(glue);
}
}
}

So that it would provide the desired behavior.

Thanks again for the quick answer.
Manish


On Apr 5, 1:07 pm, aslak hellesoy <aslak.helle...@gmail.com> wrote:

Aslak Hellesøy

unread,
Apr 6, 2012, 6:46:17 AM4/6/12
to cu...@googlegroups.com

My thinking was that not providing an explicit glue value would
default to the package, and providing one or more would override that
default.

With what you suggest it wouldn't be possible to "get away" from the
default package, but perhaps that is ok?

What do others think?

Reply all
Reply to author
Forward
0 new messages