-
Notifications
You must be signed in to change notification settings - Fork 5
4) How to write a Jest test
Before we actually write our tests, we need to make a jest test file inside of our lightning web component folder! Let's go through the steps of creating a jest test for an LWC below:
-
If you haven't done so yet, make sure to create your LWC, we need to make it first so that we can put our jest test file in the same folder as our LWC!
-
Once your LWC is created, create a folder named "tests" inside your LWC folder.
-
After your folder "tests" is created inside your LWC's folder, create a new js file and name it "theNameOfYourLWC.test.js"
-
Batta Boom, Batta Bing, you ready to make a jest test now fam.
Note: In Illuminated Cloud 2 you can just right click on your LWC's folder, go to New -> "Lightning Web Component Javascript Test File" and it will do steps 2-3 for you automatically.
Depending upon the complexity of your Lightning Web Component, your jest test could be simple, or it could be complicated, but either way these basic concepts are important. Let's take a look at a very very veryyy basic jest test example and break it down piece by piece.
Simple jest test example:
describe('Addition function', ()=>{
test('2+3=5', ()=>{
const num = 2+3;
expect(num).toBe(5);
});
});
The above example is extremely simple, in fact, it's so simple it's not even testing an LWC! But you should see three key words in there. Those keywords are "describe", "test", and "expect". Let's go over each below:
describe - This keyword defines a test suite (or groups multiple tests together). Use this if you would like to group multiple similar types of tests together in a single block.
test - This keyword can also be replaced with the keyword "it", either one will work here, but I personally prefer the keyword "test" as I think it's more clear what you are writing, because what you are writing is indeed a test! The "test" keyword indicates the start of a single jest test method.
expect - This keyword is used when you want to test the value of something! For instance, we "expect" our variable named "num" "to be" the value 5 and what that expect keyword is doing above is checking to verify if that is true. It's very similar to the Assert class that you use when writing tests in Apex! If you would like to see a list of all of the "matchers" that can be appended to the end of the "expect" keyword (like "toBe" in the example above), you can check out a list of all of them here.
In Apex when you want to have something setup for you prior to a test method running you would use a method annotated with @testSetup. The beforeEach and the afterEach functions in jest work in the same way. beforeEach runs code before each of your jest tests run and the afterEach funtion runs after each jest test runs. Pretty niftyyyyy. Let's check that magic out in action.
beforeEach Example:
beforeEach(()=>{
console.log('I run before your test runs!');
});
afterEach Example:
afterEach(()=>{
console.log('I run after your test runs!');
});
The above examples are obviously very simple examples just to give you an idea of how these methods are setup and how they work, in reality you will likely be setting up or tearing down html elements that you need for testing in your jest tests in these methods, should you decide to use them. Just as a reminder though, these methods run before or after EVERY SINGLE JEST TEST. So make sure you need the code in them running before each test and that the code won't be detrimental to any of the individual jest tests in your test js file.
More than likely the vast majority of your LWC's have a UI component to them and the only way to properly test them would be to test that values actually were populated and displayed in the html file of your LWC. You might be thinking, "Yea, you right, but how the heck can I test that? No one is viewing the lwc during the jest test...". No worries fam, there's an answer to that in the form of "import {createElement} from 'lwc'". We're gonna use that import to build our LWC's html so we can test it properly! Yay!!
Let's take a look at a simple example of this in action:
import {createElement} from 'lwc';
import componentYouAreTesting from 'c/componentYouAreTesting';
describe('componentYouAreTesting Test Suite", ()=>{
test('example creation of dom element', ()=>{
const testingComponent = createElement('c-component-you-are-testing', {
is:componentYouAreTesting;
});
document.body.appendChild(testingComponent);
});
});
The above code has successfully appended the lightning web component named "componentYouAreTesting" to the DOM and now you will be able to test whether or not data gets appended to that element successfully! Let's figure out how to setup a bit more complicated scenarios below, and how we can actually verify DOM elements get filled out as expected.
Data binding in your html file of your LWC is likely one of the most common things you do in all of your LWC's. In this section we're gonna figure out exactly how to test that those data binds are displaying exactly what you intended for them to test. So let's get to it!
Chances are in the vast majority of your LWC's you're going to have js events incorporated somewhere, maybe a simple onchange event, or maybe a CustomEvent you made for your particular needs! In any event, we need to learn how to test those bad boiz, so let's get to it!
Conditional rendering is pretty common in most LWC's, and making sure that an element is only rendered in the right scenario is crucial to ensuring your component works as intended (pending that's a feature of your LWC of course lol). In this section we're gonna find out how to test those scenarios, so let's check, check, check it outttt.
Iterators, for:each and everything inbetween are gonna show up in tons of LWC's you make, and figuring out how to test them isn't the most obvious thing in the world. Let's go through a couple examples together on how to test iterators of every kind in your LWC's.
Got a component inside your component? Child components are likely a part of any quality made LWC and we absolutely need to know how to test that they are reacting right as well, so let's run through an example together of how to figure out whether your parent LWC's sweet cute little child LWC is working as expected below.
You, me, and your best friend Jean Ralphio have all got @wire methods in our LWC's whether we like it or not, let's figure out how to test those cutie pies below.
If you aren't callin Apex somewhere in your LWC, was it even worth writing? Probably not. Lol, ok, that's definitely not true, but we still need to know how to test those Apex calls within our LWC's when we make them, so let's figure out how, ok pal??