Getting Started
Part 3: Using Variables to Improve Your Test
What You'll Learn:
- Extending your test with new steps recorded in the browser
- Creating variables from content in the page
- Using JavaScript logic to create dynamic variables
Skip to part 4 to learn about accessibility testing and fixing failing tests.
In our previous test, we added an item to the cart and verified the right name showed up in the cart. Now let's verify the right price showed up. We can also verify that the total adds up correctly. Because we're working with dynamic data (products that can change), we'll use variables in these steps so that our tests won't fail just because a product price was changed.
Step 1: Add Steps to test
The Ghost Inspector extension can be used to record new tests, but you can also use it to add steps to an existing test. You can record as many as you need and put them before or after any step you need. For this tutorial, we're going to add some more steps to the end.
If you're not already there, open a browser window and navigate to demo.ghostinspector.com. If your cart is empty, be sure to add one item to the cart before you start recording.
Click the Ghost Inspector icon to open the recording extension and select Add steps to an existing test. If you have more than one suite, be sure to select the suite and test you created for this tutorial: "Your First Test" > "Add to cart". Keep "Add to end of test" selected and click Start recording!
Let's add another item to the cart. Since we're going to make this dynamic, it can be any product you like, but we'll use the "Eames Molded Plastic Side Chair". Instead of opening the details, you can just click the + (plus sign) to add it to the cart. You should see "Cart (2)" in the upper right-hand side of the site. Click on that to open the shopping cart.
What we're going to do now is record some assertions for the product prices. Switch to assertion mode now and click on the product prices in the right column. Click each price and then the subtotal. These are the values we're going to turn into variables in a bit.
Be sure to switch back to operations and click "Back to shop" so that your last test step resets the test back to the homepage. Otherwise, your test might fail the screenshot comparison.
Step 2: Add Variable Logic
Your test should still pass for now, but what happens when the products change? What if the product is removed or renamed, or goes on sale? Your test will fail and while it might be relatively easy to fix, the unexpected failure can cause a lot of stress! Let's use some variables to make our tests much less brittle!
On the test screen, click Edit steps. Scroll down to step 9, or whichever step asserts that the "Element text contains" $56 (the price of our cup planter). Let's change the action to Extract from element (under Store variables) and for the variable name, call it something like itemPrice1. Now find the other step which uses "Element text contains" and a product price. Do the same thing but name the variable something like itemPrice2.
After those steps, add a new step (click "Add below") with "Extract from JavaScript" and use the following code:
const price1 = parseInt('{{itemPrice1}}'.slice(1))
const price2 = parseInt('{{itemPrice2}}'.slice(1))
return price1 + price2
This will cut the "$" from the prices, convert them to numbers, and add them together. Save this new variable as totalPrice. Scroll down to the step where you verified that the .subtotal element text contains the total price. Replace the hard-coded total in the step with ${{total}}. Tada! You now have a dynamic test that adds up the prices in the shopping cart and verifies that the subtotal equals the right amount.
Run your test again to verify the new changes haven't broken anything.
What are these "selectors" anyway?
The test edit will show you every selector that will be used to either take an action (like a click) or make an assertion (like "element is visible"). If you're not familiar with selectors, you can read our blog post on CSS Selector Strategies for Automated Browser Testing.
These are the selectors that our extension automatically chose, but they may not always be the best. To keep your tests from breaking in the future, due to code or other dynamic changes, you should probably consider adding backup selectors that are more robust.
Summary: ...
Move on to part 4 to learn about accessibility testing and fixing failing tests.