Use Cypress and Storybook to test your React Components in Isolation

Instructor: [0:00] When adding Storybook to our React library, we use the Storybook configuration schematic. It's a flag we pass in the configure Cypress. Cypress is a very powerful end-to-end testing framework that allows you to control your browser and click through your application just as user would do.

[0:18] It is very similar to Selenium, but uses a different approach of controlling your browser that allows for a much better developer experience. As we have seen before in Nx, we can actually run a Storybook for a component.

[0:33] What this will do is serve up the Storybook in the browser, so we can navigate to the port 4400 and have our component served up here. What Nx does with that configure Cypress flag is use this component in isolation and test it with Cypress.

[0:50] This results in a very powerful combination. When we use that configure Cypress flag, what happened is that in our apps folder up here, we got a new end-to-end test folder, which is for our store UI shared.

[1:03] By also confirming to generate some spec, we also got automatically some generated test files for our component. That's why Story end-to-end has its own application in the workspace JSON. We can directly search it, which has a single target here end-to-end.

[1:22] Hence, what we can do is we can run this by using an nxrun command store UI shared end-to-end and use the end-to-end target. For now, let's use the --watch command that will open Cypress in watch mode.

[1:37] Behind the scenes, Nx now launches Storybook, such as it runs on 4400 and then in runs Cypress and points to that 4400 port. If you switch over, we see that Cypress test runner window that opens up. If you now click on header spec, it actually runs the Cypress test in Chrome to test our store UI shared header component.

[1:59] Right now, the preconfigured test here fails because it doesn't match the welcome to store UI shared message because we changed that in our component. Let's quickly fix that test.

[2:09] If you go back in our header spec, let's first of all see how that test works. What Nx generated for us here is it uses a feature of Storybook that allows you to serve up a single component.

[2:21] You can do that by using that iframe HTML and parse in SID, the ID of the component plus the configuration of the flex. In our case, our header story credits are property titled that for now has an empty value, which is also why in Cypress we have the test failure because no title is actually being displayed.

[2:42] We could now either add a title here or go to our test here and parse one in as a dynamic configuration. We also need to adjust the assertion, which is no more valid. Let's go back to Cypress, we can see that the test meanwhile has refreshed and now we see that game store, which we passed in as a header property here.

[3:02] We don't have an H1 here in this case, but let's simply use that element selector here and go over to our title element here, click it. Then we can copy that selector which we would get here on our header component.

[3:16] Let's go back, use that one. It should also not contain welcome to store UI shared, but rather game store, which is the one we're parsing as the title for our Storybook configuration.

[3:29] If we save again and go back, we see the task already refreshed, and now it's parsing. Now note, I'm using here that automated selector. Usually, it's a better practice to use data CI attributes that create much more robust tests.

[3:43] Obviously, why we've been using here the watch mode to get that Cypress test runner up and be able to interactively fix our test. In a CI setting, we wouldn't use the watch mode, but rather use something like the headless mode, which runs the Cypress only on your terminal.