feat: Add .toLog() matcher

[ollelauribostrom]

This might need a bit of tweaking so consider it a WIP. Thought I put it up here to see if something like this would be useful, input is much appreciated 🙂

What

This PR adds a new matcher for asserting that a callback function outputs a message to the console. The given console method is mocked when running the callback, so nothing is actually printed to the console.

Why

I sometimes find myself wanting to assert that some function prints a message to the console. Like for instance checking that some information is printed, or that a deprecation warning is printed when calling a certain method. This matcher would be convenient for such scenarios.

Instead of doing something like:

const log = jest.spyOn(console, 'log');
log.mockImplementation(() => {});
someFunction();
expect(log).toHaveBeenCalledWith('some message');
log.mockRestore();

We could do

expect(someFunction).toLog('some message');
expect(someOtherFunction).toLog('some deprecation warning', 'warn');

Housekeeping

• Unit tests
• Documentation is up to date
• No additional lint warnings
• Add yourself to contributors list (yarn contributor)
• Typescript definitions are added/updated where relevant

[codecov-io]

Codecov Report

Merging #202 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #202   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files         109    117    +8     
  Lines         554    634   +80     
  Branches       97    109   +12     
=====================================
+ Hits          554    634   +80

Impacted Files	Coverage Δ
src/matchers/toLogWarning/index.js	100% <100%> (ø)
src/matchers/toLog/predicate.js	100% <100%> (ø)
src/matchers/toLogInfo/index.js	100% <100%> (ø)
src/matchers/toLogError/predicate.js	100% <100%> (ø)
src/matchers/toLogInfo/predicate.js	100% <100%> (ø)
src/matchers/toLogError/index.js	100% <100%> (ø)
src/matchers/toLog/index.js	100% <100%> (ø)
src/matchers/toLogWarning/predicate.js	100% <100%> (ø)
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 124db14...048a0ad. Read the comment docs.

[benjaminkay93]

Hey there,
Thanks for raising this, and I think its a really really cool idea.

I have a question around the API we use here, we could stick with the implementation proposed where we pass what we expect and then the console function expected to be called, or we could have an explicit matcher for each console function e.g.

expect(someFunctionCall).toConsoleLog('some log')
expect(someFunctionCall).toConsoleInfo('some info')
expect(someFunctionCall).toConsoleError('some error')

That way we can setup the spies on initiation rather than run time so it only gets setup once rather than for every use of the matcher? How does this sound?

Look forward to hearing from you soon, this is awesome 🥳

[benjaminkay93]

if we set up the spy here I can imagine we could incure larger performance implications than if it wasn't set at run time, but ill comment on that in my main response 😇

[ollelauribostrom]

Thanks a lot for the input @benjaminkay93, really like having an explicit matcher for each console method (PR is updated to reflect this). A few thoughts,

• Should I put each matcher in its own directory?
• Not sure I get what you mean by setting up the spies on initiation rather than run time. Wouldn't that mean that we would always be spying on the console methods?

[williamrchr]

Nit: I would adjust the matcher method to be more human-readable:
.toLog()
.toLogError()
.toLogInfo()

[williamrchr]

Thanks a lot for the input @benjaminkay93, really like having an explicit matcher for each console method (PR is updated to reflect this). A few thoughts,

* Should I put each matcher in its own directory?

* Not sure I get what you mean by setting up the spies on initiation rather than run time. Wouldn't that mean that we would always be spying on the console methods?

Should I put each matcher in its own directory?
Will let the project maintainer determine, but current structure would indicate that each should have its own directory.

Spying on initiation rather than run time
I don't think you need a spy here. You could simply wrap console.log() and friends and have a counter that adds everytime something gets added. Then there's not an internal dependency on jest. See: https://stackoverflow.com/questions/19846078/how-to-read-from-chromes-console-in-javascript

[ollelauribostrom]

@williamrchr Thanks for having a look, did some more updates to this 🙂

[AmyFoxFN]

Hi, all
Thanks for the design and endeavor for the console matchers. It is really helpful to me and my team. In fact , we are just looking for something like this.

But there is a question, Why this process stoped and Maybe when will this PR is probably be merged?

Look forward to knowing more about this, and Thanks a lot!

[keeganwitt]

README.md and types/index.d.ts both need updated to reflect the separate functions that were added.

[keeganwitt]

I assume this path used to be correct, but it's now jasmineUtils instead of jasmine_utils.