That way you would not have to .querySelector the element yourself when you need it for other test helpers (for example ember-test-helpers).

// ...
let buttonElement = this.element.querySelector('.some-button');
let domAssertion = assert.dom(buttonElement);
domAssertion.exists();

await click(buttonElement);
// ...

Could be changed to something like:

// ...
let domAssertion = assert.dom('.some-button');
domAssertion.exists();

await click(domAssertion.element);
// ...

It would improve the DX a tiny bit, in my opinion 😁

Thoughts?

... for hasTextContaining()

Following code:

  assert.dom('.some-existing-element').hasText(1234);

Produces following exception:

TypeError: string.replace is not a function
    at collapseWhitespace (http://localhost:7357/assets/test-support.js:7820:17)
    at DOMAssertions.hasText (http://localhost:7357/assets/test-support.js:8124:20)
    at Object._callee$ (http://localhost:7357/assets/tests.js:244:52)
    at tryCatch (http://localhost:7357/assets/vendor.js:381:40)
    at Generator.invoke [as _invoke] (http://localhost:7357/assets/vendor.js:655:22)
    at Generator.prototype.(anonymous function) [as next] (http://localhost:7357/assets/vendor.js:414:21)
    at step (http://localhost:7357/assets/tests.js:194:32)
    at http://localhost:7357/assets/tests.js:205:15
    at <anonymous>

I believe it goes down to this line. And the fact that I'm passing down number instead of string.

I know that hasText()'s API is defined as: expected (string | RegExp), but the library should at least warn about unsupported parameter and not blow up. Preferably though, I'd like to see automatic conversion from number to string #justWorks™

Basically the inverted case for #17

This assertion should work roughly similar to hasAttribute() and can then be used to check for properties that don't have dedicated assertions (like hasValue()).

Say you have an element like <div id="fun" class="thing1 thing2 thing3">, and your testing code is written like assert.dom('#fun').hasClass('thing1').

IF it does not find a class, it fails with "Expected: thing1", "Result: thing8 thing2 thing3".

... I guess this is not a very important issue.

Similarly as there is hasAnyValue assertion, there could be hasAnyText or hasAnyContent.

I run tests by dropping an iFrame of the target into my testrunner.html file. Then I do

a = document.getElementById('idOfiFrame').contentWindow;

This allows me to view the visual state of the page as it's being tested. I test all target functions via a.targetFunctionName.

Your plugin looks great, but I can't figure out how to make the .dom() test things within (a), instead of the testrunner.html window.

Any tips?

How would one go about adding their own, project-local assertions to qunit-dom?

With QUnit, we can say

QUnit.assert.myAssertion = function() {...}

However, to be able to do that with an object returned from QUnit.dom(...), one would have to extend a DOMAssertions object or prototype. I couldn't seem to find where that is accessible.

What do you think about making it possible to chain assertions? That way you don't have to call assert.dom() multiple times (or cache it).

assert.dom('.some-class')
  .exists()
  .hasText('Testing')
  .hasAttribute('disabled');

I have quite a few failing tests after applying the codemod, for tests that were using the :first-child selector. This is due to the fact that in normal Ember tests the first child will be the component under test, while here it is another wrapper element inside #ember-testing. This is similar to the same issue in ember-native-dom-helpers: cibernox/ember-native-dom-helpers#63.

I used this to fix it for my use, the same selector could be used in your vendor script. Can submit a PR if you agree!?

Would it be a good idea to have something like

assert.dom(selector).matchesSelector(anotherSelector, message)

to be able to check if a given CSS selector returns the exact same (set of?) element(s)?

I would probably save some boilerplate if we had that, and CSS selectors have come to express a lot more things than just CSS classes and attributes (sibling detection, last-child, ...)

Just checking the waters here.

This seems like a more friendly API and closer to e.g. chai-dom

Adding checked and disabled states to be able to assert them easily:

assert.ok(find('input[type="checkbox"]').checked);
assert.dom('input[type="checkbox"]').isChecked();

assert.ok(find('input[type="checkbox"]').disabled); 
assert.dom('input[type="checkbox"]').isDisabled();

Also what about readonly or required?

Hey there!

Working with this addon is amazing, however, working with this and TypeScript is not great as it doesn't have type definitions.

Do you have intention on adding Type Definitions to easy integrate with Ember apps using TypeScript?

Hello 👋 Would it be possible to get the latest changes (like isVisible) released in a new version? Thanks 🙏

The following should be possible:

test('element has class', function(assert) {
  assert.dom().hasClass('data-foo');
});

However, the following error is thrown:

TypeError: Unexpected Parameter: undefined

The current work around (in Ember's moduleForComponent parlance) is:

test('element has class', function(assert) {
  this.render(hbs`{{some-thing}}`);

  assert.dom(this._element).hasClass('foo');
});

I extracted https://github.com/kellyselden/ember-text-test-helper from an app without knowing hasText does whitespace collapsing. I would like to ditch my addon, but to reach feature parity, this project would need to support selectors that match multiple elements and "combine", as well as assert.dom(document.querySelectorAll('div')).

I think @Turbo87 is open to it, but every assertion will need to be updated. For instance hasAttribute will probably turn into a "all have attribute".

Currently, when you want to find a count of elements on the page you do:

assert.dom('[data-test-something]').exists({ count: 4 });

While this works, I find the API a bit inelegant. Any thoughts on adding a count alias (or something similarly named) which essentially is a wrapper around the above call?

assert.dom('[data-test-something]').count(4);

Feel free to close if it's not something you'd like to add.

would you be interested in having a new function that allows you to filter out all the visible-hidden elements and just assert against the visibleText??

This should assert if the classList property of an element contains the expected value.

... including the .rpt2_cache folder 🤦‍♂️

#62 added a isDisabled() assertion, but the reverse (isNotDisabled()) is still missing.

/cc @rtablada

I do something like:

assert.equal(this.element.querySelectorAll('.column-map-row').length, 1, 'Has one row');

very often, would love a helper to do it quicker. Not really stuck on the name hasNItems.

That would be great!

After the change made to satisfy issue #104, you can no longer pass in text containing line breaks (or probably multiple spacing) as the expected text in includesText.

This is not a clear limitation in the documentation, and the resulting message in Ember is confusing:

As you can see, it appears as though the test is failing because of the diff at the beginning of the string. If you are not distracted by the red highlight in the diff, you might notice that there is actually a line break discrepancy, too.

Issue

"\u00A0Foo\u00A0\u00A0Boo\u00A0" should collapse to "Foo Boo" but does not.

Solution

In the function 'collapseWhitespace' update

".replace(/[\t\r\n]/g, ' ')"

to

".replace(/[\t\r\n\u00A0]/g, ' ')"

This will enable assertions like:

assert.dom().containsText('foo');

If I pass an SVGElement into assert.dom(<svg element>) and try to run any assertions, it fails because it requires a HTMLElement explicitly. Maybe move up the inheritance chain in the instanceof check to Element rather than HTMLElement?

let svgElement = document.querySelector("svg"); // Element retrieved manually because too complicated for selector
assert.dom(svgElement).hasAttribute("width", "100");

Throws:

TypeError: Unexpected Parameter: [object SVGGElement]
--
  | at DOMAssertions.findTargetElement (http://localhost:7357/assets/test-support.js:22780:15)
  | at DOMAssertions.hasAttribute (http://localhost:7357/assets/test-support.js:22285:26)
  | at Object._callee21$ (http://localhost:7357/assets/tests.js:140150:76)
  | at tryCatch (http://localhost:7357/assets/vendor.js:10983:40)
  | at Generator.invoke [as _invoke] (http://localhost:7357/assets/vendor.js:11274:22)
  | at Generator.prototype.(anonymous function) [as next] (http://localhost:7357/assets/vendor.js:11035:21)
  | at step (http://localhost:7357/assets/tests.js:139513:32)
  | at http://localhost:7357/assets/tests.js:139524:15
  | at <anonymous>

Example

assert.dom('.some-element').hasCSS({
  opacity: 1,
  width: 340,
});

It seems like I have forgotten to implement linting on this project... 😱

We should make sure to implement it in a way so that it warns us about unsupported browser features like Array.from() (on IE11)

Using qunit-dom in an Ember project with ember-cli-typescript

ember ts:precompile gives errors:
tests/filename...(line, col): error TS2339: Property 'dom' does not exist on type 'Assert'.

As per the readme, I've added the import

// test-helper.js
import Application from '../app';
...
import { start } from 'ember-qunit';
import 'qunit-dom';
...

My use case: interop with ember-native-dom-helpers which returns dom elements.

That way I can write things like:

import { find } from 'ember-native-dom-helpers';

test('it exists', async function(assert) {
  assert.dom(find('h1')).hasClass('bar');
});

The "message" argument is not very consistent - in some assertion helpers, it's the first argument - but in others, it's the second argument.

This is confusing, especially for helpers with an optional first argument. For example:

assert.dom('.my-element').exists({}, 'My description') // why did I have to pass an empty object here?

I propose a chained method for descriptions to handle the inconsistency. Example:

assert.dom('.my-element').exists().withDescription('My description')

When I'm testing multiple elements in one particular area I need to write something like:

let rootElement = document.querySelector(".super .long .selector .that .i .dont .want .to .repeat");

assert.dom('.foo', rootElement).hasText('foo');
assert.dom('.bar', rootElement).hasText('bar');
assert.dom('.baz', rootElement).hasText('baz');
...

• Because rootElement can be only HTMLElement, I can't use simple CSS selector string. Not really a problem, since that would come with performance penalty anyway.
• I'm wondering whether there is different, more "standard" way to write this? Namely asking about document.querySelector which feels really "bare" to use.

Issue

While building HTML we regularly leave line-breaks and various inline elements, and that shouldn't interfere with testing.

The current implementation of includesText includes all types of whitespace and line-breaks which can make assertions very cumbersome.

This would also have the side effect of bringing includesText in-line with hasText.

Possible solution

All white space inside the element is collapsed into a single space, similarly to how it happens in HTML.

Possible implementation

Update this:
https://github.com/simplabs/qunit-dom/blob/632205606020d9d7e6aa3c0a83bb34502a65f9e5/lib/assertions.ts#L559-L565

to:

let collapsedText = collapseWhitespace(element.textContent);
let result = collapsedText.indexOf(text) !== -1;
let actual = collapsedText;
let expected = text;

if (!message) {
  message = `Element ${this.targetDescription} has text containing "${text}"`;
}

And apply a similar change to: doesNotIncludeText

References

• https://github.com/tradegecko/ember-semantic-test-helpers/issues/18

_{Edited upon finding the collapseWhitespace function}

It would be awesome if there was an easier way to run assertions on the selected <option> of a <select> element. Proposal:

assert.dom('select.foo').selection.hasText('Foo!');

instead of

assert.dom([...this.element.querySelector('select.foo').querySelectorAll('option')].find(it => it.selected)).hasText('Foo!');

Since a few days qunit-dom uses Array.from() in findElements(). It was introduced in this commit: 8b274f1

This is breaking tests in Internet Explorer 11 for Ember Bootstrap: https://travis-ci.org/kaliber5/ember-bootstrap/jobs/464077936#L1762-L1783 Array.from() is not supported in IE 11 and it seems like there isn't any transpiling done for it.

I have a translation string with HTML in it, and I wrote a test to verify that it renders, properly escaping the HTML.

My string looks like (simplified & redacted):
Something went wrong on our end. Please try again later or contact <a target="_blank" href="#support-team">our&nbsp;support&nbsp;team</a>.

My test looks like:
assert.dom('[data-test-not-found-subtitle]').hasText('Something went wrong on our end. Please try again later or contact our support team.');

In qunit I see this:

It seems like it isn't doing the right thing with the  . I've tried copying the qunit result line into my test string, and it still doesn't recognize a match.

This should assert if the value property of an element (e.g. <input>) equals an expected value.

During a debug session of a failing test I was trying to see why the assertion failed (to see why the query selector was incorrect). But executing the same assertion methods in the devtools console window returned undefined instead of the actual result of the assertion. It would help during debugging what the result of the assertion is so that I could try the same assertion with a different selector.

So for example the current behaviour is as follows

assert.dom('div .my-selector').exists() // Returns undefined

I would expect something like

assert.dom('div .my-selector').exists() // Returns false/true

So while using the isNotVisible, I tested on a selector that did not return any elements and got the following error:

assert.dom('.my_selector').isNotVisible();
// Throws: Element .my_selector exists

This message to begin with is a little cryptic because it doesn't mention visibility anywhere (which could be something we should look into). Secondly, elements matching the .my_selector don't exist! Exactly the opposite of what the error message suggests. This could be considered a bug, right? I think the offending code lies in findTargetElement with some interesting conditions:

  findTargetElement() {
    if (this.target === null) {
      let message = `Element <unknown> exists`;
      this.pushResult({ message, result: false });
      return null;
    }

    if (typeof this.target === 'string') {
      let el = this.rootElement.querySelector(this.target);

      if (el === null) {
        let message = `Element ${this.target || '<unknown>'} exists`;
        this.pushResult({ message, result: false });
      }

      return el;

    } else if (this.target instanceof Element) {
      return this.target;

    } else {
      throw new TypeError(`Unexpected Parameter: ${this.target}`)
    }
  }

Am I missing something? Or any ideas on a fix? I can submit a PR if necessary.

Would there be any room for an isVisible/isNotVisible assertion? Obviously you don't want to add every possible assertion under the sun to the library but if you think it's something that would be beneficial, I'd be happy to work on it.

This assertion should check if the required property of e.g. an <input> element is true or not.

Example:

assert.dom('.username-field').isRequired();
assert.dom('.coupon-code').isNotRequired();

Would there be interest in either modifying how the hasValue method works or adding a new one that works well with data-test-* attribute selectors?

A common pattern we use is: assert.dom('[data-test-record-id="1"]').exists(). This fails with the same message if either the data-test-record-id attr is not present or it is present but has a different value. It would make our tests easier to work with if we could do something like:

assert.dom('[data-test-record-id]').hasValue("1")

And then this could fail with one useful message if data-test-record-id is missing, or a useful diff when it is present but has a value other than "1".

Overloading the hasValue method doesn't seem quite right, so perhaps this is an enhancement request, to add a new method. Maybe hasSelectorValue?
If there's interest in adding this I'd be happy to make a PR for it.