feat(cli): Adding JUnit test reports

[skycoop]

This PR makes the following changes

• Created a CompoundTestReporter to allow us to use multiple reporters
• Implements JUnitTestReporter which writes JUnit XML to a path
• Added a CLI flag/option --junit that enables JUnit reporting. By default this writes the report to stdout (and disables pretty reporting). If a path is provided, it will write the JUnit report to that file while the pretty reporter writes to stdout like normal

Output of deno -- test --allow-all --unstable --location=http://js-unit-tests/foo/bar --junit cli/tests/unit/testing_test.ts

<?xml version="1.0" encoding="UTF-8"?>
<testsuites name="deno test" tests="7" failures="0" errors="0" time="0.176">
    <testsuite name="file:///Users/cooper/deno/deno/cli/tests/unit/testing_test.ts" tests="7" disabled="0" errors="0" failures="0">
        <testcase name="testWrongOverloads" time="0.012">
        </testcase>
        <testcase name="nameOfTestCaseCantBeEmpty" time="0.009">
        </testcase>
        <testcase name="invalidStepArguments" time="0.008">
        </testcase>
        <testcase name="nameOnTextContext" time="0.029">
            <properties>
                <property name="step[passed]" value="step ... nested step"/>
                <property name="step[passed]" value="step"/>
            </properties>
        </testcase>
        <testcase name="originOnTextContext" time="0.030">
            <properties>
                <property name="step[passed]" value="step ... nested step"/>
                <property name="step[passed]" value="step"/>
            </properties>
        </testcase>
        <testcase name="parentOnTextContext" time="0.030">
            <properties>
                <property name="step[passed]" value="step ... nested step"/>
                <property name="step[passed]" value="step"/>
            </properties>
        </testcase>
        <testcase name="explicit undefined for boolean options" time="0.009">
        </testcase>
    </testsuite>
</testsuites>

[CLAassistant]

All committers have signed the CLA.

[dsherret]

Overall looks good to me!

[bartlomieju]

@skycoop I did this:

$ cargo build
$ ./target/debug/deno test -A --unstable --junit=./report.xml cli/tests/unit/http_test.ts

Then I used xunit-viewer like so:

$ xunit-viewer -r ./report.xml
Written to: /Users/ib/dev/deno/index.html

Then I opened the file in the browser and got this:

Looks great, test steps are reported too - although in a bit quirky way... here's how it looks if there's a failing step:

I did a quick comparison with what mocha is doing on a test file like so:

var assert = require('assert');
describe('Array2', function () {
  describe('#indexOf()', function () {
    it('should return -1 when the value is not present', function () {
      assert.equal([1, 2, 3].indexOf(4), -1);
    });

    it('should return -1 when the value is not present', function () {
        assert.equal([1, 2, 3].indexOf(2), 1);
      });

    for (var i = 0; i < 10; i++) {
      it(`generated ${i}`, function () {
        assert(false);
      });
    }
  });
});

And the report I got is:

It appears mocha is flattening all deeply nested cases to top-level cases.

Do you feel it would be possible for us to do the same for our test steps? (Seems like the exact same problem we'd have to face if we decided to do #14390, so might be worth to address it now).

[skycoop]

I think the representation is being unpacked that way since xunit-viewer casting the repeated property to an array. Since steps are non-standard, I think this will be represented a lot of different ways by a lot of different systems.

The issue comparing with mocha is that our internal representation is different. describe is not a test case, it's a test suite, hence why everything ends up nested under a suite called #indexOf(). Deno.test is not a test suite, it's a test case that can have other test cases nested into it, so we're in a really uncomfortable situation. If we un-nest every step as it's own test-case, we'll start double counting everything which will cause deceptive execution times and failure counts.

[bartlomieju]

LGTM