One of the strengths of Nx is that it provides you easy access to some of the best tooling available. As such, whenever you generate a new app or lib inside an Nx workspace, it automatically preconfigures Jest for you and even sets up some pre-generated tests.
Instructor: [0:00] One of the main strength of an Nx workspace, apart of course, of having a monorepo situation and being able to easy to share code, is that it already sets you off with one of the best practices tools that are currently in the market.
[0:13] It happens all behind the scenes as you generate applications, components or libraries. For instance, in our case, if we open up the workspace JSON, we already have here in the store App for example target setup that allows us to execute testing against our application.
[0:29] By default here, Jest has been used. It already pre-configures Jest for you. If we open up App's store for instance, we see we already got a pre-generated spec file that can be executed with Jest. We also have a couple of Jest configuration-related items that have been generated for us, so we don't have to care about that.
[0:48] What we can do is we can invoke that target, that test target, which we have seen in our workspace JSON, just as we would execute our serve target or our build target.
[0:59] Again, we use Nx run store:test. This will now use Jest and execute all of the tests that are present in the store application. What do you see here, we get a failure. The reason is that we got a task generated here, for instance, our app.spec.tsx file, which got generated initially when we generated the application.
[1:19] Meanwhile, we obviously have changed our app component and we should have adjusted our test case already, but let's do that now. What I've inserted in my app component is some fetch calls.
[1:31] Without bothering you too much about the actual implementation, let me just add here a mocking for that fetch call and very easily also here replace that in our before each. Also, we need to change the greeting here obviously, it's no more welcome to store, but it should be something along the lines of boardgame hort. Let's again execute our test.
[1:57] You can now see that both of them passed. We still get some warning here, which is because we didn't wrap some of the parts of our component with an act function callback, which is needed in React when you manipulate the components by the state.
[2:11] In our case, we can easily handle that by wrapping our assertion of the base element and wait for that element to appear on our screen. Here, instead of expecting the base element, we use the findByTestId, and we import it from the testing library.
[2:30] Also, let's make this async, and now we have to add a test app container ID to our React component. If you open up the app.tsx component, we can here add a tag data-testid, passing that app container.
[2:47] With that, we should be able to find an element and verify it's actually present. Similarly, we need to modify here our greeting as title. What I'm doing here is I'm exporting here the base element again, and then I'll search based on that base element.
[3:02] In this case, I'm using actually find by text. Let's again, import that, make this Async. With that, we should be good. Let's open up our console again, run Nx stored:test. We get a passing React test.
[3:19] We have to apply the same things to our library, which is down here, which also uses fetch API behind the scenes, but I'll leave that to you as an exercise. Note that you can also obviously pass in here --watch, and that would open up the Jest-watcher.
[3:35] Now, you can have the same kind of developer experience as you usually have with Jest, so we can run all tests. We can filter out a single task and much more.