when a test fails it does not return a non zero exit code, meaning that services like travis do not know that there has been a test failure and report a success.

Example: https://travis-ci.org/dojo/examples/jobs/204142494

Bug

If an application is built without the legacy flag functional tests fails (as expected) for IE11.

Possibly should add an option to skip IE11.

Review the generated API documentation for cli-test-intern at http://dojo.io/api/. If any of the information is not accurate, please make the necessary adjustments to the API documentation within this repo.

Discussion

Would we have the ability to test individual modules via the test command in a user friendly way? For example, should we support something like: dojo test -m unit/FooBar to only run the specified tests instead of the entire unit or functional suite?

Bug

Package Version:

The currently installed groups are:

build (@dojo/cli-build-webpack) 0.1.0
create (@dojo/cli-create-app) 0.1.0
test (@dojo/cli-test-intern) 0.1.0

You are currently running @dojo/cli 0.1.0

Expected behavior:

$ time dojo test --unit

# dojo test --unit  19.79s user 0.92s system 121% cpu 17.065 total

Actual behavior:

I would expect tests to be run in a few seconds.

When working on tests for the widget showcase, I found myself frequently re-running tests to find out what works, learn about APIs and experiment. However the experience is slow which is not ideal.

I also see that 10 seconds are spent building the app:

I'm using the 0.2.0 version of cli-test-intern.

When I run "dojo test", the last message output to the console is:

to run in browser: http://localhost:8080/node_modules/intern/?config=node_modules/@dojo/cli-test-intern/intern/intern.json

There is no server running so that URL is not going to work.

Enhancement

It would be useful to have a browser flag for using the browser test runner for straight forward debugging etc..
Command could simply print a link to the console which the user to click to open the runner in their browser of choice.

Bug

Running dojo test -c local which is the implied configuration according to the documentation fails to work properly.

Package Version: master

Code

dojo test -c local

Expected behavior:

Test complete successfully.

Actual behavior:

⠸ Running testsError: Failed to load module /Users/kitsonk/github/examples/todo-mvc/node_modules/@dojo/cli-test-intern/intern/intern-local.js from /Users/kitsonk/github/examples/todo-mvc/node_modules/@dojo/cli-test-intern/intern/intern-local.js (parent: *20)
  at ReadFileContext.callback  <node_modules/dojo/loader.ts:831:119>
  at FSReqWrap.readFileAfterOpen [as oncomplete]  <fs.js:365:13>
 failed Running tests
Tests did not complete successfully

Enhancement

Now that we have @dojo/cli-build-app and @dojo/cli-build-widget we can remove the support for the legacy build command @dojo/cli-build-webpack.

