Chalk: Provide a convenient way for mocking

[LeoAref]

CONTEXT: I'm writing a lib, and I've a printer module which uses Chalk for console styling
And I'm trying to write unit tests for the printer module with mocking Chalk.

I checked the source code searching for a way to mock the lib for my testing, but I couldn't find a convenient way to do so.

All the colors/background are in the __proto__ property, which is so hard to override (ie. mock), so could you advise the best way to do that?

Thanks!

[Qix-]

If you're testing the output of Chalk in your unit tests, you're being _way_ too specific with your tests and you'll find their fragility to be a hindrance.

Could you explain a bit more about what you're trying to mock with chalk?

[LeoAref]

@Qix- I have different print styles (ie. success, warning, danger, ...) with different colors, and backgrounds.

In my test, I'm trying to test the method calls NOT the Chalk output, for instance:

// styles.js
const styles = {
  warning: {
    color: 'white',
    background: 'bgYellow'
  }
};

// printer.js
printText(text, styleName) {
  const style = styles[styleName];
  console.log(chalk[style.color][style.background](text);
}

// printer.spec.js
describe('printer', () => {
  it('should print the given text in correct style', () => {
    printText('My title', 'warning');
    expect(chalkStub.white).to.have.been.called;
    expect(chalkStub.bgYellow).to.have.been.called;
  });
});

[Qix-]

You're testing a third party library at that point. Leave that to us, or lock in your versions. Your tests are _way_ too specific if this is what you're concerned about.

Also, your tests won't be deterministic. If you pipe your test results, or use certain CI, etc. then you're going to get false negatives anyway since we use supports-color.

Don't test output like that. This is just going to add headache to refactoring later on, and testing something as innocuous as colored output is way overboard unless you have _extremely strict requirements_ as to what colors should be outputted - which is absurd.

[LeoAref]

I don't test the third lib here, I'm testing MY method printText if it calls the correct methods!

[Qix-]

You are, though. You're making sure our methods are being called by your code. Don't do that; you're going to run into a ton of problems by doing that and you gain nothing by having such granular tests.

[LeoAref]

So this means that I don't have to test the printText method? or how could I test it?
Thanks btw 🙂

[Qix-]

It depends; if your printText method has strict requirements as to what _exactly_ it should be printing, then test it. Otherwise, it's superfluous.

Usually if you're testing an output function that uses colors, you don't have strict requirements.

Normally with output functions, I make sure they _work_ - period. I usually write a test that calls the function (printText in your case) that doesn't assert anything other than that it doesn't throw/crash the program. Nothing more, nothing less.

The reason is that, unless there is a very _specific_ format you need to have for the output (e.g. you're formatting TAP output or something), then testing the output isn't all that important.

[LeoAref]

Ok, thanks a lot for your input 👍

Currently I'm testing that it's working without issues and calling console.log with the given text, I also think that's enough!