Video Demo: Unit Testing JavaScript/TypeScript in AEM with Jest

Following up to the previous article on Unit Testing in AEM with Jest, I have created a video demo to show how you can do this yourself. You can follow along using the Sandbox code we provided.

Watch the Demo

Transcript

[00:04:13] Animation opening sequence with 3|SHARE logo and waves. 3|SHARE Senior Developer Hiten Patel presents AEM Unit Testing with Jest .

Hiten Patel: Hi everyone today, I'm going to be walking through the configuration required to run Jest unit tests within AEM builds. This is to ensure that we, we do have tests that they're passing and when they don't pass, it actually breaks the build. To download the referenced a repository with the sandbox code, please refer to the link in the blog post.

But that said, let's begin. As you can see we're using the Maven archetype for the ui.frontend module, for this example. Within the ui.frontend module, we have created a test directory where all of our tests will be housed. As you can see in the sandbox.Test.ts and sandbox-fixture.ts. Alongside with this, we have the setupTests.ts file.

And this ensures that before each of the tests are run, modules [00:05:13] that we've required are reset so we get a fresh version of the required modules each time, a new test as run. And this is to avoid any issues with caching of stale modules. . So this set up dot test file, setupTests.ts file, excuse me is referred to within the jest.config.js, as you can see. Set up falls off, and this will make sure anything that we have in this file eh is run after the environment is fully set up. We also have the clearMocks, the setting here that's set to true, and at the moment we don't have any,  tests currently within the code base that,  uses any mocks, but, mock calls or mock instances of any sort,

but if, if there are in future,  this ensures that we clear them on each test run. Also, we have the collectCoverageFrom, and it's [00:06:13] exactly that. So we just point to, the location of where our main scripts are kept and it will do a comparison, um, and generate a coverage report based on that, which I'll show you in a bit. But this just references, the location where, our main scripts are kept.

So, um, most of them would ideally be kept within this site directory here. And as you can see the sandbox.ts file is there. And the last one, setting is, the test environment. So by default it uses node js , but because we're testing against the DOM, with AEM and everything AEM at the moment,  we have set this as jsdom.

So next we would need a way to, run these tests. And that's done within the package.json as npm scripts. So [00:07:13] we have a script here called test and that effectively just runs Jest with a flag--passWithNoTests. And that's provided because if there aren't any tests, it will not fail. So we can, we can do that now, so we can see into the ui.frontend.

And then,  we do npm run test and this will just run our tests. The next one is test-watch. So this is, useful for a developer when writing tests. So if we run that, so we just do the test-watch, and then we go to our test here for example. Let's just go to the first one. So this, this is something we ensure that the component is available in the DOM and [00:08:13] that's done through the fixture here.

Once the fixture is loaded as part of the html of the body, we can safely say that it, the component is added to the DOM, and, at the moment, yeah, assertion "is" expects the container not to be null, so expects it to be on the page. To remove the not, this has tries to assert back. It's not null. Sorry,

it is null. . Then, it should fail, which it does as you can see, and it did that in real time. So that's great. And back to the passing test. And it passes. So, yeah. So that's the test-watch. And not only does it watch for the test files, it also watches for the actual main script as well. So, that's great. So the next one is the test coverage script.

So the test-coverage [00:09:13] will, do the same, but we're just passing the coverage flag with that so that we can get a report on how many lines I've covered, how many branches, how many functions, et cetera, et cetera. So we can do that with coverage here.

Ideally the coverage it should be around 80% plus. As you can see, it's a hundred percent here. Um, this is,you know, the perfect scenario, but it's probably unachievable as, , when we have a ton of scripts across the site. So generally I'd say if we are 80% or above, then that's pretty good. So yeah, as you can see that, we've got the coverage now and we've got all the different, ways to run the tests.

But the main way, the main thing that we're after is running as part of the Maven build. So, [00:10:13]um, the Maven build picks up the prod script. Um, I can show you that as part of the UI frontend POM file. So as you can see here, NPM run prods. So the goal is NPM, the argument is passed in as runprod.

So whenever we do run Maven build, it would run this script. And we've added the NPM run test, before webpack concatenation and the actual build of the bundle. So what we can do, let's see this, so we're in the main directory and we can runmvn clean install which triggers the Maven build.

And we can, if we look close to them, look closely on the output, we can see,  where [00:11:13]exactly in the test is run. So it does the npm front end here. It is part of the UI Frontend module. Then here we go to just positive tests and you can see what tests are positive breaking, so they should continue one and succeed the mills. And as you can see, we've got better success. So, um, to prove that the build fails, we can do something similar to what we did previously. So remove the not. So we, at the moment we expect the container toBeNull which is not because it's added as part fixture, and then let's run the Maven clean install again.

We should expect it to pass.

Yeah, which is exactly what we want. So, when we have failing tests,  [00:12:13] actually we'll break the build. So that's perfect, um, and concludes our demonstration. So, um, thanks for watching. For further details, please refer to the blog posts. And if there are any questions in the meantime, please drop us a line at 3|SHARE.

We'll be more than happy to help. Thank you.

A closing slide shows that you can contact 3|SHARE. And the 3|SHARE logo animation displays again

Get in Touch

Questions about this or do you have a problem 3|SHARE's Adobe Experience Cloud experts can help with? Contact 3|SHARE and we'll put you in touch with the right person. Just visit our Contact page and submit the form.