I use this long line to check the selected value on any list on my page (using Ember power-select which is not a but a complex set of ), selector being the parent so I can target the list I want, and trimming being there so I can chain a .should('eq', expected_value)
cy.get(selector).find('span[class="ember-power-select-selected-item"]').invoke("text").then((text) => text.trim())
I would love to shorten all the commands after get in one, and be able to call something like
cy.get(selector).selected_value()
I've started reading on custom commands, wrap, invoke... but am too new on Cypress to understand the right way to do this.
To add a custom command, you may add the following inside cypress/support/commands.js file:
Cypress.Commands.add('selected_value', { prevSubject: true}, (subject) => {
return cy.wrap(subject).find('span[class="ember-power-select-selected-item"]').invoke("text").then((text) => text.trim())
})
Note that we use the prevSubject option to be able to chain our command from an initial cy.get(selector) one.
And now you are able to use the command:
cy.get(selector).selected_value().should('eq', expected_value)
Also, it's better to provide a type script definition file for the new command so IDE can be aware of it and provide the autocomplete and other features.
Adding a command might look a bit complicated for a beginner or annoying for an experienced user. There is Cypress Pro plugin (I'm the author) for the IntelliJ platform that can simplify creating and maintaining custom commands.
Creating a custom command can make your test more readable, encapsulate a group of commands that are repeated and need to be parameterized.
For your example testing the text of dropdown items, you can pass in the text and return the select so that chaining is possible
NOTES
In your code, .find().invoke("text") returns all the item text in one string, so I added .contains() to select an individual item.
If you're only interested in a partial match, the command chain can stop at .contain(text.trim())
Cypress.Commands.add('hasSelectedItemText',
{ prevSubject: true },
(subject, text) => {
cy.wrap(subject)
.find('span[class="ember-power-select-selected-item"]')
.contains(text.trim())
.invoke("text")
.should('eq', text.trim())
cy.wrap(subject) // returns the original select
}
)
cy.get(selector)
.hasSelectedItemText('one')
.hasSelectedItemText('two')
.hasSelectedItemText('three')
A more complicated example using the dual type command. Here the command can be parent or child, so the parameters have different meanings depending on usage
Cypress.Commands.add("dropdownItemText",
{ prevSubject: "optional" },
(subject, arg1, arg2) => {
if (subject) {
const text = arg1
cy.wrap(subject)
.find('span[class="ember-power-select-selected-item"]')
.contains(text.trim())
.invoke("text")
.should('eq', text.trim())
cy.wrap(subject) // returns the original select
} else {
const text = arg2
cy.get(arg1)
.find('span[class="ember-power-select-selected-item"]')
.contains(text.trim())
.invoke("text")
.should('eq', text.trim())
cy.get(arg1) // make select the returned "subject" for further chaining
}
}
)
cy.dropdownItemText(selector, 'one')
.dropdownItemText('two')
.dropdownItemText('three')
Related
I have a scenario, where i need to put Assertion on an element's text which could be true OR pass the test case, if the any 1 value is present out of many.
Let say, an element can contain multiple status' : 'Open', 'Create', 'In Progress' any of these could be true.
How can i implement this scenario and Assert with OR logical operator or any other way?
cy.get('element').should('have.text', 'Open' | 'Create')
It sounds like a one-of assertion, something like the following:
cy.get('element')
.invoke('text')
.should('be.oneOf', ['Open', 'Create'])
To do it you need to extract the text before the assertion.
For reference see chaijs oneOf
Asserts that the target is a member of the given array list. However, it’s often best to assert that the target is equal to its expected value.
These both Worked:
cy.get('element')
.invoke('text')
.should('satisfy', (text) => text === 'option1' || text === 'option2')
OR
cy.get('element')
.invoke('text')
.should('be.oneOf', ['option1', 'option2']);
Wodens answer is most valuable if you wish to make an assertion and have the test fail if one of them doesn't exist
However, if you want to check the text of the element that is visible and do separate things based on which one is available:
cy
.get('element')
.filter(':visible')
.invoke('text')
.then((text) => {
if(text.includes('Open')){
// Things that only occur when Open is present
} else if (text.includes('Create')){
// Things that only occur when Create is present
} else if (text.includes('In Progress')){
// Things that only occur when In Progress is present
} else {
// Things that happen when the options are exhausted
}
});
https://docs.cypress.io/api/commands/wait - cy.wait() is used to wait for an arbitrary number of milliseconds.
What's the difference in the following two snippets
// snippet-1
cy.wait(10*1000);
// other code
// snippet - 2
cy.wait(10*1000).then(()=>{
// other code
})
I tried to run the following code to test how it is working and i got the output mentioned in the below image.
cy.wait(10 * 1000).then(() =>
cy.log("This is inside wait()" + new Date().toLocaleTimeString())
);
cy.log("This is after wait()" + new Date().toLocaleTimeString());
These are the log results:
From the above image, it looks like we should add our code inside .then because that will be executed after cy.wait . I also have seen people writing their test cases just like snippet-1
Which one is correct and which one we should use?
If you want a better log, use a custom command to make a version that defers evaluating the value.
By providing a callback, the new Date().toLocaleTimeString() expression evaluates when you expect it to.
Cypress.Commands.add('logLazy', (thingToLog) => {
if (typeof thingToLog === 'function') {
cy.log(thingToLog())
} else {
cy.log(thingToLog)
}
})
cy.wait(3_000).then(() =>
cy.log("This is inside wait()" + new Date().toLocaleTimeString())
);
cy.log("This is after wait()" + new Date().toLocaleTimeString());
cy.wait(3_000).then(() =>
cy.logLazy("This is LAZY LOG inside wait()" + new Date().toLocaleTimeString())
);
cy.logLazy(() => "This is LAZY LOG after wait()" + new Date().toLocaleTimeString());
Cypress commands use the current value of variables and resolve function values when enqueuing commands. So, in your example, the commands are enqueued as .wait() and then the outer .log(). The value of the date string is calculated when the command is enqueued. The inner .log() is enqueued within the .then(), and thus has a later date string.
Either snippet is fine to use, but be aware of how the subsequent commands in your test will react. Are you manipulating some variable during your .wait(), and you would not want the original value to be used for your Cypress command? Probably a good idea to place that command within a .then() or some other Cypress command. Are you just interacting with the website and need to wait 10 seconds? You probably don't need to worry about placing commands inside .then().
I have set up a number of intercepts in the body of my tests. Here they are, pasted from the Cypress log, with the alias added
cy:intercept ➟ // alias: getRecipesSku(971520)
Method: GET
Matcher: "https://wpsite.com/wp-json/wp/v2/posts?tags[]=6287&_fields**"
Mocked Response: [{ ... }]
cy:intercept ➟ // alias: getRecipesSku(971520,971310)
Method: GET
Matcher: "https://wpsite.com/wp-json/wp/v2/posts?tags[]=6287&tags[]=6289&_fields**"
Mocked Response: [{ ... }]
Our application's tests also mocks a number of routes by default, (coming from an apiClient.initialize) including this one below. FWIW, this is defined earlier than those above:
cy:intercept ➟ // alias: getJustcookRecipes
Method: GET
Matcher: "https://wpsite.com/wp-json/**"
Mocked Response: [{ ... }]
My test code sets up those first two intercepts, and ultimately calls the routes. Here is the code, heavily abridged:
it('refreshes the recipes when switching protein tabs', () => {
apiClient.initialize()
/* do lots of other stuff; load up the page, perform other tests, etc */
// call a function that sets up the intercepts. you can see from the cypress output
// that the intercepts are created correctly, so I don't feel I need to include the code here.
interceptJustCook({ skus: [beefCuts[0].id] }, [beefCut1Recipe])
interceptJustCook({ skus: [beefCuts[0].id, beefCuts[1].id] }, twoBeefRecipes)
// [#1] select 1 item;
// calls route associated with intercept "getRecipesSku(971520)"
page.click.checkboxWithSku(beefCuts[0].id)
/* assert against that call */
// [#2] select 2nd item (now 2 items are selected);
// calls route associated with intercept "getRecipesSku(971520, 971310)"
page.click.checkboxWithSku(beefCuts[1].id)
In the Cypress logs, the first call (marked by comment #1) is intercepted correctly:
cy:fetch ➟ (getRecipesSku(971520)) STUBBED
GET https://wpsite.com/wp-json/wp/v2/posts?tags[]=6287&_fields=jetpack_featured_media_url,title.rendered,excerpt.rendered,link,id&per_page=100&page=1&orderby=date
However, the second call (marked by comment #2) is intercepted by the wrong route mocker:
cy:fetch ➟ (getJustCookRecipes) STUBBED
GET https://wpsite.com/wp-json/wp/v2/posts?tags[]=6287&tags[]=6289&_fields=jetpack_featured_media_url,title.rendered,excerpt.rendered,link,id&per_page=100&page=1&orderby=date
You can see for yourself that the URL called at #2 does indeed match the getRecipesSku(971520, 971310) intercept, but it is caught by the getJustcookRecipes intercept. Now, I suppose the URL for that latter intercept would catch my second custom intercept. But it would also, in the same way, catch my first custom intercept, but that first one works.
(update:) I tried commenting out the place in the code where the getJustcookRecipes intercept is created so that it doesn't exist. Now, the call that should hit getRecipesSku(971520,971310) isn't being mocked at all! I checked and the mocked and called urls are a match.
Why is this going wrong and how do I fix it?
Something in the glob pattern for the 2nd intercept #getRecipesSku(971520,971310) is refusing to match.
It's probably not worth while analyzing what exactly (you may not be able to fix it in glob), but switching to a regex will match.
See regex101.com online test
cy.intercept(/wpsite\.com\/wp-json\/wp\/v2\/posts\?tags\[]=6287&tags\[]=6289&_fields/, {})
.as('getRecipesSku(971520,971310)')
The request query string may be badly formed
Looking at the docs for URLSearchParams, the implication is that the query string should be key/value pairs.
But the 2nd request has two identical keys using tags[] as the key.
It looks as if the correct format would be /wp/v2/posts?tags=[6287,6289] since the square brackets don't have a lot of meaning otherwise.
It may be that the server is handling the format tags[]=6287&tags[]=6289, but Cypress is probably not. If you run the following intercept you see the query object has only one tags[] key and it's the last one in the URL.
cy.intercept({
method: 'GET',
pathname: '/wp-json/wp/v2/posts',
},
(req) => {
console.log('url', req.url)
console.log('query', req.query) // Proxy {tags[]: '6289', ...
}
)
#Paolo was definitely on the right track. The WP API we're consuming uses tags[]=1,tags=[2] instead of tags[1,2] so that's correct, but some research into globs showed me that brackets are special. Why the first bracket isn't messing it up but the second one is, I'm not sure and I kind of don't care.
I thought about switching to regex, but instead I was able to escape the offender in the glob without switching to regex and needing to escape aaaallll the slashes in the url:
const interceptRecipes = (
{ category, skus }: RecipeFilterArgs,
recipes: Recipe[]
) => {
let queryString = ''
if (category) queryString = `categories[]=${CATEGORY_MAP[category]}`
if (skus) {
const tagIdMap = SkuToTagIdMap as Record<number, { tagId: number }>
// brackets break the glob pattern, so we need to escape them
queryString = skus.map((sku) => `tags\\[]=${tagIdMap[sku].tagId}`).join('&')
}
const url = `${baseUrl}?${queryString}${otherParams}`
const alias = category ? `get${category}Recipes` : `getRecipesSku(${skus})`
cy.intercept('GET', url, recipes).as(alias)
}
How do I write this test in Cypress?
enter image description here
I have to confirm that either the headline or paragraph should contain the same keyword.
It's better to have JQuery elements in hand before the assertion so that you can use JQuery methods on them. cy.get() acts just like $(...) in JQuery, it will be enough to have the elements. (more here)
Once u have the elements, i.e. $el1 and $el2 below, then you can get their text via .text() method (more here) and then you can write your assertion.
Instead of a separate assertion, below I used a single one and checked if either of them includes the desired text by using || operator.
cy.get('first-el').then($el1 => {
cy.get('second-el').then($el2 => {
const inEl1 = $el1.text().includes('FIFA');
const inEl2 = $el2.text().includes('FIFA');
expect(inEl1 || inEl2).to.be.true;
});
});
Among many, One of my test looks like
it("Admin is able to edit new group", () => {
cy.intercept("PUT", /\/api\/groups/).as("editGroupAPI");
cy.get("#groups").then(groups => {
const group = groups[0];
// go to edit page cancel and come back to groups page
app.groupsPage.card
.groupActionIcon(group.name, "modify")
.scrollIntoView()
.click();
app.commonElements
.toolBarTitle()
.should("have.text", "Edit Group");
app.groupsPage.groupDetailsForm.cancelButton().click();
app.commonElements.toolBarTitle().should("have.text", "Groups");
// edit group - 1
app.groupsPage.card
.groupActionIcon(group.name, "modify")
.scrollIntoView()
.click();
app.groupsPage.groupDetailsForm
.groupDescription()
.type(" edited");
app.groupsPage.groupDetailsForm.saveButton().click();
cy.wait("#editGroupAPI");
// validate that Groups page have loaded
app.commonElements.toolBarTitle().should("have.text", "Groups");
// validate whether group card description is reflected on card
app.groupsPage.card
.groupDescription(group.name)
.should("have.text", group.description + " edited");
});
});
app is top level parent obj, and this test uses Page Object Model.
One example of POM class is :
class CommonElements {
burgerMenu() {
return cy.get("#widgets-banner-appBanner-sideDrawerButton-content");
}
toolBarTitle() {
return cy.get("h1.app-toolbar__title__main-title");
}
toolBarTitleWithText(text) {
return cy.contains("h1.app-toolbar__title__main-title", text);
}
globalScopeButton() {
return cy.get("#global-scope-switch-toggleSwitch-button");
}
}
So as it is evident that, cy.wait() and then call to pageObjectModel function to grab title element:
cy.wait("#editGroupAPI");
// validate that Groups page have loaded
app.commonElements.toolBarTitle().should("have.text", "Groups");
Now sometimes this fails, so as I have seen in docs, plain js code get executed immediately, but since in this case whole test is wrapped in cy.get("alias"), will it still matter (or execute js immediately)?
This might sound very obvious, but I just want to confirm.
Final question: does mix usage of Page Object Model functions and cy.command contribute to test flakiness?
Short answer: no, mixing Cypress commands with Page Object model functions does not itself contribute to test flakiness.
Explanation: a Cypress command is never executed immediately. It does not matter if a Cypress command is called in any 'external' function (including a POM function) or directly in a test case function. Either way, Cypress commands are only enqueued when statements of a function are executed. And they later will be executed in the same order regardless whether they defined inside 'external' function or test case one.
This is also true for a command that was called inside a cypress synchronous block of code (in a then/should callback). Even in this case the command will not be executed immediately.
In a nutshell, using a POM function to call a Cypress command does not influence on how and when this command is executed and so using POM approach can not itself contribute to any test flakiness.
You can play and see the order of command execution using such a script:
You can either open Dev console to see the console output or use breakpoints to see the execution live.
The gif above shows the debugging directly from IDE (IntelliJ) using the Cypress Support Pro plugin