Improve parser testing support about gherkin2

[aslakhellesoy]

What do you think is hacky about it? I think a mock based approach where we expect certain events is good. Do you see any problems with that approach or are you referring to how it's currently implemented with the spec's #scan method? (I think that can be improved).

[msassak]

The spec's #scan method. It can be removed in favor of a before block that sets up @Listener and @table. I was also thinking of writing some custom matchers for use with the listener to enable writing specs like

parsing("|a|b|\n").should find(3).rows
parsing("Feature: foo").should find_feature("foo")

or something like that, but that might be more trouble than it's worth.

[aslakhellesoy]

Let's wait with custom matchers until we see some repetitive patterns that can't be solved nicely without matchers. For features it could be something along the lines of:

@listener.should_receive(:feature).with("Feature", "foo")
@listener.should_receive(:scenario).with("Scenario", "bar")
@listener.should_receive(:step).with("Given", "bar")
@parser.parse("Feature: foo\nScenario: bar\nGiven bar")

Think that could work?

[msassak]

For sure! That's close to what's in feature_spec.rb right now as it is. I'll move everything over to that and push later tonight.

[aslakhellesoy]

Mike, can we close this now?

[ghnatiuk]

I'm looking into creating a TestListener that outputs something like to_sexp does in cucumber. As the feature files we're parsing get longer, I'm finding it harder to correctly ensure proper message reception and counts, particularly in regards to ordering and ensuring only a single message reception.

I'd like to be able to do something like:

@listener.messages.should == [
    [:feature, "Feature", "This is a feature\n  With multiple lines", 1],
    [:comment, "This is a comment", 3],
    [:scenario, "Scenario", "This is a scenario, 4]]

by simply appending all calls to the TestListener to a list in the order they're received. It would allow for simple assertions, and provide far better output than the current method when the assertion fails (e.g. "Mock 'listener' received :feature out of order" doesn't really tell me much about how the rest of the parsing went).

It would, however, provide a level of indirection between the behavior of the parser and the expectations on the interface of the listener. What do you think?

[aslakhellesoy]

I love that idea. Instead of calling it TestListener, maybe we could call it SexpRecorder? It could serve two purposes: Testing and documentation of the Listener API. (It would only have one non-API method: #to_sexp)

[aslakhellesoy]

Come to think of it - it might be easier to implement SexpRecorder with #method_missing, which would render it useless as documentation ;-) (We could always write a different reference implementation. Maybe a pretty printer or something)

[msassak]

I was screwing around with Google AppEngine last night and whipped this up: http://gherkintest.appspot.com. Pretty useless as it currently stands, but the code does contain an UglyPrinter that perhaps we could use as a basis for a reference implementation. :-)

[aslakhellesoy]

OK, I just pushed an implementation of a simple SexpRecorder and wrote one spec using it. I'm a bit busy working on a presentation I have tomorrow, so I won't be converting any of the existing specs...

[aslakhellesoy]

Oooh nice! Is the code open source?

[msassak]

It will be tonight. :-) I used the google-appengine gem, and while it's super-easy to get started, I need to figure out how to create a git repo for a google app without all the extra generated stuff before pushing it to github.

[ghnatiuk]

Perfect! Thanks. I'll close this issue. I'll work through converting the existing specs as I revisit them. Shouldn't take too long.