Fix scala

[aslakhellesoy]

APIs were refactored again, so the code broke since neither of us know enough Scala to fix it.

[aslakhellesoy]

@dwskoog - is this something you can help us fix?

[dwskoog]

Working on it now. Btw, the cucumber-java pom has a deep hate for Windows thanks to that antrun task. Oh how I wish I had something other than my windows laptop right now...

[dwskoog]

Okay, my Groovy-fu is a bit weak, but for posterity: /{$basedir}\subdirectory\another/ is how you make a string literal safe for ant-run's groovy task under windows... which of course breaks it horrible on every OS without retarded file separators. I'll make sure not to taint the check-in with that evil.

[dwskoog]

@teigen is dead on with his answer. The problem is that nested objects/classes don't have nullary constructors because of how Scala handles the scoping details at the jvm level.

There is still a bit of an issue about how the ScalaDsl derivatives are loaded though. It's fairly odd from a Scala POV to have the StepDefs in a class, but the current loading scheme requires it since we're reflecting into public nullary constructors. Given an object Example extends ScalaDsl that would generate a class Example$ which only has a private nullary constructor so it blows up. The right way to get your hands on it is via Example$.MODULE$

[aslakhellesoy]

@dwskoog are you saying there might be a more idiomatic way to declare step definitions in Scala? Something more similar to Ruby/Groovy/JavaScript/Python?

If so, would you be interested in adding support for it?

[teigen]

I wouldn't say its odd to to have step defs in classes, but I agree its odd not to allow them in objects.
Another fun project would be to allow step definitions in scala scripts which would let you organise step definition just like the ruby cucumber api

[dwskoog]

@aslakhellesoy It's fairly weird to me that class SomeStepDefs extends ScalaDsl ... works fine but object SomeStepDefs extends ScalaDsl ... spits out the suggestions about how to implement the steps. The snippet that is printed on the console looks exactly like what would be in the object as far as the Given-When-Then lines go. Let me see if I can clear that up sensibly.

The whole issue about making the DSL truly fluent is way out of scope for the 1.0 release. Best to get some explicit feedback from the scala community to figure out where to take that issue.

[dwskoog]

@teigen I get a feeling of impedance mismatch between the declarative feel of the DSL and having steps in classes. When I write out a Given(..) {...} for example, to me that's akin to a routing statement and nothing that makes real sense in terms needing an instance of something.

[teigen]

@dwskoog the classes are instances in a world.
For step definitions that manage mutable state this is quite important.
You also need isolation if things are to run in parallel which is now the default for test execution in sbt.

But like I said, I completely agree that object should be supported and the current behavior with objects is very far from what one would expect

[dwskoog]

@teigen ah, I see why now. Definitely better than the gross reflection abuse you'd need to pull off to hide all of that away from end users.

[aslakhellesoy]

This is fixed on master - thanks @teigen. The object DSL discussion can continue in #156.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.