Step definitions don't do anything with regexp matches

[jowers]

Currently the when a step_definition is matched, there is no substitution done with any matches, so it's only really useful for full string matches at present.

[jowers]

I'm going to have a go at this one next - it's a bit limited at present without the ability to re-use steps with different values

[mattwynne]

Top man! Hopefully you can use the unit tests to help TDD it out in the TCL framework, but it would be nice to have a feature to document it as well, I think.

[jowers]

I've written the feature already :-) - that's the easy bit.

I think I can get something that looks like:

Given {^Passing (\d*)$} {number} { puts "something here $number" }

which follows the ruby step definitions quite nicely. But I may have to do a bit more work to avoid having to pass in an empty object for the case with no matches...

[mattwynne]

Great - well if you push the feature into a PR then we can talk about it there.

What about when the regexp has more than one capture group?

Also, have you considered what we'll do about DataTables and DocStrings? I haven't. They become implicit parameters, e.g.

Given this long string:
  """
  hello there
  """

Given /this long string/ do |string|
  expect(string).to eq "hello there"
end

[jowers]

Ok, I've created a pull request for basic parameters.

I have thought about tables, but only as far as "we'll need to sort out something with tables".

[mattwynne]

Fixed by 4144e8447e3c4eeffcbf09c8753a77ed01bde957