Proposal of expect.call helper syntax about code HOT 16 CLOSED

I can see how this would be helpful. Two things though:

1. I would make the syntax expect(fn).calledWith(this, arg1, arg2).to.throw(...);
2. Why not just use Function.prototype.bind() (expect(fn.bind(this, arg1, arg2)).to.throw(...))?

from code.

about the implem, bind was the idea ;)

from code.

and indeed, your syntax is even better!! :D

from code.

I personally think it's more readable to do the bind by hand. That way you only have to understand native JavaScript, instead of code specifics. It might actually be less to type anyway.

However, I'm open to hearing what other people think.

from code.

One problem of bind is the first argument:
cf hapijs/joi#787 (comment) (by habits I went for null...).

Beside I don't find it more explicit. I feel it cloud test intent which is more calling the function and getting an error, than binding value.

I would also tend to not put this in calledWith. Most of the function not really use this

But for sure, allways better to understand native js! :D

from code.

@cjihrig I started working on this. Shall I open a WIP PR to get feedback, and propose a basis for discusstino?

from code.

after first draft and replexion was more thinking about something like:

`expect(fun).call.with().on().to.throw()``

The with and on being facultative.

A return(value) could also be added to check the return eventually. (as I had first wrote test)

from code.

Expect.js had withArgs:

withArgs: creates anonymous function to call fn with arguments

expect(fn).withArgs(invalid, arg).to.throwException();

How about dropping call and just using with? I think it reads quite well:

expect(fn).with(<args>).to.throw();

from code.

@hueniverse thoughts?

from code.

@gergoerdosi Good suggestion, I followed it, adding some aliases.

cf 2f162c2

from code.

Hapi New Year @ALL :)

Has a logical sequel of previous changes I introduced a result function to call the function and be able to assert on the result.

Was hesitating to add some alias names like return. Any suggestion is welcome

from code.

The more I think about this, the less I like it. You have to add APIs for calling the function, getting the return result, setting this, etc. Just seems like a lot of unnecessary complexity when JavaScript gives you everything you need to do this just as simply, if not simpler.

I'm going to go ahead and close this.

from code.

Sure it's just sugar around javascript features.
But are as most of assert already in code! :)

The point of this is to enable writing test in a very succint way.
Without having noise around to define function you don't need.

cf motivation example:

expect.call(Joi.func().minArity).with(0).to.throw(Error, 'n must be a strict positive integer');

vs

const schemaWithZeroArity = function (){

    return Joi.func().minArity(0);
};
expect(schemaWithZeroArity).to.throw(Error, 'n must be a strict positive integer');

With three test like that it's 3 lines instead of 15!!
Beside the asserter capture semantics.

from code.

Just use bind() and it's still 3 lines.

Another reason I don't like this proposal is that you need to be able to set this, or else it's incomplete (unless you're dealing with arrow functions, but there is no way to tell that). Just a can of worms that I don't want to open.

Sure it's just sugar around javascript features.
But are as most of assert already in code! :)

To be honest, I wouldn't have accepted some of the existing features like the type checking functions. It's REALLY hard to do that accurately (and getting harder) without dropping down to the C++ layer.

from code.

To be honest, I wouldn't have accepted some of the existing features like the type checking functions. It's REALLY hard to do that accurately (and getting harder) without dropping down to the C++ layer.

That's because it's hard it's better to rely on a library to do this correctly (haence relying on a developer to fight the C++ layer for us :), thanks for that).
From a library user it's a powerful abstraction.

you need to be able to set this, or else it's incomplete (unless you're dealing with arrow functions, but there is no way to tell that). Just a can of worms that I don't want to open.

Are you refering to the onsyntax?
And what king of worms you fear to come out of this?

from code.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

from code.