Jest - how to test if a component does not exist? - jestjs

How do I check if a component is not present, i.e. that a specific component has not been rendered?

.contains receives a React Node or array of Nodes as an argument. Instead, use .find:
expect(wrapper.find('selector').exists()).toBeTruthy()

You can use enzymes contains to check if the component was rendered:
expect(component.contains(<ComponentName />)).toBe(false)

If you're using react-testing-library (I know the OP wasn't but I found this question via web search) then this will work:
expect(component.queryByText("Text I care about")).not.toBeInTheDocument();
You can query by Text, Role, and several others. See docs for more info.
Note: queryBy* will return null if it is not found. If you use getBy* then it will error out for elements not found.

Providing a slightly updated answer based on the documentation for enzyme-matchers's toExist. This will require you to install the enzyme-matchers package.
function Fixture() {
return (
<div>
<span className="foo" />
<span className="bar baz" />
</div>
);
}
const wrapper = mount(<Fixture />); // mount/render/shallow when applicable
expect(wrapper.find('span')).toExist();
expect(wrapper.find('ul')).not.toExist();

.contains does not expect a selector, unlike find. You can look at the length attribute of the ShallowWrapper
expect(wrapper.find('...')).toHaveLength(0)
I found I needed to use this syntax with Enzyme and Jest to test if a Connected Component existed in the rendered output.

We use Jest and Enzyme, and I've found the only good test is to import the sub-component and test this way:
expect(component.find(SubComponent).length).toEqual(0); // or (1) for exists, obvs
I tried all the other answers and none worked reliably.

If you are using react-testing-library, then this also will work:
expect(component.queryByText("Text I care about").toBeNull());
expect(within(component).queryByText("Text I care about")).toBeNull();
Note: In my case, I needed to use queryBy* because it doesn´t error out when the text element (that contains the text: Text I care about) does not exist. Therefore, I could evaluate whether there is an existence of a text component or not.

Related

Difference between toBeInTheDocument() and toBeDefined()

What is the difference between toBeInTheDocument() and toBeDefined() when testing with Jest and React Testing Library? When should they be used?
The #testing-library/jest-dom library provides a set of custom jest matchers that you can use to extend jest. These will make your tests more declarative, clear to read and to maintain.
It solve the below problem:
You want to use jest to write tests that assert various things about the state of a DOM. As part of that goal, you want to avoid all the repetitive patterns that arise in doing so. Checking for an element's attributes, its text content, its css classes, you name it.
From the source code of toBeInTheDocument(), it uses several DOM APIs such as Node.getRootNode() and Node.cloneNode(). You don't need to check if the element is present in the document on your own. This is very convenient and readable.
toBeDefined has nothing to do with DOM API, it's a basic matcher uses const pass = received !== void 0; to check if the value is defined or not.

Cypress test: is .contains() equivalent to should('contain')?

