The Test Driven Development process assumes the incremental steps of module logic improving starting with unit test following the implementation in the source code. As unit test is created, it immediately should fail as the logic still has to be done. Once logic is in place, the next feature added to the unit test and the cycle repeats…
The UI development used to be different as there was no ability to do the checks and incremental code improvements. The module (UI component) used to be tested within the web application without insulation and ability to visualize the variations without app state change or the following the whole flow leading to the UI variation. Till the StoryBook became a natural part of UI SDLC.
What is a StoryBook? It is a toolkit for various aspects for UI development.
When installed inside of the web UI project as a NPM module, it allows to run the components collection with all variations within the StoryBook interface which is not attached to the actual web app your team is working on. Instead, it exposes the collection of UI components hierarchically organized and exposes the samples of the UI variations and use cases.
Of course the UI has a lot of aspects besides basic variations. Those include but not limited to:
Color theming: dark, light, high contrast light/dark
Language switch
Various screen sizes and mobile variations
Accessibility:
blurred vision, limited colors, etc.
Screen reader
Keyboard navigation
Set of mocked user roles
And so on… All the listed is covered by StoryBook making it “a must” part of the UI development stack. Which is especially important for enterprise grade applications bound by various compliance requirements.
Compliances aside, StoryBook gives the frame to practice TDD during UI component development. Once the SB UI is running, developers would be able to work on individual UI component in insulation.
( in examples I use the “native” JS web components, the React or Angular typescript module work in similar fashion )
For xxx module, create the xxx.stories.ts file either in the folder for component or in directory dedicated for stories
Inside of .stories.tx file you would keep the UI variations of component (similar to unit tests variations). Those would export
Parameters set for SB which should cover all use cases
Template to render component UI with parameters ^^
Use cases. A template to particular parameters binding.
Once the use cases created, they would be listed in SB interface. To work with component in insulation, there is a “Open Canvas in new tab” button:
That is where the primary development for your component would be shown:
As SB is served in the browser, the dev tools at your service to inspect the UI styles, debug code, etc. The code hot reload allows you to change the code and immediately see the affected UI.
StoryBook gives you the ability to integrate with Figma and other UI design services. The link inside of your story would lead to the UI design to compare the components against design.
Once your component is ready and becomes a part of the application, it is important to check whether following changes break any UI appearance. The pixel comparison tools like Chromatic or SauceLabs Selenium would give you ability to:
See the pixel difference between original and code in pool request
Engage UX team in visual changes approval
That assures there are no UI regressions introduced by pool request.
Here we touched just UI TDD aspects, but other features by SB are not less important in enterprise grade UI.
The StoryBook is well detailed on https://storybook.js.org and covered by multiple web and video blogs.
<custom-element> test project used as example. Happy coding!
