re: Bad Test Double
Actually your GOOD PATTERN is a potential anti-pattern in itself.
You've taken a fast, well isolated (decoupled) test and slowed it down and made more it difficult to set up and run - you've created an "integrated test" (not to be confused with an integration test).
The accepted solution to the conundrum you present is contract testing (2011!)
As ridiculous as it may initially sound a contract test shows that the service implementation behaves correctly in the way the client expects - i.e. it verifies that the test double's behaviour is in alignment with the actual service.
The idea is to maintain the isolation and speed of the original microtests in order to remain viable to be executed quickly and frequently.
Contract tests are run regularly but much less frequently as they require more resources and are more complicated. When the test double's implementation becomes stale the contract test will fail. It is at this point that the test double is updated to make the contract test pass - then the updated test double is deployed to the collection of microtests.
re: Bad Test Double
Actually your GOOD PATTERN is a potential anti-pattern in itself.
You've taken a fast, well isolated (decoupled) test and slowed it down and made more it difficult to set up and run - you've created an "integrated test" (not to be confused with an integration test).
Integrated Tests Are A Scam (2009)
Clearing Up the Integrated Tests Scam (2015)
The accepted solution to the conundrum you present is contract testing (2011!)
As ridiculous as it may initially sound a contract test shows that the service implementation behaves correctly in the way the client expects - i.e. it verifies that the test double's behaviour is in alignment with the actual service.
The idea is to maintain the isolation and speed of the original microtests in order to remain viable to be executed quickly and frequently.
Contract tests are run regularly but much less frequently as they require more resources and are more complicated. When the test double's implementation becomes stale the contract test will fail. It is at this point that the test double is updated to make the contract test pass - then the updated test double is deployed to the collection of microtests.
re: Promises
MDN: Promise.reject()
For debugging purposes and selective error catching, it is useful to make reason an
instanceofError.