Can the expenses for creating mock data in unit tests become a source of business profit? Absolutely! Here’s how.

Most web applications, whether they are healthcare portals or shopping carts, require seed data with a user set that reflects all variations of application data associated with those users. This set is a crucial part of the deployment process to run integration and end-to-end tests. It is also essential for smoke testing before A/B deployment activates the infrastructure components with new code.This is a well-known pattern used in most enterprise-quality software products.

Restricting such valuable data solely to the deployment process is a missed opportunity in various business use cases and throughout the Software Development Life Cycle (SDLC).

You might wonder how this data can have any business value?It seems like just an unavoidable product maintenance cost. And you would be right—until your app needs to be indexed by search engines and operable by AI assistants for user-specific parts of the application. Of course, exposing private user data is not an option. This is where synthetic personas from seed data become invaluable. Since this data set does not contain any real personal information, it is safe to expose to search engines and AI crawlers. If the app is developed with accessibility compliance and SEO in mind, these business goals can be achieved.

In SDLC the seed data can ( IMO should ) be propagated into mock data for the UI components and pages to be used in

* StoryBook

* unit tests

* serverless UI run

* e2e integration tests.

Data can be saved as a module, better with strict typing in place. If your project uses TypeScript, Java, or C#, that is the format to use. 

One of the advantages of GraphQL is its ability to generate client code for target languages such as TypeScript or Java. In similar fashion your script can crawl through all graphql queries in application and execute them on behalf of each synthetic persona in the data seed. The same mock generation routine should also generate the Mock Service Worker (MSW) handler to be used in StoryBook, unit tests, and serverless mode.

If your mocking frame with seed data that can be created ahead of UI components,  it would be a huge time saver for developers and QA as there will be no difference on data protocol on all those aspects of application front-end. 

Once the mocking is available for each synthetic persona, the MSW would help to run the front-end without back-end helping to validate the UI in isolation with the same test set as the full e2e/integration test. It would enable you to identify the tier which is responsible for the failed test without the need for manual troubleshooting for finding the guilty front-, back-, or DB side and forwarding to responsible team members if your tiers are implemented by different folks. Or just simplify the fix if your people are full stack developers. 

While SEO, search engine indexing, and AI vectors are separate topics,  here I just want to point out that pages with synthetic persona data would be publicly available, improving your site visibility and empowering your application users with AI assistants. 

My team has implemented most of the design outlined above, and is currently finalizing the business use. I would be glad to discuss the impact of such an approach on your product. 

Happy coding!

UI TDD with StoryBook

 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 )

1. For xxx module, create the xxx.stories.ts file either in the folder for component or in directory dedicated for stories
   

2. Inside of .stories.tx file you would keep the UI variations of component (similar to unit tests variations). Those would export

1. Parameters set for SB which should cover all use cases 

2. Template to render component UI with parameters ^^
   

3. 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!