If a stub is defined to return a rejected Promise using rejectWith, but that stub has not been called during process execution, then an UnhandledPromiseRejectionWarning will result in later versions of NodeJS (6.6.0+), with a warning that at some later version, NodeJS will terminate with a non-zero exit code on such an occurrence.
This appears to be because the Promise (both for rejectWith and resolveWith cases) is created at the point that the behaviour is defined rather than at the point the stub is called, and if the stub is not called, then there is no way for the Promise to be handled.
I'd expect that either:
simple-mock should be able to report at the end of the process whenever behaviour has been defined that has not been invoked (useful for tracing unnecessary specification in tests)
or at least that the creation of the Promise should be deferred until the behaviour is required, in both resolve and reject cases.
If a stub is defined to return a rejected Promise using
rejectWith, but that stub has not been called during process execution, then an UnhandledPromiseRejectionWarning will result in later versions of NodeJS (6.6.0+), with a warning that at some later version, NodeJS will terminate with a non-zero exit code on such an occurrence.This appears to be because the Promise (both for
rejectWithandresolveWithcases) is created at the point that the behaviour is defined rather than at the point the stub is called, and if the stub is not called, then there is no way for the Promise to be handled.I'd expect that either:
simple-mockshould be able to report at the end of the process whenever behaviour has been defined that has not been invoked (useful for tracing unnecessary specification in tests)