Eclipse plugin for navigating between textual and code steps

Please have a look at screencast of this plugin: http://bitbucket.org/szczepiq/givwenzenclipse/wiki/Home

I bet I can change it a little bit so that it integrates easily with jBehave

I totally agree with this.
We've written a partial xtext grammar which gives us fairly trivially an editor with syntax highlighting and formatting. I was hoping to offer it when it was a bit more mature.
xtext seems like a good framework to build extra validation of story files on top of, auto-completion, etc;
but it seems hard in terms of candidate step discovery (look for references from Class associated with story file? Were the step classes actually added? Did another class add them somehow?). Likewise in the other direction.

>it seems hard in terms of candidate step discovery

My friend is experimenting with levenshtein distance to find candidate steps. He might have implemented it already in his project: http://bitbucket.org/loomis/givwenzen-flex/wiki/Home

However, it seems that 'suggesting' candidate steps might be a part of jBehave. For example to help me fix the scenario if I make a typo in a step.

There is already a LD prioritisation strategy (JBEHAVE-247) which can be injected in the StepFinder.

new StepFinder(new ByLevenshteinDistance());

Hi Szczepan - givwenzen looks interesting, would be good to see smth similar for JBehave as JBehave already has plain text scenarios (rather than DomainSteps/Step etc. annotations). I am pretty sure JBehave community would like better Eclipse (and other IDEs) integration.

I think the code available in https://github.com/Arnauld/jbehave-eclipse-plugin makes what you guys are suggesting.
I have two small suggestions for the plugin, but it looks great and it is the one I use today. (https://github.com/Arnauld/jbehave-eclipse-plugin/issues/8 and https://github.com/Arnauld/jbehave-eclipse-plugin/issues/7).

As author of https://github.com/Arnauld/jbehave-eclipse-plugin, here are some updates:

+ Syntax coloring (partially implemented: only narratives, scenario, steps and parameters)
+ Completion has been fixed and improved to work even with parameters partially typed (https://github.com/Arnauld/jbehave-eclipse-plugin/issues/7 and https://github.com/Arnauld/jbehave-eclipse-plugin/issues/4)
+ Outline is partially done (only quick outline for now but outline view will come soon https://github.com/Arnauld/jbehave-eclipse-plugin/issues/22)
+ Quick search feature allow to efficiently search and insert steps while keeping your fingers on keyboard and writing stories
+ Support the "in-trunk" step variants feature (https://github.com/Arnauld/jbehave-eclipse-plugin/pull/18)
+ Jump to declaration ("support for opening declarations of steps from the scenario files")

I have added the following in the issue list:
+ support for finding usages of steps in scenario files from the declaration
+ refactoring support: when editing the annotations, scenarios using the step get rewritten

Feel free to add more suggestions as Gabriel did.

I would probably requires some help for this one:
+ support for opening the declaration of failed steps when running junit
since it would requires an alternate JUnitStories that provides more fine grained tests. Actually the runner create a single test with all stories. It would be nice to dynamically generate one suite per story, in which each step would be a testcase by itself. I'm not yet enough familiar with Junit 4 runner and new suite management. My concerns are about the sharing of the Embedder between the different suite, and the split of a single story into sub-tests.

Tried out version 1.0.5. It was not able to get to work properly, i.e. configure the steps classes which are not found.

Moreover, though, the scan approach may work for POJO classes with default constructors but now for steps classes created by other means, e.g. a CI container.

What we need is to leverage the Embedder as a central point of access for all envs, from command-line to IDEs.

Work is ongoing to provide OSGi support (https://github.com/jbehave/jbehave-osgi).

> It was not able to get to work properly, i.e. configure the steps classes which are not found.

can you provide more information about your issue.

> the scan approach may work for POJO classes with default constructors

Actually no, it is based on eclipse representation of java file or class file. ".java" and ".class" (for classes into jar file) are read into JDT internal representation and allows to scan for the presence of annotations.

> but now for steps classes created by other means, e.g. a CI container.

right, it is not supported.
Even if the Embedder is leverage, it still requires configuration that may not be available in a "passive" project which does not load any configuration, or setup environment. It would require to plug into a "live" environment to retrieve the step definitions.

The steps classes are not found via the JBehave story editor - and the lines are marked with red.

The projects have well formed classpaths, generated by m2e (e.g. the JBehave trader examples).

I've tried to add the corresponding packages to the Preferences > JBehave > Class Scanner, but to no avail.

Any more info I can provide?

Sorry for the late response, i strongly think your only issue is due to the default filtered classes in `Preferences > JBehave > Class Scanner`
make sure to remove the exclude filter `org.jbehave.*` if your sample classes are part of `org.jbehave` package.

Hi Mauro,

I've investigated further on why the trader samples is not properly handled by the Eclipse plugin.
And i've found at least the following plugin issues:

• Removing the exclude filter org.jbehave.* is not reflected at runtime, and requires an eclipse restart to be taken into account.
  Plugin bug ~ Issue 39

• Parameters are defined using the '%' prefix whereas the documentation indicates:

  The simplest default behaviour identifies arguments in the candidate step by the words prefixed by the $character -- http://jbehave.org/reference/stable/developing-stories.html

  Plugin enhancement ~ Issue 40

• Plugin fails to disambiguate steps matching different kind of steps e.g. "Given wind blows" and "When wind blows"
  This is a regression in the plugin.
  Plugin bug ~ Issue 41

Hi Arnauld,

could you please add a BUILD.txt to the project detailing the build process you use to produce the plugin jar, e.g. Eclipse requirements, target env etc ... ?

Also, we should be able to build via command-line, using either Ant or Maven?

Cheers

Build process is actually hand made and not available through command line.
This is mainly because of the eclipse requirement and the lack of documentation on how to build plugin from outside, i also didn't investigate further.

Here is how i'm actually managing dependencies, how i build the plugin and how i'm launching a runtime workspace:

https://github.com/Arnauld/jbehave-eclipse-plugin/blob/master/BUILD.markdown

Building eclipse plugins with maven appears to be rather complicated, I couldn't figure that out when I looked at it a while back for another project.

There is a project called Eclipse Tycho that can be used (I didn't get that working, but maybe you can try it)

http://www.eclipse.org/tycho/

Hi Mauro,
If you're interested, I would be happy to donate the jbehave-eclipse-plugin codebase to the JBehave project.
Feel free to grab it, modify it, rename package as wish, and refactor it. I would be happy to continue in participating on it too

Arnauld

Hi Arnauld,

thank you for you contribution - much appreciated. I've repackaged it, re-licensed it under EPL, and pushed to the jbehave-eclipse git repos:

http://git.codehaus.org/gitweb.cgi?p=jbehave-eclipse.git
https://github.com/jbehave/jbehave-eclipse

A tycho-based build has also been provided (JBEHAVE-795 and JBEHAVE-796).

Mauro