Support custom interfaces

[ckedwards]

It would be nice if wdio-mocha-framwork supported custom mocha interfaces.

My use case is rather complex and I wanted to "extend" describe to handle some logic for the user (setting up the connection to our benchmarking service and closing the session after the test is done). The reason why I didn't want to use beforeSuite/afterSuite is because I didn't want all suites to create sessions.

My problem is that wdio-mocha-framwork rejects my interface because it is not in the INTERFACES object. I was not sure what the wrapping commands in fiber context is for (though it looks need) and I haven't looked into it too much. However I did try adding my interface to the INTERFACES object as a hack and it seemed to work.

Does this seem like a reasonable request?

[christian-bromann]

Does this seem like a reasonable request?

Yes absolutely

[ckedwards]

Here are my current thoughts on the subject.

Require a static variable on the interface, something like description. The description could be a string or an object. So if are just "extending" bdd you could say description="bdd", but if you have some some completely alternate interface you would need to be more descriptive.

The object would look like this:

description: {
    hooks:["beforeEach", "foo", "bar"]
    test: "it"
}

Example file:

var Mocha = require('mocha');


module.exports = Mocha.interfaces["test-interface"] = function(suite) {
    .. Normal logic here...
}
module.exports.description = "bdd";

Example file 2:

var Mocha = require('mocha');


module.exports = Mocha.interfaces["test-foo-interface"] = function(suite) {
    .. Normal logic here...
}
module.exports.description = {
    hooks:["foo", "bar"],
    test: "HiYa"
};

Then wdio-mocha-framework adapter would process this description wrap it appropriately. The static INTERFACES descriptions would change for consistency.

I don't mind looking into this if the plan looks good to you, but it might be a little while before I get to it. I am guessing I have a unique use case an no one else is clamoring for this one though.

We could also optionally default to bdd, but that seems potentially dangerous as not wrapping the needed functions would cause unexpected behavior. I think that throwing an error when description is not specified would be a better option.

[christian-bromann]

@ckedwards PRs are welcome.