`given` doesn't allow raw values

Question

`given` doesn't allow raw values

timbertson opened this issue 9 years ago · comments

It's claimed in the README that this should work:

given('name', 'James Sadler');

But I get:

Error: definition of "name" is not a function
    at defineOneVariable (given/lib/given.js?body=1:128:15)
    at given (given/lib/given.js?body=1:156:16)

It works if I use the long form:

given('name', function() { return 'James Sadler'});

But that's not very convenient for non-coffeescript users.

James Sadler · Answer 1 · Thu Jan 07 2016 11:26:32 GMT+0800 (China Standard Time)

Hi there. Apologies for the late reply, I must have missed the email notification. I'll look into this.

Raymond Maung · Answer 2 · Tue May 17 2016 07:58:31 GMT+0800 (China Standard Time)

given intentionally stopped allowing raw values. It is as intended, README needs to be updated.

Tim Cuthbertson · Answer 3 · Fri May 20 2016 05:34:24 GMT+0800 (China Standard Time)

Ahh, I see. Well while I can see the logic for coffee script, it's pretty verbose to require all values to be functions in js. Could there be an explicit shorthand for defining a raw value that doesn't require a function definition?

Raymond Maung · Answer 4 · Fri May 20 2016 21:14:26 GMT+0800 (China Standard Time)

Maybe add

given.raw = function(data) {
  return function(){ return data; };
};

Then given('name', given.raw('James Sadler')});?

Tim Cuthbertson · Answer 5 · Sat May 21 2016 15:39:06 GMT+0800 (China Standard Time)

Or even less verbose, `given.raw(name, value)` ?

Raymond Maung · Answer 6 · Sat May 21 2016 20:51:17 GMT+0800 (China Standard Time)

I recall there is a reason the raw values are not allowed and forced to delcare function.

To illustrate the challenge, then consider the following scenario:

given({
  first: "James",
  last: "Sadler",

  person: {
    name: this.first + " " + this.last  // <== what is "this" now?
  }
})

Then this in nested object is evaluated too early before giving given a chance to rebind this. By forcing to use function, Given can decide what this should be.

Maybe @freshtonic can confirm the reasoning.

James Sadler · Answer 7 · Sun May 22 2016 09:25:12 GMT+0800 (China Standard Time)

@timbertson @raymaung see this commit for why it was removed as a feature: 6f70430

I'd accept a PR for a given.raw(...) implementation. It wouldn't advantage a CoffeeScript user because -> is short anyway, but for a JS user function() { return "myvalue"; } is a bit inconvenient.

James Sadler · Answer 8 · Sun May 22 2016 09:42:42 GMT+0800 (China Standard Time)

I've just remembered why this isn't a good idea. It's because lazy evaluation won't work as one would expect.

given("foo", function() { return 123; });
given("bar", this.foo);  // this.foo evaluated immediately (not lazily)

given("foo", function() { return 456; });
given("baz", function() { return "foo value: " + this.bar; });

this.baz; // => "foo value: 123" instead of "foo value: 456"

This was a major pain point suffered by myself and my colleagues where I used to work, so I removed the non-lazy values. Even given.raw(...) won't solve it.

James Sadler · Answer 9 · Sun May 22 2016 09:43:44 GMT+0800 (China Standard Time)

I'm closing this issue, given the reason above. I'll reopen it if someone comes up with a reasonable, elegant workaround to the problems introduced.

Tim Cuthbertson · Answer 10 · Wed May 25 2016 09:22:18 GMT+0800 (China Standard Time)

Maybe I'm expecting too little, but this doesn't really seem like much of a problem to me. A raw value is clearly non-lazy. I know what this is at the time I'm defining values, and it certainly isn't the given context object. So no, this example wouldn't work, and I don't think it could ever be made to work. But I would never have expected it to, either.

I guess the confusion here stems from the fact that there's always a this in javascript, but it requires users to mentally keep track of what this means in each scope, or else they run into issues like this. Perhaps one solution is to change how value functions are called.

What about if the context were given explicitly as an argument, rather than provided implicitly as this?

given('fullName', function(ctx) { return ctx.firstName + " " + ctx.lastName })

That way, nobody would ever think raw values could depend on other values since there's no way to access this ctx object outside of a lazy value. You need to do a little extra work to name the context, but only when you're depending on other properties. And the user no longer has to mentally track what this refers to various scopes.

James Sadler · Answer 11 · Wed May 25 2016 10:05:47 GMT+0800 (China Standard Time)

I agree a better API would use a context instead of this for the definition functions. I was aiming for something more elegant, but clearly that has drawbacks such as remembering what this refers to in different parts of the code.

It may even be feasible to introduce optional context support without breaking backwards compatibility. By all means submit a PR. If it does break backwards compatibility then I'll release a version 2.0.0.

Sound reasonable?

Tim Cuthbertson · Answer 12 · Wed May 25 2016 13:03:39 GMT+0800 (China Standard Time)

Great - I've had a go, here's a PR: #5

I couldn't think of a good way to make the explicit context support backwards-compatible. Well I mean you could do definitionFn.call(env, env), but that probably only adds to the confusion since now there would be two ways to do the same thing.