Some more sugar, and a bugfix.

[Goutte]

Feature: int and num step parameters are automagically unserialized. Bugfix: scenario.passedTests was empty.

[Goutte]

Extracted the boilerplate generation logic from the runner. (I needed to use it in my dartium runner)

Drunken commit, back to the party ! :tropical_drink::tropical_drink::tropical_drink:

[Goutte]

Notable : I changed the number of words from 4 to 5 used in setpdef function name during boilerplate generation, just to see if it was better. I think it is. But maybe you chose 4 for a reason, so I can revert that if you want.

We should continue on the OO design pattern and make a DherkinRunner or something. Two, even. One with workers, one without (because in Dartium it is too soon).

I'm working on propagating the exceptions and stack traces up the chain of Statuses, to the runner.

[Goutte]

Also, not sure about the name Status. Maybe Output ? What do you think ?

[dkornishev]

We should continue on the OO design pattern and make a DherkinRunner or something. Two, even. One with workers, one without

Yep, I agree.

Notable : I changed the number of words from 4 to 5 used in setpdef function name during boilerplate generation, just to see if it was better. I think it is. But maybe you chose 4 for a reason, so I can revert that if you want.

No particular reason. I'll take a look.

2014-06-21 18:31 GMT-04:00 Antoine Goutenoir notifications@github.com:

Also, not sure about the name Status. Maybe Output ? What do you think ?

— Reply to this email directly or view it on GitHub https://github.com/dkornishev/dherkin/pull/17#issuecomment-46766667.

[Goutte]

While we're at it, we should re-consider the signature of the stepdefs. What's the difference between ctx and params ?

@StepDef("I am (white|black) in a game of size ([0-9]+)")
i_am_$player$_in_a_game_of_$size(params, {pyString, <tableColumnA>, <tableColumnB>, ...}) {
  assert params[0] is String;
  assert params[1] is int;
  // and we forbid table columns to be named "PyString", it's not a big sacrifice
}

Actually, I think a FeatureContext or DherkinContext class to extend with stepdefs would be more flexible and allow for easier context handling (I need external context handling to "swap" the AI that's being tested). Right now I'm writing into global variables, and it's not pretty.

[dkornishev]

Params is that is matched in the gherkin. Ctx was my work-around to inject the table.

Best thing would be if stepdefs could just take a table optional param. Also would be nice if stepdefs could take gherking params separately, like ruby-cucumber

@StepDef some_step(arg1, arg2, arg3, {colum1, column2, column3, table})

I don't quite remember why I didn't do it that way, but I'll take a look now.

2014-06-22 12:00 GMT-04:00 Antoine Goutenoir notifications@github.com:

While we're at it, we should re-consider the signature of the stepdefs. What's the difference between ctx and params ?

@StepDef("I am (white|black) in a game of size ([0-9]+)")iam$player$_in_a_gameof$size(params, {pyString, , , ...}) { assert params[0] is String; assert params[1] is int; // and we forbid table columns to be named "PyString", it's not a big sacrifice}

Actually, I think a FeatureContext or DherkinContext class to extend with stepdefs would be more flexible and allow for easier context handling (I need external context handling to "swap" the AI that's being tested). Right now I'm writing into global variables, and it's not pretty.

— Reply to this email directly or view it on GitHub https://github.com/dkornishev/dherkin/pull/17#issuecomment-46784772.