Mark step as pending programmatically? about yadda HOT 10 CLOSED

There's nothing you can do inside the step, but you can redefine your step as follows...

library.then(/I do something/);

Is that sufficient?

from yadda.

Just realised my previous answer was wrong. The step completes but isn't recorded as pending. It would be nice if it was.

FYI mocha does have the ability to programatically skip tests.

it('some test', function(done) => {
  this.skip();
})

However you'll find it difficult to get access to "this" from Yadda. I also wouldn't want to couple anything in the core Yadda codebase to mocha. I'll see if I can come up with something.

from yadda.

I've found a way, but wanted to check if it will provide what you need. I'm also not "delighted" with my idea so want to mull it over a little.

In the step level plugin you'll see a "context", which is what you get if you reference "this" from inside a mocha test, e.g.

it('some test', function() {
  this.skip();
})

The step level plugin also contains a sync and async iterators, which is the callback you pass to the step funciton

scenarios(feature.scenarios, function(scenario) {
  steps(scenario.steps, function(step, done) {
    yadda.run(step, done);
  });
});

If I bind the iterator to the context in the step level plugin you should be able to do

scenarios(feature.scenarios, function(scenario) {
  steps(scenario.steps, function(step, done) {
    yadda.run(step, { mocha: this }, done);
  });
});

And then from your steps

library.then(/I do something/, function() {
  this.mocha.skip();
});

The reasons I'm not delighted with it are

1. It relies on binding, which doesn't work with arrow functions (I don't mind too much since both mocha's skip feature and yaddas context feature already rely on binding).
2. Steps without functions will still not be marked as pending, which would have been nice

However I do like that mocha hasn't leaked outside of the plugin and that the change is backwards compatible. I also like that it will work for other mocha features like programatically setting the timeout.

from yadda.

@cressie176 Hey thanks for your quick response! I'm trying to get the context iterator binding to work but for whatever reason I can't seem to get it: iterator.bind(context) doesn't seem to do it. Would you mind pasting your /node_modules/yadda/lib/plugins/mocha/StepLevelPlugin.js with the changes here?

I'm thinking I might just write my own extended version of StepLevelPlugin.js for now and include it and call something like MyStepLevelPlugin.init(); instead of Yadda.plugins.mocha.StepLevelPlugin.init(); in my local yadda.spec.js test.

from yadda.

I pushed to a branch - 9ad9bf7. If it does what you need I'm happy to merge into master

from yadda.

Did you find time to try the branch?

from yadda.

Apologies, I was out of town last week. I have the code checked out on my end but haven't had a chance to run it yet. My feeling is that the step definitions probably shouldn't know about Mocha, but, they should probably have a metaphor for reporting so they can call some kind of skip() functionality. I might be more likely to make a Runner class exposing some subset of Mocha and pass that as the context to Yadda, rather than passing the Mocha instance directly.

That said, I'm not a huge fan of making a bunch of glue classes and boilerplate to prop up this notion of separating concerns. In the end, we're telling Mocha to skip the test! So there might not be any harm in just passing the whole Mocha object to the step definition as you have done in your example.

In an ideal world, I'd like to have full access because we just don't know all the use cases that people will have in the future. Which in my gut tells me that maybe this should be a pattern instead of framework functionality. In other words, as long as developers have a way to pass Mocha (or some of its functionality) to the Yadda step definitions (and maybe an example for doing so) then that should be enough for most situations.

I really like the elegance of your bind() solution, where the user can specify the object representing this to yadda.run(). Your not-delighted reason # 1 with arrow functions hadn't really occurred to me, and I feel like reason # 2 with marking functionless steps as pending might be addressable down the road outside of this quick fix.

So I'm thinking there are two ways to do this:

yours:

// test.js:
yadda.run(step, { mocha: this }, done);

// bottles-library.js:
this.mocha.skip();

vs only exposing certain methods:

// test.js:
yadda.run(step, { skip: this.skip }, done);

// bottles-library.js:
this.skip();

I think that both ways have their merits, so I don't really have a definitive answer as to which is better.

Anyway, feel free to merge it, it will definitely work for me. You've been super responsive so sorry I didn't get back to you sooner.

from yadda.

Hi @zmorris ,

Thanks for responding. I agree with almost everything you've said, but with two exceptions. I no longer think bind was a good idea - it means that steps can't use arrow functions. If I were to write Yadda again, I would try to implement a proper state model similar to react/redux.

I agree having an API to skip tests from state would be a nice feature, but I would have to think of an alternative implementation to bind because of the arrow function problem. Right now it's possible to use arrow functions, but you have to find another way to get the context to the step (e.g. by passing a shared context to the step definition). If I were to bind the step to a runner API there would be no way to use this and arrow functions.

Another concern is that not all test runners are as advanced as mocha and support a skip option. Adding bespoke test runner features might lead to a very confusing API.

For now I'll merge since it doesn't prevent doing something more sensible in the future. I like your alternative syntax of

// test.js:
yadda.run(step, { skip: this.skip }, done);

// bottles-library.js:
this.skip();

But suspect it will need adjusting, since I suspect skip function relies on being bound to mocha. yadda.run(step, { skip: this.skip.bind(this) }, done) is rather confusing, so I'll probably go with

// test.js:
yadda.run(step, { runner: this }, done)

// bottles-library.js:
runner.skip();

Which at least gives de-coulpes the step from mocha in name.

from yadda.

Oh ya bind() always gets me into a uh, bind, in JavaScript since I'm new to it. I think the most important thing for me is that I can pass a context to the step definitions, so I'll defer to you on the details. Good discussion though for the next version of Yadda as well.

from yadda.

I merged the branch and released as [email protected]

from yadda.