Open searls opened 7 years ago
What's the timing of these messages now? On reset
? Never?
There are no messages for stubbings (when would there be?)
Is this something we can do during reset
? Otherwise, I fear whatWentWrong
would just become a part of some afterEach
boilerplate.
Sure! This could be a flag you send to reset, so that reset(true)
could print the warnings
That, or even an option: reset({ printReport: true })
I think reset
could be a good place to put these kinds of features in the future. It has little effect on the test practice or test quality.
Yeah, agree, we probably shouldn't throw a mystery meat boolean at an unrelated-looking method. I think this is the right approach. Is console.log/warn the right mechanism for getting folks that report?
Probably. The only issue I can think of would be with unix pipes, but I think that was resolved.
(It used to be that node script-with-console-log.js | whatever
would blow up.)
Proposal: a new top-level method designed to be run in an
afterEach
block of the user's tests, and passed a boolean as to whether or not the test failed.When
td.reset(true)
is called, td.js will log a warning to the console that contains a summary of the state of all the test doubles known to it since the last reset, including what they were all invoked with.Like #161, this would be organized stubbying-by-stubbing ("this stubbing was never satisfied (red flag!)", and "this stubbing was satisfied by these three calls: [list]"`
Not all tests allow for this, but many do. And for those that don't, the user could set the var themselves to manually introspect like so:
afterEach(() => td.whatWentWrong(process.env.UGH))
I think this could be a solution to all the issues where people want to sprinkle in
td.verify()
calls for better messages alone like #148 & #138