Hi,
I'm fully supporting the idea, as discussed at CukeUp and I have also
started to think about this (actually started to wrap it up as an
article). I have created a diagram showing the important aspects of
the steps in a Gherkin project (from SpecFlow's point of view, but I
hope the picture fits to Cucumber and the other tools too). It's here:
http://dl.dropbox.com/u/51289/BlogAttachments/StepMap.pdf (uses
slightly different namings)
It is another question how much part of this is really necessary for
the completion. I think the best would be to have a basic set that
every tool supports and allow extension points where specialties of
the tools could be stored, in case the editor wants to support them
(eg. in SpecFlow you can scope the step definitions). The alternative
is that every tool manages it's own format, but can expert to the
common format. I'm fine with both.
For this basic feature set, in addition to Aslak's proposal, I can
think of:
- handling steps in scenario outlines (shall we display the steps with
the <parameters> or the expanded ones - the ones with the param will
not necessarily match the regex)
- displaying "unbound" steps
- storing also the table / multiline text argument of the text as
well, or at least a sample of it (e.g. table header)
Other comments:
I don't exactly know how it is with Cucumber, but SpecFlow also
considers the argument transformations when deciding if a step
matches. While I'm sure we don't want to include that in the
completion, we have to be prepared that one step can also match to
multiple step definitions, which complicates the things a little bit.
If we have the exactly the same step (with the same params) used in
the feature files, we should display it in the completion list only
once.
Incremental update: for this we need to store the "origin" of the step
definitions and the step instances, otherwise you cannot remove the
old entries in case of a change.
For the storage format, my vote is for JSON as it is much easier to
use it any platform (e.g. in .NET there is an x64 and an x86 version
of SQLite provider which is an extra maintenance issue). Also better
fits to hierarchical data than RDBMS.
Br,
Gaspar