To continue to use cli-build-webpack a previous version of cli-test-intern will be required along with previous compatible versions of @dojo/test-extras and @dojo/widget-core (pre sub-tree rendering, <= 0.7.0`

Notes

Notes subsections below describe the corresponding subsections in the readme.

Features

Runs tests built using @dojo/cli-build-webpack, or @dojo/cli-build-app.

No comma

How do I use this package?

There are several configuration options, to see what options are available run dojo test -h

Use a semicolon rather than a comma, or make these separate sentences.

How do I contribute?

Maybe How can I contribute?

An additional npm script to run prettier (with write set to true) against all src and test project files is available by running:

Maybe better worded as You format all src and test project files by running:

Testing

Test cases MUST be written using Intern using the bdd test interface and Assert assertion interface.

...the "bdd" test interface and "assert" assertion interface.

Licensing information

We don't normally list out the licenses of dependent packages.

Update the copyright line to 2018, and start at the real start year, not 2004.

Bug

Package Version: @dojo/[email protected] with [email protected]

When running the command dojo build -m test && dojo test -c local -f with the following test file, it works as expected on Linux but doesn't work on Windows. On Linux, you can see a browser window being opened and broken tests being marked as failed. On Windows, the application reports testing completed successfully even though there are broken tests, no browser window is opened.

Code

const { describe, it } = intern.getInterface('bdd')
const { expect } = intern.getPlugin('chai')

describe('Home page', function() {
    it(
      'should display',
      function() {
        return this.remote
          .get('http://localhost:9000/')
          .findByTagName('header')
          .findByTagName('footer')
          .end()
      }
  )
})

Expected behavior:

Functional tests should be run and there results reported by the application.

Actual behavior:

The application reports testing completed successfully even though no tests were run.

Bug

Using cli-test-intern throws a suite error when running functional tests using dojo test -a

Version: 0.2.0

Error

Suite chrome 62.0.3202.94 on Mac OS X FAILED
Error: Unable to load /./_build/src/src.js
  at HTMLScriptElement.<anonymous>  <node_modules/intern/browser/remote.js:118:5778>

Enhancement

cli-test-intern needs to be updated to support the new cli-build-app output directory, but also maintain backwards compatibility with the existing cli-build-webpack command.

To do so we it might be necessary to remove the automatic building that currently occurs, instead checking for the test bundle output (logging to the console to inform the user to run dojo build for test if the they don't exist) and running an appropriate intern configuration for the target.

Bug

dojo test fails if the project has multiple bundles (tested with the auto bundling only).

Error:

⠴ Running testsReferenceError: window is not defined
  at <_build/tests/unit/webpack:/webpack/bootstrap 606e39ae41b6b3349607:2:0>
  at <_build/tests/unit/all.js:153:10>
  at executeModule  <node_modules/@dojo/loader/loader.ts:680:52>
  at <node_modules/@dojo/loader/loader.ts:668:10>
  at Array.map  <native>
  at executeModule  <node_modules/@dojo/loader/loader.ts:662:43>
  at <node_modules/@dojo/loader/loader.ts:749:5>
  at guardCheckComplete  <node_modules/@dojo/loader/loader.ts:734:2>
  at checkComplete  <node_modules/@dojo/loader/loader.ts:741:25>
  at onLoadCallback  <node_modules/@dojo/loader/loader.ts:822:4>
 failed Running tests

Repo for reproducing the error isolation here: https://github.com/agubler/-dojo-test-bug-repro

Checkout failing branch, npm i, dojo test (assumes @dojo/cli is installed globally)

Diff between master and failing: https://github.com/agubler/-dojo-test-bug-repro/compare/failing

Enhancement

This is an epic to hold all the various issues for improving/re-architect the cli-test-intern command.

when ejecting an app following error occurs:

ENOENT: no such file or directory, lstat '..../node_modules/@dojo/cli-test-intern/intern/intern-next.json'

I'm using version 0.2.0 of cli-test-intern.

When I run "dojo test -h", I see this:

-c, --config       Specifies what configuration to test with:
                   'local'(default), 'browserstack', 'testingbot', or
                   'saucelabs'.                     

"local" is not a valid configuration in https://github.com/dojo/cli-test-intern/blob/master/src/intern/intern.json. So if you try to use it:

dojo test -c local

you get an error:

Error: Unknown child config "local"
  at <src/lib/common/util.ts:108:13>
  at Array.forEach  <anonymous>
  at mixinConfig_1  <src/lib/common/util.ts:105:13>
  at <src/lib/common/util.ts:139:4>
  at <node_modules/intern/node_modules/@dojo/core/async/Task.ts:319:12>
  at handler  <node_modules/intern/node_modules/@dojo/core/async/ExtensiblePromise.ts:216:14>
  at <anonymous>

  testing failed

Also, in the Dojo 2 projects, we use "local" to mean "run the tests in a browser (Chrome) using a local instance of Selenium".

Can we change the help text to indicate that the absence of a "config" option will cause the tests to run locally in node? Or change "local" to "node" in the help text and make it trigger the default behaviour?

Enhancement

It should be easy for users of dojo test intern to be able to express module mocks as part of their unit test cases and ensure that the documentation reflects how to do this.

Enhancement

Refreshing the page when viewing the intern test results does not re-run the tests, but instead shows the results from the last run of "dojo test". When using Intern on our existing Dojo (1) codebase, the tests will be rerun based on the latest code changes.

Package Version:
I was just testing out the first Dojo 2 tutorial (Dojo 2 local installation). "dojo test" is not mentioned in the tutorial, but is mentioned from the README file.

Code

Expected behavior:
I would expect navigating to the test results (http://localhost:9999/node_modules/intern/client.html?config=node_modules/@dojo/cli-test-intern/intern/intern-local), or refreshing the browser, would rerun "dojo test" to output the latest results.

Actual behavior:
I first run "dojo test" from the CMD window and all tests pass. In the results, it mentions you can view the results in the browser using a URL. That URL is incorrect (at the end it references "/intern" rather than something like "/intern-local"). I looked in the filesystem to find four files with "intern-*", so I chose one.

I then change the source code to make the test fail and then refresh the browser. The page reports that all tests still pass. Only after re-running "dojo test" and then refreshing the browser does the browser show the tests failing.

Bug

Running dojo test -a -c "browserstack" fails, whilst using the local tunnel or saucelabs run successfully.

building "dojo2-todo-mvc"...
ts-loader: Using [email protected] and /Users/Anthony/development/dojo2/examples/todo-mvc/tsconfig.json
Hash: bd396845ae9b73eed140
Version: webpack 2.7.0
Time: 12024ms
                                Asset       Size  Chunks                    Chunk Names
             ../_build/src/src.js.map    53.5 kB       3  [emitted]         src
                ../_build/src/main.js     348 kB       0  [emitted]  [big]  ../_build/src/main
    ../_build/tests/functional/all.js    89.1 kB       2  [emitted]         ../_build/tests/functional/all
                 ../_build/src/src.js     164 kB       3  [emitted]         src
                             main.css    6.71 kB    0, 2  [emitted]         ../_build/src/main, ../_build/tests/functional/all
            ../_build/src/main.js.map     545 kB       0  [emitted]         ../_build/src/main
                         main.css.map     9.7 kB    0, 2  [emitted]         ../_build/src/main, ../_build/tests/functional/all
      ../_build/tests/unit/all.js.map  914 bytes       1  [emitted]         ../_build/tests/unit/all
../_build/tests/functional/all.js.map     116 kB       2  [emitted]         ../_build/tests/functional/all
          ../_build/tests/unit/all.js    1.03 kB       1  [emitted]         ../_build/tests/unit/all
                           index.html  114 bytes          [emitted]
           widgets/styles/todoApp.css  247 bytes          [emitted]
        widgets/styles/todoFilter.css  411 bytes          [emitted]
        widgets/styles/todoFooter.css  714 bytes          [emitted]
        widgets/styles/todoHeader.css    1.13 kB          [emitted]
                              main.js    3.12 kB          [emitted]
          widgets/styles/todoItem.css    2.12 kB          [emitted]
          widgets/styles/todoList.css  167 bytes          [emitted]
             ../_build/src/index.html  321 bytes          [emitted]
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks  Chunk Names
    index.html  3.02 kB       0
Child html-webpack-plugin for "../_build/src/index.html":
                       Asset     Size  Chunks  Chunk Names
    ../_build/src/index.html  3.02 kB       0

testing "dojo2-todo-mvc"...

Listening on localhost:9000 (ws 9001)
Tunnel started
BUG: suiteEnd was received for invalid session
(ノಠ益ಠ)ノ彡┻━┻
Error: [POST https://(redacted)@localhost:4444/wd/hub/session] connect ECONNREFUSED 127.0.0.1:4444
  at Server.post  <node_modules/src/Server.ts:367:14>
  at Server.createSession  <node_modules/src/Server.ts:412:14>
  at Suite.before  <src/lib/executors/Node.ts:475:8>
  at <src/lib/Suite.ts:387:19>
  at new Task  <node_modules/intern/node_modules/@dojo/core/async/Task.ts:210:3>
  at runLifecycleMethod  <src/lib/Suite.ts:354:10>
  at before  <src/lib/Suite.ts:457:10>
  at Suite.run  <src/lib/Suite.ts:476:6>
  at <src/lib/executors/Node.ts:929:20>
  at FunctionQueue.next  <src/lib/executors/Node.ts:1308:13>

TOTAL: tested 0 platforms, 0 passed, 0 failed; fatal error occurred
BUG: suiteEnd was received for invalid session
BUG: suiteEnd was received for invalid session
Stopped
  testing failed

To reproduce create a fresh Dojo 2 project using dojo create, export browserstack credentials and run dojo test -a -c "browserstack"

New versions of source-map include their own type definitions, so we can remove our dependency on type definitions if we update to a new version of source-map:

npm WARN deprecated @types/[email protected]: This is a stub types definition for source-map (https://github.com/mozilla/source-map). source-map provides its own type definitions, so you don't need @types/source-map installed!

Bug

The Intern configurations included with cli-test-intern contain a lot of information that is not actually used, like the loader configuration. This is because the tests are actually run against a WebPack bundle and therefore there is not an AMD loader impacted.

End users might get confused by this configuration. We should only have configuration in the files that is actually used by Intern when running under WebPack.

The default version of chrome driver does not support the latest chrome version (76) and throws errors trying to create a session.

Reported by @xiaohulu via the Dojo discord channel.

Enhancement
When running in node, we currently build both the unit and functional tests in webpack. This takes time to build as well as not allowing node centric functionality to be used (existing issues: #66, dojo/cli-build-webpack#256).

To get the tests to run in node without a build step, we need to at the least transpile the ts and deal with css modules. Fortunately there are require hooks to deal with both of these:

• ts: https://github.com/TypeStrong/ts-node
• css modules: https://github.com/css-modules/css-modules-require-hook

If we load these, we can then run off the source code alone.

I quickly tried the output from a fresh @dojo/cli-create-app scaffold, and here are the results (in seconds to complete):

existing with build:

8.95 real        10.07 user         0.63 sys

without building (using ts-node and css-modules-require-hook):

2.45 real         2.43 user         0.29 sys

Which is quite a big improvement.

We would still need to build the units for browser testing.

Bug
Running the tests with the dojo test -f command fails because it does not use the local config.

Package Version: 3.0.0

Code
/tests/functional/main.ts

const {registerSuite} = intern.getInterface('object');
const {assert} = intern.getPlugin('chai');

import * as css from '../../src/widgets/styles/helloWorld.m.css';

import {Remote} from 'intern/lib/executors/Node';

function getPage(remote: Remote) {
    return remote
        .get('http://localhost:9999')
        .setFindTimeout(5000);
}


registerSuite('Logo', {
    'logo should be visible'() {
        return getPage(this.remote)
            .findByCssSelector(`${css.logo}`)
            .getSize()
            .then(({height, width}: { height: number; width: number; }) => {
                assert.isAbove(height, 0, 'The logo height should be greater than zero.');
                assert.isAbove(width, 0, 'The logo width should be greater than zero.');
            })
            .end();
    }
});

Expected behavior:
The dojo test -f command should use the local config by default. In the above case the test should fail.

Actual behavior:
The dojo test -f command runs successfully but does not find any tests. Running dojo test -f -c local does run the test.

➜  issue-demo dojo build app --mode test

ℹ cli-build-app: 1.0.0
ℹ typescript: 2.6.2
✔ hash: 87b7f427ceb77be4b429
✖ errors: 0
⚠ warnings: 0

chunks:
functional  unit
assets:
2ho78oCW.svg (10.98kb) / (3.89kb gz)    functional.js (65.66kb) / (21.11kb gz)  unit.js (1526.95kb) / (403.61kb gz)
output at: file:////Users/username/Documents/issue-demo/output/test

The build completed successfully.

➜  issue-demo dojo test -f

testing "issue-demo"...

TOTAL: tested 0 platforms, 0 passed, 0 failed

  testing completed successfully

 These tests were run using Dojo JIT compilation. The test suite may also be run against the built application with dojo test -c local
➜  issue-demo dojo test -f -c local

testing "issue-demo"...

Listening on localhost:9000 (ws 9001)
Tunnel started

‣ Created remote session chrome 68.0.3440.106 on Mac OS X (36b8c62ce9abe4911de3046e6e03f806)
× chrome 68.0.3440.106 on Mac OS X - Logo - logo should be visible (5.312s)
    NoSuchElement: [POST http://localhost:4444/wd/hub/session/36b8c62ce9abe4911de3046e6e03f806/element / {"using":"css selector","value":"SNEWwkH3"}] no such element: Unable to locateelement: {"method":"css selector","selector":"SNEWwkH3"}
      (Session info: chrome=68.0.3440.106)
      (Driver info: chromedriver=2.39.562713 (dd642283e958a93ebf6891600db055f1f1b4f3b2),platform=Mac OS X 10.13.6 x86_64)
      at Server.post  <node_modules/src/Server.ts:367:14>
      at runRequest  <node_modules/src/Session.ts:132:5>
      at <node_modules/src/Session.ts:166:38>
      at new Task  <node_modules/@dojo/core/async/Task.ts:239:3>
      at InitializedProxiedSession.Session._delegateToServer  <node_modules/src/Session.ts:110:9>
      at InitializedProxiedSession.Session.serverPost  <node_modules/src/Session.ts:176:14>
      at InitializedProxiedSession.Session.find  <node_modules/src/Session.ts:1172:14>
      at Command.<anonymous>  <node_modules/src/Command.ts:709:32>
      at <node_modules/@dojo/core/async/Task.ts:351:12>
      at handler  <node_modules/@dojo/core/async/ExtensiblePromise.ts:229:14>
      at Command._callFindElementMethod  <node_modules/src/Command.ts:688:9>
      at Command.find  <node_modules/src/Command.ts:657:14>
      at Command.Locator.findByCssSelector  <node_modules/src/lib/Locator.ts:39:14>
      at Test.logo should be visible [as test]  <webpack:/tests/functional/main.ts:20:13>
      at <src/lib/Test.ts:260:47>
      at <node_modules/@dojo/core/async/Task.ts:351:12>
      at handler  <node_modules/@dojo/core/async/ExtensiblePromise.ts:229:14>
      at process._tickCallback  <internal/process/next_tick.js:68:7>

TOTAL: tested 1 platforms, 0 passed, 1 failed
Stopped
  testing failed

 If the project directory is hosted on a local server, unit tests can also be run in browser by navigating to http://localhost/node_modules/intern/?config=node_modules/@dojo/cli-test-intern/intern/intern.json@local
Tests did not complete successfully

Enhancement

Related to #21

There are several common use cases that would fall outside of the "default" configuration options we currently offer with intern. We need to figure out how to support these in a way that would not simply lead a user to eject the CLI command and go it their own.

Use cases we don't currently support, but are highly likely:

• Changing the types of browsers and version to run against remotely for SauceLabs, BrowserStack and TestingBot.
• Saving authentication information so they don't have to be passed on the CLI.
• Changing the local SeleniumTunnel to support Safari or Firefox instead of Chrome.
• Supporting proxy only configurations (but see #24)
• Changing the concurrency of remote tunnels.

Bug

This package should depend on ~0.2.0 of @dojo/test-extras instead of ~0.1.0:

Bug

The to run in browser message needs to be changed to point at the intern-local.js config file.

cli-test-intern currently defaults to using selenium tunnel for functional tests, which requires the JDK. We either need to deal with this better or at least note it as part of cli-test-intern in some way.

Bug

When the build command is executed, it automatically sets disableLazyWidgetDetection to true, which is not desirable in applications that lazy-load widgets since it results in the tests being unable to load those widgets (e.g., dojo/cli-build-webpack#106).

The expected behavior is that executing dojo test would use the same disableLazyWidgetDetection flag used when running dojo build.

This package should be updated to use the new @dojo/framework instead of the individual core, has, i18n, widget-core, routing, stores, and shim packages.

Enhancement

Right now when we generate a bundle for testing, everything is included in a single bundle, the target app, dependencies and tests. Because it is a single JS file, it ends up getting instrumented fully by Intern, which means that all coverage for all code is instrumented and collected. This is currently being stripped out during the coverage process, but we have already had issues in other areas where when testing on remote browser that has to post back the coverage information breaks some of the XHR requests as well as it causes everything to run slower as it handles all this coverage information.

We should consider breaking the app under test out from the dependencies and the tests so that it can be selectively instrumented for code coverage analysis.

Enhancement

Include loadJsDom by default for suites in the intern.ts config.

Bug

When you run functional tests from the CLI it runs the unit tests also (which the dojo-test-intern believe fail)

Package Version: 2.0.0-beta2.4

Code

dojo test --functional

Expected behavior:

The CLI to just functional tests, i.e. ones in tests/functional/all.ts

Actual behavior:

Runs both functional and unit tests, and the unit tests are treated as functional test and in turn fail.

Screenshot

Currently the test task delegate directly to intern-runner, and by default runs both unit tests and functional tests, in a browser.

By default it should run only unit tests, and should run them in node. Running functional tests should be optional.

Getting an error when running dojo test in Windows,

Error: Failed to load module intern/lib/reporters/C:/Users/rorti/Desktop/Dojo2/testapp/node_modules/@dojo/cli-test-intern/reporters/Reporter from C:/Users/rorti/Desktop/Dojo2/testapp/node_modules/intern/lib/reporters/C:/Users/rorti/Desktop/Dojo2/test-app/node_modules/@dojo/cli-test-intern/reporters/Reporter.js (parent: *21)

To Reproduce (from powershell or cmd):

dojo create-app --name=temp
cd temp
# need to downgrade ts-loader
npm i [email protected]
dojo test

Enhancement

This issue is to update the package so that dojo test intern runs tests under Intern 4.

Enhancement

dojo/cli supports now ejecting configuration for advanced users. The eject should be implemented for the test configuration.

Bug
The jsdom plugin in cli-test-intern is not currently implemented correctly for bundles (ie using dojo test -c local).

It imports both @dojo/shim and @dojo/has modules to set things on, but those modules have no correlation with what is actually bundled. We should likely favour setting things directly on the global in node here (given the jsdom plugin is only used in a node env anyway). I'm not sure how important the has flag for jsdom is either so perhaps we can drop that?

It also seems like due to our global implementation in dojo/shim (which checks for a global first over a window) and the way we are just attaching the jsdom window to global.window results in this not working. To fix we could either change our global implementation to test for window first, or we have to spread the jsdom window over the node global. If we are going to do the latter we should consider https://github.com/rstacruz/jsdom-global perhaps

Discussion

The arguments of what to test are confusing.

• -u (the default) runs intern against node.
• -f runs the functional tests against the local tunnel.
• -a runs both the unit and functional tests against the local tunnel.

It is likely better to be explicit about running tests in the browser and -a would run unit tests against node and the unit tests and functional tests via the local tunnel by default. So maybe it should be:

• -n (default) run unit tests via node
• -u run unit tests via node and the local tunnel
• -f run functional tests via the local tunnel
• -a run unit tests via node and unit and functional tests via the local tunnel

Running dojo test displays a URL that can be used to run the tests in a web browser, but only when all of the tests pass. When at least one fails, the URL is not displayed. The URL should be displayed whether or not the tests pass.

Bug
Awaiting on theintern/intern#850, to be fixed.

IE10 is not supported for Dojo 2 so should not be included in the default intern configuration files.

Bug

if the user has cli-test-intern command installed and runs any dojo cli commands in a directory that doesn't contain a package.json, dojo cli becomes unusable with the following error:

Commands are not available: Error: Failed to load module /Users/foo/.nvm/versions/node/v6.10.3/lib/node_modules/@dojo/cli-test-intern
Nested error: Cannot find module '/path/to/cwd/package.json'

Package Version: 2.0.0-beta2.1

Expected behavior:
dojo cli commands should be usable without a package.json, since initially the user won't have any apps created to start with.

Bug

When running functional tests, the Java checker does not recognize OpenJDK installations. The output of java -version does not contain the substring "java version" but instead shows "openjdk version ...".

Package Version: 0.5.1

Actual behavior:

> dojo test -f
Error! Java VM could not be found.
A Java VM needs to be installed and available from the command line to allow the dojo test command to run tests in a browser locally or remotely.

> java -version
openjdk version "1.8.0_161"
OpenJDK Runtime Environment (IcedTea 3.7.0) (build 1.8.0_161-b12 suse-1.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.161-b12, mixed mode)

Bug

The app, generated with dojo create app can not run the intern test with junit reporter specified

Package Version: 5.0.0

Code

// run following commands

dojo create app -n test-intern
dojo build app --mode dist
dojo build app --mode test
dojo test -a -r junit

Expected behavior:

cli should write test result to an xml file.

• would be nice if you had an option to provide the path to output file

Actual behavior:

<?xml version="1.0" encoding="UTF-8" ?><testsuites><testsuite name="node" failures="0" skipped="0" tests="8" time="0.011"><testsuite name="App" failures="0" skipped="0" tests="4" time="0.006"><testcase name="default
renders correctly" time="0.002" status="0"/><testcase name="home outlet renderer" time="0.001" status="0"/><testcase name="about outlet renderer" time="0" status="0"/><testcase name="profile outlet renderer" time="0.001" status="0"/></testsuite><testsuite name="About" failures="0" skipped="0" tests="1" time="0"><testcase name="default renders correctly" time="0" status="0"/></testsuite><testsuite name="Home" failures="0" skipped="0" tests="1" time="0.001"><testcase name="default renders correctly" time="0.001" status="0"/></testsuite><testsuite name="Profile" failures="0" skipped="0" tests="1" time="0.003"><testcase name="default renders correctly" time="0" status="0"/></testsuite><testsuite name="Menu" failures="0" skipped="0" tests="1" time="0.001"><testcase name="default renders correctly" time="0" status="0"/></testsuite></testsuite></testsuites>
Unhandled error: Error [ERR_STDOUT_CLOSE]: process.stdout cannot be closed
    at WriteStream.stdout._destroy (internal/process/stdio.js:18:18)
    at WriteStream.destroy (internal/streams/destroy.js:32:8)
    at WriteStream.Socket._final (net.js:301:17)
    at callFinal (_stream_writable.js:584:10)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)
Error [ERR_STDOUT_CLOSE]: process.stdout cannot be closed
  at WriteStream.stdout._destroy  <internal\process\stdio.js:18:18>
  at WriteStream.destroy  <internal\streams\destroy.js:32:8>
  at WriteStream.Socket._final  <net.js:301:17>
  at callFinal  <_stream_writable.js:584:10>
  at _combinedTickCallback  <internal\process\next_tick.js:139:11>
  at process._tickCallback  <internal\process\next_tick.js:181:9>

Bug

if there are compilation failures building the test bundles (in _build directory), test-intern does not return a non-zero exit code, meaning that tests still execute and the command does not "fail"

Enhancement

We should integrate @dojo/test-extras so that it is available by default when testing.

Enhancement

As @dojo/test-extras no longer provides JSDOM, we should consider adding built in support within @dojo/cli-test-intern.

Bug

--cov option does not seem to be working.