testing-react VS pedalboard

For more details on implementation, please refer to the following link (the above code is also quoted from this link): https://github.com/storybookjs/testing-react

When I started to play with this idea the first option which came to my mind was to launch Storybook and then tell Cypress to navigate to the component’s iFrame source url and start interacting with it. It can work but it has some challenges, like making sure the Storybook is up first, and how it is accessed on on-demand spawned environments in the build pipeline, but then another method presented itself to me - using a library that Storybook team has developed called @storybook/testing-react

Adding on to what others have said: you can use https://github.com/storybookjs/testing-react to reuse your storybook entries as test setup & really simplify your tests while making your storybook entries even more valuable.

You can check out some demo examples in this Storybook, and see the code in the pedalboard repo.

Turns out there are tools for that and one of them is called typescript-coverage-report by Alex Canessa and I’m going to give it a try now and implement it in my Pedalboard monorepo.

Also, all the code mentioned here can be found in the GitHub repository for this plugin. Put your testing helmet on, here we go!

My Components package currently supports regular plain-old CSS (not that there’s anything wrong with it), and I thought it was a good time to introduce SASS to it, but the package is not a ordinary “Webpack-build-that-s#!t-for-me”. I’m using TSC (TypeScript Compiler) to generate the artifacts - What it means is that TSC is compiling 2 versions of the component, ESM and CJS. Once we have these, we’re taking the ESM outcome and bundling it using esbuild. You can read more about it here, but if to put it visually:

In this post I will write a test suite for my @pedalboard/stylelint-plugin-craftsmanlint. We will be using jest-preset-stylelint to help us with that, and as a bonus, I’ll fortify the plugin’s TypeScript support.

For reference, below is an image of the Pagination component, and you can find it’s code here:

Disclaimer - I’m going to apply the following steps on my Pedalboard monorepo. Working with monrepos is a bit different, and I will relate to that during the process, but be aware that applying Chromatic on a “simple” repo is even simpler.

I have noticed that although the build process for packages under my “pedalboard” Monorepo creates different artifacts (CJS, ESM and types - you can read about it in more details in my “Hybrid NPM package through TypeScript Compiler (TSC)” post) it does not create a single bundle for the entire package.

I will attempt to introduce this visual regression testing to my Pagination component from the @pedalboard/components package. So here we go.

So let’s see how this tool works and what we can do with it. I’m gonna do my experimenting over my Pagination component which resides on the @pedalboard/components package. Let’s go!