td.reset(thingsBlewUpSoPleaseLogWarnings=true)

[searls]

trafficstars

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

[Schoonology]

What's the timing of these messages now? On reset? Never?

[searls]

There are no messages for stubbings (when would there be?)

[Schoonology]

Is this something we can do during reset? Otherwise, I fear whatWentWrong would just become a part of some afterEach boilerplate.

[searls]

Sure! This could be a flag you send to reset, so that reset(true) could print the warnings

[Schoonology]

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.

[searls]

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?

[Schoonology]

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.)