how does this sound, for a start to the known issues category

[bcoe]

Added links based on @sindresorhus' suggestions, regarding known issues on Windows.

How does this sound as a start @jamestalmage, would love to expand on it based on your feedback.

[jamestalmage]

Anyone testing stderr/stdout of a forked process on Windows will have nightmares on AppVeyor, especially Node 0.10.

• Windows: make stdout/sterr pipes blocking nodejs/node-v0.x-archive#7196 (comment)
• http://help.appveyor.com/discussions/problems/1257-console-output-suppressed
• http://help.appveyor.com/discussions/problems/1352-output-of-commands-is-often-trimmed
• Appveyor: failing tests mapnik/node-mapnik#257 (comment)

We ended up having to do some really hackie stuff to make AppVeyor work for us:

• jamestalmage/ava@a73374d
• jamestalmage/ava@15bd794#diff-2cce40143051e25f811b56c79d619bf5R186

Our test suite still fails occasionally on Windows. It's much better now that we do minimal testing of our console output. Instead of tests that execute the CLI, we test the API, and keep the CLI to as thin a wrapper as possible.

---

Also, a very recent strategy that I think is great: Instead of creating a logger class, which logs directly to console, we employ a message generator that returns strings, so this:

test.on('error', function (e) {
  logger.logTestError(e);
});

becomes this:

test.on('error', function (e) {
  console.error(messageGenerator.createTestErrorMessage(e));
});

A little more verbose, but eminently more testable.

---

@sindresorhus recently published hook-std. If you must test stdout/stderr, use that in the same process instead of forking.