Is this: cy.get('[name=planSelect]').contains(dummyPlan)
equivalent to this: cy.get('[name=planSelect]').should('contain', dummyPlan)
And if so, which is preferred? The first is more of an implicit assertion, but it's shorter and cleaner to my mind.
Follow-up question: After looking around to see how best to select elements for e2e testing I found that the Cypress docs recommend using data-cy attributes. Is there a reason this would be better than just adding name attributes to the markup? Should name only be used for forms fields?
The result on your cypress test will be the same if the element with name=planSelect does not contain dummyPlan, that is, the test will fail at this point.
The difference between them is that in the first form, using contains(), you're actually trying to select an element, and the result of cy.get(...).contains() will yield this expected DOM element, allowing for further chaining of methods, like:
cy.get('[name=planSelect]').contains(dummyPlan).click();
In the second form you are making an explicit assertion to verify that dummyPlan exists within the other element, using the Chai chainer contain.
It is a subtle difference and the result is the same, but I would recommend you to use cy.get('[name=planSelect]').contains(dummyPlan) only in case you would like to chain some other method after contains, and use the second form if you want to explicitly assert that this element exists. Logically speaking, the first would represent a generic test failure (cypress tried to find an element that wasn't there) and the second represents an explicit assertion failure (element should contain dummyPlan but it does not).
As for your second question, name is a valid HTML attribute and using it for your tests can lead to confusion if the attribute is being used in its original function (to name input fields) or if the attribute is there just for testing purposes. I would recommend you to use cy-name as the documentation suggests because this way you avoid this ambiguity and make it clear that this attribute cy-name is only there for testing purposes.
Furhtermore, on some situations you might decide to strip all cy-name from your code before sending it to production (during the build process, using some webpack plugin, like string-replace-loader). You would not be able to do the same if using just name because you would also remove the required input name, if there was some inputs in your code.
Answer
.contains(selector, content) is the best selector; it retries
element selection AND allows text matching (not just <tag>
.class #id [attributes])
.should() is just an assertion and only the assertion is retried
(not the element selection)
.should('exist') is implied unless you specify your own -- this is how they allowed .should('not.exist')
Tangent
Browsers support XPath 1.0 which is a pretty cool but obscure way to make complex queries based on DOM tree traversal. There's a contains predicate function:
//*[ contains(normalize-space(.), 'The quick brown fox jumped over the lazy dog.') ]
[not(.//*[contains(normalize-space(.), 'The quick brown fox jumped over the lazy dog.') ])]
This searches from root of the document for any node that contains the text and doesn't contain a descendant node which contains the text.
You can test it in the console with the Chrome $x() shortcut or this polyfill (and helper):
getLowestDomNodesByText("The quick brown fox jumped over the lazy dog.")
function getLowestDomNodesByText (text) {
return x(`//*[contains(normalize-space(.), '${text}')][not(.//*[contains(normalize-space(.), '${text}') ])]`);
};
function x (expression) {
const results = new XPathEvaluator().evaluate(expression, document);
const nodes = [];
let node = null;
while (node = results.iterateNext()) {
nodes.push(node);
}
return nodes;
}
If you need even more performance, you can use a TreeWalker with NodeFilter.SHOW_TEXT as seen in this chrome extension I've worked on for a long time
I recommend to use contains after get then verify existence with should.
cy.get('[name=planSelect]').contains(dummyPlan, {matchCase: false}).should('exist')

Ember 2.0 with Ember-CLI, how to access 'document.location.host'?

Putting following line e.g. in app/controllers/application.js
console.log(document.location.host);
will not work, as the browser-context is not present.
What is the alternative? It should also work with other javascript objects.
solved: it was a structure error (novice)
import Ember from 'ember';
export default Ember.Controller.extend({
myInfo:'test',
i: console.log(document.location.host)
});
is working. Important is to put 'i:' or 'initialize:' on a freshly generated controller (after ember g controller app) as {} expects of course a js-hash-object and not a sequence of statements.
Solved. I just had to be aware that .extend(...) is not expecting code-statements per se, but a Mixin-class. So practically it needs a property-name (e.g. i or mySpecialInit syntactically followed by colon : and a function or here directly a statement console.log(document.location.host) ).

Optional Partials in DustJS

Is it possible to have optional partials in Dust? Let's say I define a layout like this:
<div>
{>"{module}"/>
</div>
I have been defining the module in Express's res.locals object. However, what if I forgot to define a module, or I actually want a default module for use when I do not define one? Worse, what if I did define one but it's the incorrect module, meaning there's no template file in the view folder with the name of that module? I don't want the user to see the ugly error message, which seems to be something like:
Error: ENOENT, open 'view_path\{module}.dust'
where {module} is the name of the module, or an empty string if I did not specify a res.locals.module. Should I resort to try-catch blocks (not even sure how to do them in dust), or is there a method for making templates optional, rather than required? NOTE: The template would be optional, but the module variable would (usually) still be a string. It seems that dust sections are optional, meaning if the exact key is not available, the section is simply not included. For example, say I have the context {friends: [{name: "Harry"}, {name: "Ron"}, {name: "Hermione"}]}. If I define the section:
{#friends}
{name} is {age} years old.
{/friends}
it will output
Harry is years old.
Ron is years old.
Hermione is years old.
Notice there are 2 spaces between is and years in each case, where the age would be if we defined any ages. If this functionality is included, how is it that neither the original creators of dust nor LinkedIn thought to not require partials? How do I specify optional partials in dust?
You could use a conditional like so,
<div>
{?module}
{>"{module}"/>
{:else}
{>"{YourDefaultPartial}"}
{/module}
</div>
This will work when {module} is either undefined or an empty string or a falsey value.
But, in case its a string pointing to a partial that does not exist, it'll throw an error. Hope this helps.

Passing variable from jade to ng-init not working

I'm trying to pass an object from jade to ng-init in angular
This: doesn't work:
ng-init='tables=!{JSON.stringify(tables)}'
This: expands but,
ng-init='tables=#{JSON.stringify(tables)}'
the output is unescaped and filled with "s
ng-init="tables={"12":{"id":....
and the view isn't updated in either of the cases. This article implies that first one should work, but like I said, it doesn't even expand,
ng-init='tables=!{JSON.stringify(tables)}'
in source code shows up exactly the same in the HTML source
ng-init='tables=!{JSON.stringify(tables)}'
Actually, the #{...} approach seems to work fine.
It is probably the way console.log prints attributes' values that confused you.
ng-init="tables=#{JSON.stringify(tables)}"
Take a look at this short demo.
In what use-case you want to pass data directly from Jade to angular? I think you could to this job in controller like this :
$scope.init = function () {
// init stuff
}
...and in your view :
ng-init = init()

Resources