Dom-testing-library: Incorrect Environment Detection When Running with Ember Test Server

Created on 28 Jun 2018  路  5Comments  路  Source: testing-library/dom-testing-library

  • dom-testing-library version: 2.6.3
  • react version: n/a
  • node version: 8.4.0
  • npm (or yarn) version: 6.1.0

Relevant code or config:

Using any dom-testing-library functionality within a running ember project (ember s) and viewing tests at "/tests";

What you did:

Attempted to use dom-testing-library along side standard Ember tooling for testing. When assertions failed (elements not found, etc) the debug output is produced.

What happened:

DTL outputs entire container in the browser window. It appears to be formatted for CLI and is unreadable.

Reproduction:

Sorry, I wasn't sure how to pull dom-testing-library into ember-twiddle. Unpkg didn't seem to work.

Problem description:

This makes it almost impossible to debug. This is especially true if using document as your container.

Suggested solution:

Issue possibly around here with detecting environment (thanks @kentcdodds):
https://github.com/kentcdodds/dom-testing-library/blob/ba44c14f93b4def2b1f8ce0eea8cbaf5c777c735/src/queries.js#L15

I found that in an Ember test

const inNode = typeof module !== 'undefined' && module.exports

will be undefined because, while typeof module is 'object', there's still no module.exports.

I'm not sure what's making DTL think it's in Node or if that is even the true issue.

help wanted needs discussion

Most helpful comment

I merged @rossipedia's PR because that makes a lot of sense to me, but I'm re-opening this because @sompylasar is right. It'd be better to check process.stdin.isTTY. Perhaps we could also have an environment variable override. Let's improve this.

All 5 comments

Maybe we could try to reference variables that we _know_ are Node only. Checking for module is actually just checking whether we're in a CommonJS environment, not Node. So we just need better node detection. Ideas?

process.stdin.isTTY or chalk.enabled for bash color highlight.

The real question asked there is not "inNode", but "canUseBashStyleColorHighlight" or even "shouldReturnAStringWithBashColors", right? And the answer is not just "if in Node, use it", right? So we don't actually need to detect if we're in Node or not, we need to detect where the output is assumed to be printed (i.e. to a terminal that supports colors or to a browser console).

I merged @rossipedia's PR because that makes a lot of sense to me, but I'm re-opening this because @sompylasar is right. It'd be better to check process.stdin.isTTY. Perhaps we could also have an environment variable override. Let's improve this.

:tada: This issue has been resolved in version 2.6.4 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings