Bug 150231

Seems like something we should support in the IDE, targetting 7.0. I'll take care of the testrunner part at least, not 
sure yet who will handle syntax editing / navigation for this.

Also (from http://forums.netbeans.org/topic3476-15.html):

- launch features from tree view (Ã  la "RSpec Test", "Test", ...)

- navigation from scenarios to the corresponding steps

- switching/configuring "language"

Have you started to work on this feature? I was thinking to add Syntax highlighting for *.feature .
I found http://netbeans.dzone.com/tips/quickstart-guide-language-supp to help me, do you have any other tutorial?

I haven't started to work on this yet, syntax highlightning for .feature files would be very welcomed! Let me ask 
around whether there are other tutorials on the topic, I'll post them here then.

I too would love to see this implemented. Currently, my cucumber steps give these syntax warnings: "Ambiguous first
argument; make sure."

The following (draft/beta) of the RSpec/cucumber book should help - I'm not aware of any others.

http://www.pragprog.com/titles/achbd/the-rspec-book

Also the following real world use-case should give some opportunity to exercise some practical workflows:

http://drnicwilliams.com/2009/03/26/testing-outbound-emails-with-cucumber/

Hope this helps?

Some thoughts... yes I know this should be written up as a Cucumber 'feature' ;)
But I'm still coming to terms with this and haven't used it in anger yet. 

- Switch between spec-file and feature-file, by matching names, with CTRL-SHIFT-DOWN.

The RSpec book, currently available as a draft/beta, uses a command line 
version of the matermind game as a example of the intended workflow.
Following this example gives some idea of desirable IDE behaviors. Perhaps the 
same project and steps could be replicated in a howto/tutorial demonstrating how
the NetBeans IDE makes life more fun ;)
 
This book also sets out some suggested name conventions, relations between 
files, spec, features, steps, Ruby classes and methods.

My take was as follows:
I'd try to setup such that I have three code editing panels open.  
Two columns one of column divided in two:

/-----------\
|     |  2  |
|     |     |
|  1  |-----|
|     |  3  |
|     |     |
\-----------/

1) Ruby code window (ruby files)
2) Cucumber window (feature files and step definition files)
3) Rspec window (spec files)

Going 'by-the-book', one common work flow would be:
1) Run a Cucumber feature file with a nonexistent step:
   - The Cucmber window is active.
     - The step definition file is opened in a tab, and given focus.
       - If no such file prompt to create one.
   - The step definition code snippets that Cucumber generates are appended to 
     the step definition file.  This file is NOT saved automagically by default
     Should this be configurable?  Alternatively, the code snippet is shown in 
     the std-out window/panel.
2) Run a Cucumber feature file with a failing step:
   - Cucumber window opens the step definition file in a new tab, makes the tab 
     visible, scrolls to, and highlights, the line in the failed step.
   - The RSpec window is active.
     - The RSpec spec file of the Class/Module which threw the error in the 
       step definition file, is opened in a new tab.
         - If no such file prompt to create one.  Make configurable whether to 
           issue this prompt or not.
3) Run a failing spec: 
   - RSpec window selects the spec file's tab, or opens it in a new tab, scrolls 
     to and highlights the line in the failed example.
   - The Ruby code window is active
      - The class's Ruby file is opened in a new tab.
          - If no such file prompt to create one.  Make configurable whether to 
           issue this prompt or not.
      - Scroll to the method in the failed example.  
          - If no such method exists scroll to method_missing.  
          - If that does not exist in the class scroll to initialize().  
          - Finally, if that does not exist scroll to the class def.

Thanks for the ideas, they seem useful - even more so as I haven't yet had a chance to make myself familiar with 
Cucumber, so this is much appreciated. I'm not sure yet when I will get to implement this, I'll keep you posted when 
that happens and will probably ask some questions too.

OK, so I'll continue to jot observations/behaviors/use cases:

Conventions in the naming of feature, step and example (spec) files:

 - The Cucumber best-practice advice seems to be 'Don't tie steps to features' 
   - Store steps in a file named after the Ruby Class or Module it relates to, 
     or use a name that reflects the application domain.
   - This also allows an IDE to automagically jump from a Cucumber step file to the  
     correct RSec (example) file, provided the spec files are also named 
     after the Class, Module or Domain they relate to.
   - When a feature is run by Cucumber it outputs data that should reveal the 
     step file names and locations.

This should permit starting with a feature file and resolving which files  
contain the step and examples we are interested in for that feature - the key is 
for step files and spec (example) files to share name and content conventions.

New feature file template:

Feature: 
  In order to 
  So that I can 
  As a 
  I want to 
  So that I can 

  Insert a more prosaic overview here.

  Scenario Outline:
    Given
    And
    When
    And
    Then
    And
  
  Scenarios:

I have found that using cucumber does make me more productive.  
Developing in the order of feature-steps-specs-code -> feature... 
This higher level of output, and more rapid progress has meant that it
became neccessary to develop some means of tracking a global view just where 
I was up to.... for more 'delicate/subtle' code I can get fully absorbed for a 
while and lose the focus my mental image of the state-of-play of a 
feature/steps/specs/code.
This resulted in me manually maintianing a features.index file - perhaps more 
accurately called a features.status file.  Some notes I jotted down:

The first line of feature files begin with 'Feature:' and describe the feature.  
This means a 'features index' can be parsed from the feature files listing 
built by recursing into the features folder.
A tabular feature index listing could be refreshed, saved, loaded and each entry 
hyper-linked to the feature file.
Given a feature file can be related to steps and examples (spec files), it is 
useful productivity aid to visually record against each row in the table/index 
what the state the feature, step, example and Ruby code is in.  These 'state'
indicators are, of course, set manually.

For example:
In the folder 'features' (at the same level as lib and spec), I now manually 
mantain a file: features.index
The contents of which are, for example:

/ fname.feature
#*** Feature: the first feature's description 
/ This feature needs to be re-thought....
/ ideally we eliminate it!
/ other_name.feature
*    Feature: the second feature's description 
/ another_name.feature
#*   Feature: the third feature's description 
/ yet_another_name.feature
##** Feature: the last feature's description 

The key to the file is:
/ Comment indicator
# Completed indicator
* WIP indicator

The positions indicate one of 
 - feature (first character)
 - step (second position)
 - example (third position)
 - ruby code (fourth position)
 - blank (fifth position, an visual aid)

In the above example the "first feature's" feature description saved in the file
fname.feature.  This feature description is written and the steps, examples and 
ruby code are still works in progress (the outside-in, red-green-refactor process).
The "last feature's" feature description and step definitions are complete. The 
examples and ruby code are still being worked on (probably a refactoring stage).
The "second feature's" feature definition is still being worked on.
etc.

One possibility is to adapt Netbeans Task List to report this information - but 
that would still mean you have to hand edit the features.index file.... :(

So far I found this necessary since the features files can grow and as you 
write one you realise you need to alter, create or remove another.
This also helps working out where you are at if you leave a project for a while.

I suppose now the IDE workspace profile would look as described previously, 
but with a "Features Status" window floating or docked alongside the output 
window.... :)

I figured I should post this here so that folks become aware of this plugin:

http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=17412

There's also another plugin here:
http://members.chello.at/server/modules.html
It seems that it has even more features.

There is another Cucumber plugin. See http://plugins.netbeans.org/plugin/46231/cetriolo