Add ability to mock out process.stdout calls

[jeffrafter]

Currently issueCommand always outputs to stdout here: https://github.com/actions/toolkit/blob/master/packages/core/src/command.ts#L25. This is great but when writing tests for actions it quickly fills up the logs:

> @ test /Users/njero/Code/Examples/example-github-action-typescript
> jest

 PASS  .github/actions/debug-action/__tests__/debug.test.ts
  debug action debug messages
    ✓ outputs a debug message (5ms)

##[debug]👋 Hello! You are an amazing person! 🙌
##[debug]👋 Hello! You are an amazing person! 🙌
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.423s
Ran all test suites.

If the output was wrapped in a call on the Command object itself then it could be mocked in the jest setup. Additionally this might pave the way for alternate logging outputs down the road.

[jeffrafter]

It is also possible to mock this globally in the jest.config.js:

const processStdoutWrite = process.stdout.write.bind(process.stdout)
process.stdout.write = (str, encoding, cb) => {
  // Note: this will soon change to ::
  if (!str.match(/^\#\#/)) {
    return processStdoutWrite(str, encoding, cb)
  }
}

[bryanmacfarlane]

Thanks for logging this issue! We will implement this (we also take PRs ;) )

[xt0rted]

These log messages from tests are now causing annotations to be created when they shouldn't be. You can see an example of this in my most recent action run here https://github.com/xt0rted/slash-command-action/pull/34/checks?check_run_id=259915650#step:8:9 and here https://github.com/xt0rted/slash-command-action/pull/34/checks?check_run_id=259915650#step:8:63.

[bryanmacfarlane]

@xt0rted - not related to mocking but I think proper annotations support will fix your issue. I can prioritize the first half of that work (ensuring logging warning / error output doesn't create an annotation). That's a bug and I can fix. Sound ok? #186

[xt0rted]

@bryanmacfarlane I meant to post that on #163, both issues a pretty similar in their end goal.

[ericsciple]

would mocking the command module make more sense?

[ericsciple]

Example here where core is mocked out specifically to capture info.

Example here where core is mocked out to control the function results.

Users can leverage mocking tools to fit their specific needs.

[jasonkarns]

@ericsciple I don't think it's just as simple as mocking core. I'm using the tool-cache module and getting all the debug messages triggered by tool-cache. I can't mock @actions/core because tool-cache has its own copy of the module. (@actions/core isn't de-duped in my node_modules tree; but even if it were, that would be a pretty fragile mock to assume they would always de-dupe)

[ericsciple]

@jasonkarns good point regarding dedupe

[bryanmacfarlane]

This is what we do in setup-go tests to mock it.

https://github.com/actions/setup-go/blob/master/__tests__/setup-go.test.ts#L49

So, you're not mocking core wit a need for understanding internal. You're getting console writes so mock that.

It's not the toolkit's role to add mocking for stdout. There's plenty of mocking frameworks that are capable of mocking stdout (as per above). Action authors should use the testing and mocking framework that suits them.