Forem: Ivan Malov

Front-end testing in 2024

Ivan Malov — Mon, 15 Jan 2024 08:15:14 +0000

Hello everyone! My name is Ivan. I'm building Frontend and interfaces more than 10 years. As it happens, I've been deeply immersed in the topic of front-end application testing for the past few years. I noticed that this topic has become much more popular than it was a few years ago. This is especially noticeable in the appearance of new testing tools. Despite this, writing tests still raises a lot of questions, especially in young teams. That's why I decided to write a short article about why and when you should write tests, how to motivate yourself and your team to do it, and what you should try to use when writing tests in 2024.

Who is this guide for?

First of all, I'm writing this guide for myself. I wanted to collect all my current knowledge about testing that I know at the moment and structure it. Since I am primarily an engineer, this guide will probably be useful for all engineers. I tried to understand what tests are, then/when and what to test. Here you can find examples of testing, modern tools and useful links.

When writing tests, I am guided by several principles. First principle, don't put tests in a black box. Set up tests as early as possible, and write them along with the code. Pay special attention to tests related to bugs. A bug is the result of manual testing, the cost of which can be incredibly high.
The second principle of testing is ensuring that the software is reliable, secure, and user-friendly. A narrow focus on test coverage can divert attention from these broader, more important objectives.

In each section, you'll find a description of each type of test, when to apply it, and an example with the tools I recommend when writing tests in 2024.

This text does not claim to be the truth in the first instance. It is primarily my experience, but I will be glad to hear any criticism or thoughts on this subject.

Understanding the necessity of testing
Unit testing
End-to-end testing
Accessibility testing
Integration testing
Testing tools you should try in 2024

Understanding the necessity of testing

Software testing is the process of checking the quality, functionality, and performance of a software product before launching. It involves both manual and automated methods to detect and fix bugs, guaranteeing that the software operates as intended. The primary advantages of software testing include:

Ensuring Code Quality and Functionality: Guarantees that each component and the application as a whole operates correctly, both in isolation and in combination with other components.
Early Detection of Bugs: Catches and fixes bugs early in the development cycle, saving time and resources.
Facilitating Refactoring and Code Enhancements: Allows for safe refactoring and introduction of new features, ensuring existing functionality is not broken.
Improving Code Maintainability and Documentation: Acts as documentation for the codebase, aiding in understanding and maintaining the code, especially over time or with multiple contributors.
Building Confidence and Trust: Increases the reliability and stability of the application, fostering trust among users, clients, and stakeholders.
Cost-Effectiveness: Writing tests is more economical than dealing with the repercussions of errors in the long run, leading to significant cost savings.
Enhanced Maintainability and Scalability: Ensures the codebase remains maintainable and scalable, particularly vital for long-term projects with numerous contributors.
Promoting High-Quality Code: Encourages adherence to SOLID principles and makes it challenging to write subpar code, directly benefiting code quality and maintenance.
Developer Satisfaction and Happiness: Fosters a sense of confidence and fearlessness in dealing with the code, enabling developers to clean and optimize code effectively.
Team Satisfaction and Happiness: Enhances the morale and satisfaction of the supporting team, contributing to a more positive and productive work environment.

That's a pretty serious list, isn't it? But I have noticed that tests are very much neglected, especially in young companies and startups. This is due to several factors.
The first factor is time and money. Developers and stakeholders think that they don't have time to write tests. I can't agree with that. Test writing should become a part of any engineer's daily work. Early bug detection through testing is a significant advantage, as it helps identify and address issues early in the development cycle, saving both time and resources. Beyond technical benefits, software testing is cost-effective in the long run, preventing the high costs associated with fixing post-launch errors. A lot of benefits, and if you start right now, with your component, it will cost you almost nothing.
Just remember, race for high test coverage, while seemingly a noble pursuit, can be a flawed approach for many reasons, but one of them is maintenance overhead. Please, do not write tests just to increase coverage percentages, neglecting the actual purpose of testing, which is to ensure the application works correctly and is free from defects.
The second factor, developers don't know how and when to write tests. This may be lack of experience or lack of motivation. But at the end, tests increase developer satisfaction and happiness. Writing tests should be easy and fun. Testing is crucial for facilitating safe code refactoring and the addition of new features, ensuring that existing functionalities are not compromised.

Testing plays a vital role in building confidence and trust among users and stakeholders, promoting high-quality coding practices, and enhancing both developer and team satisfaction, leading to a more positive and productive work environment.

Unit testing

Unit tests are very low level and close to the source of an application. They consist in testing individual methods and functions of the classes, components, or modules used by your software. Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server.

When

The ideal use of unit testing is your components and functions. Test components for state changes and pure functions for its return value. A good example: design system components and utility functions.

Example

For unit testing in 2024 I would strongly recommend using Vitest and Testing Library. Today, both tools have already become a standard in Front-end testing. Despite the fact that Jest is still the most popular testing framework, it is inferior to Vitest in terms of execution speed and interesting features such as Hot Module Reload (HMR).

import { expect, test } from 'vitest'
import { faker } from '@faker-js/faker'
import { render, screen } from '@testing-library/react'
import NavigationBar from 'components/NavigationBar'

test('NavigationBar', () => {
    it('renders items correctly', async () => {
        let items = [  
            { slug: faker.lorem.slug(), url: faker.internet.url() },  
            { slug: faker.lorem.slug(), url: faker.internet.url() },  
        ]

        const { getByText } = render(<NavigationBar items={items} />)

        await fireEvent.click(getByText(items[0].slug))

        expect(getByRole("heading", { level: 1 })).toBe(items[0].slug)      
    })
})

End-to-end testing

End-to-end testing replicates a user behavior with the software in a complete application environment. It verifies that various user flows work as expected and can be as simple as loading a web page or logging in or much more complex scenarios verifying email notifications, online payments, etc...

End-to-end tests are very useful, but they're expensive to perform and can be hard to maintain when they're automated. It is recommended to have a few key end-to-end tests and rely more on lower level types of testing (unit and integration tests) to be able to quickly identify breaking changes.

When

E2E testing involves testing user flows in an environment that simulates real user scenarios, like the browser. On the frontend, the ideal place for testing is the user's login and registration process, payment scenario.

Example

Until recently, using cypress and testing-library in E2E testing was a common practice. Even though these tools remain the most popular combination, I recommend using playwright for the next projects, and there are several reasons for this. The first reason is the incredible speed, compared to Cypress. If you've worked with Cypress before, remember how long it took you to launch a shell with a browser. Playwright does it about 3 times faster. The second reason is configuration. Cypress can take days to configure and debug. Playwright is amazingly easy to use and informative when debugging, and the command interface will configure your CI/CD pipeline as a gift.

import { test, expect } from '@playwright/test'  
import { faker } from '@faker-js/faker'

test.describe('Game Page Tests', () => {  
  test('should show a dialog window on a first page load', async ({ page }) => {  
    await page.goto(process.env.host)

    const dialogWindow = await page  
      .getByRole('dialog')  
      .locator('section')  
      .filter({ hasText: 'Hello world!' })  

    await expect(dialogWindow).toBeVisible()  

    const initials = faker.lorem.word()
    await page.getByPlaceholder('Enter initials').fill(initials)  
    await page.getByLabel('Save initials').click()  

    const heading = await page.locator('.main-header').getByText(initials)  
    await expect(heading).toBeVisible()  
  })})

Accessibility testing

Accessibility testing is a process used to ensure that an application can be used by everyone, regardless of their ability or disability. This type of testing is important for making sure that all users can access and use the features and functionality of an application.

There are many different ways to test for accessibility, but some common methods include using screen readers or other assistive technologies, testing with users who have different disabilities, and checking for compliance with accessibility standards.

When

Accessibility testing remains a crucial aspect of software development to ensure applications and websites are usable by all people, including those with disabilities. Accessibility testing is critical in sectors where digital inclusivity is crucial, including government, education, commerce, finance, healthcare, corporate, and public services. It ensures compliance with legal standards and enhances the overall user experience for a wider audience. Any project or task that interfaces with a diverse user base, especially those that provide essential services or information, should prioritize accessibility testing. It not only helps in complying with legal requirements but also ensures a wider reach and a better user experience for all.

Example

Every year, the number of tools for this kind of testing grows larger and larger. And that's good! Developers and companies increasingly realize the importance of accessibility of services and applications. The choice of a tool depends on the project and its inclusiveness. I recommend always using eslint-plugin-plugin-jsx-a11y because it's just a static evaluation to identify accessibility issues, so there's no need to install and run tests. For more in-depth testing, we would need a high-level web browser automation API and toolkit. I recommend playwright, for its speed and ease of configuration, and axe-core, a powerful library for accessibility testing. It can be integrated into various testing frameworks and CI/CD pipelines. There is an @axe-core/playwright API for playwright that needs no configuration and is easy to use.

import { test, expect } from '@playwright/test'  

test.describe('homepage', () => {  
  test('should not have any automatically detectable accessibility issues', async ({  
    page,  
  }) => {  
    await page.goto(process.env.host)

    const accessibilityScanResults = await new AxeBuilder({ page }).analyze()

    expect(accessibilityScanResults.violations).toEqual([])
  })  
})

Visual Regression Testing

Visual regression testing is a type of front-end testing that compares screenshots of the interface to see if they match the expected version. This test focuses on the interface of the application and crucial in front-end development for ensuring visual consistency, improving the quality of the user interface, saving time and resources in UI review processes, and fitting well into modern development practices and workflows. This is particularly useful in teams where developers and designers collaborate closely.

When

Anything that is visual and difficult to test in other ways: visual language, layout and company brand materials, icons, histograms, responsive Design Testing.

Example

For tests you can use any tool you like, like Playwright.Almost all e2e tools either include this feature or work in conjunction with them as dependencies. For 2024, I recommend setting up Storybook and Chromatic. This is the perfect tandem for documenting, organizing, and testing isolated components. Visual tester is automatic, you don't need to manually write tests. Just document components with Storybook and Chromatic automatically turns stories into tests. So the more coverage of your UI with stories, the more time you'll save your team with our automation. Chromatic serves as a single hub that allows you to test, approve PRs, and share feedback. During the pull request, Chromatic automatically runs in CI when you push code. There are two key workflows: UI Tests and UI Review.

Integration testing

Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.

When

In web applications, integration testing aims to detect issues in the interaction between various components, such as the front-end, back-end, database, and external APIs. This is crucial because even if individual components (units) work flawlessly on their own, they might fail when integrated. For instance, it might involve testing how the client-side interface interacts with the server-side application or how the application communicates with the database.

Example

If something goes wrong, you simply don't release until the bugs are fixed. If your front-end and back-end are developed separately, you may encounter difficulties here. Tests should be run independently so that they do not block each other. The error response rate and recovery rate should remain fast. In this case, if we imagine that back-end writes tests on its side and front-end on its side, the main task of integration tests is communication between interface and server API. In 2023, I tried Pact and I found its idea very interesting. Pact is a code-first tool for testing HTTP and message integrations using contract tests. Contract tests assert that inter-application messages conform to a shared understanding that is documented in a contract. Without contract testing, the only way to ensure that applications will work correctly together is by using expensive and brittle integration tests. Contract testing is a technique for testing an integration point by checking each application in isolation to ensure the messages it sends or receives conform to a shared understanding that is documented in a "contract".

How testing with Pact looks like

In general, "contract" testing is creating a pact between a consumer (for example, a client that wants to receive some data) and a provider (for example, an API on a server that provides the data the client needs).

Client (Consumer) test

const provider = new Pact({
    consumer: 'BookClient',
    provider: 'BookService',
    port: 3000,
    log: path.resolve(process.cwd(), 'logs', 'book_service_pact.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
    logLevel: 'INFO',
});

describe('Books Service', () => {
    describe('When a request to list all books is made', () => {
        beforeAll(() =>
            provider.setup().then(() => {
                provider.addInteraction({
                    uponReceiving: 'a request to list all books',
                    withRequest: {
                        method: 'GET',
                        path: '/books',
                    },
                    willRespondWith: {
                        status: 200,
                        body: eachLike({
                            id: 1,
                            title: like('Book Title 1'),
                            author: like('Author Name'),
                            year: like(2015),
                        }, {
                            min: 3
                        }),
                    },
                });
            })
        );
        test('should return the correct data', async () => {
            const response = await fetchBooks(URL, PORT);
            expect(response[0].title).toBe('Book Title 1');
            expect(response[0].author).toBe('Author Name');
            expect(response[0].year).toBe(2015);
        });
        afterEach(() => provider.verify());
        afterAll(() => provider.finalize());
    });
});

Server (Provider) Test

describe('Pact Verification', () => {
    test('should validate the expectations of our consumer', () => {
        const opts = {
            provider: 'Provider',
            providerBaseUrl: 'http://localhost:3000',
            pactBrokerUrl: process.env.PACT_BROKER_URL,
            pactBrokerToken: process.env.PACT_BROKER_TOKEN,
            publishVerificationResult: true,
            providerVersion: '1.0.0',
            logLevel: 'INFO',
        };
        return new Verifier(opts).verifyProvider();
    });
});

Sharing the contracts with the provider team

After successfully creating and executing your consumer tests, which generated a pact file as an output, the next step is to distribute this contract to the team in charge of the Order API. This is essential for them to verify that their API fulfills all the requirements outlined in the pact. While there are various methods to share pacts, it is advisable to use a Pact Broker. The Pact Broker is the preferred option because it facilitates efficient and automated workflows.

Testing tools you should try in 2024

Faker

Faker.js is a library for generate massive amounts of fake (but realistic) data for testing and development. Try not to use static data in your tests. Instead, use generated, close to real data. This will bring your tests closer to real-life scenarios, which means you will get realistic, close-to-user results.

MSW

MSW is is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments. It allow to Intercept both REST and GraphQL API and use it as real API. No configurations, adapters, or plugins. Reuse the same mocks across environments and tools, be it an integration test with Vitest, an automated browser test with Playwright, a demo showcase in Storybook, or a React Native app. Or all of them at once.

UVU

UVU is an extremely fast and lightweight test runner for Node.js and the browser. I recommend it especially for Solid.js developers and node.js unit testing.

Happy DOM

Happy DOM is a JavaScript implementation of a web browser without its graphical user interface. It includes many web standards from WHATWG DOM and HTML. I use it in my tests instead of Jest DOM. Can be used without configuration, just specify // @vitest-environment happy-dom on the top of test file.

Conclusion

Software testing is a complicated and big topic. Hopefully this guide will help you choose correct testing tools and understandings of that and how to test your front-end. I'm also hoping you will motivate and have a fun with tests.

If you are left confused or wanting more resources about a topic I touched on, don't hesitate to leave a comment below. Also, feel free to share your testing tools and ideas in comments.

Golden document root size

Ivan Malov — Mon, 28 Dec 2020 20:37:27 +0000

Now it is difficult to find information on why all modern browsers use 16px as the default. Almost all famous fonts on the web are created for this size. This can also change depending on if the font uses serifs or is a fixed-width font, but most of all fonts look good on 16px size. On almost all sites, this is the default number. But why 16?

I didn’t find the history, but in fact, it is a very convenient number and it is not difficult to guess why exactly 16. Computer monitors consist of pixels of the image. The pixel is always at least 1. So the minimum value for scaling is best to take the minimum natural number — 2. The Internet is primarily texted content and readability is a top priority. 16 — is the size at which the font remains natural when scaled, does not deform, and at the same time remains readable for most of the popular line length — 800px.

IBM uses a 2x grid system, the base unit of which is the 8-pixel square mini-unit. The basic concept of which is to divide or multiply by two, forming a visual rhythm.

As for usability expert, Oliver Reichenstein recommends using 16px font-size for most situations. He wrote 5 simple rules for good web typography, and the first rule reads:

Initially it is more difficult to create a visually pleasing layout with a bigger font size, but that challenge will help you design a simpler, clearer site. Anyone can cram a page with information, but making it simple and easy-to-use is hard. At first, you will be shocked by how big the default text is. But after a day you won’t want to see anything smaller, and you quickly realize why all browsers use the default text size.

REM is everywhere

“rem” is a very convenient unit. It allows you to scale the entire interface relative to the root size of the document. There are many properties in hand, including font-size, font-weight, line-height, padding, and, if relevant, borders, which can be scaled very quickly to meet your requirements while maintaining the proportions of the content. A very good article on the topic of "Sizes in Design Systems" from Nathan Curtis.

What happens if you don’t follow this rule?

If you are not going to make a scalable library, and transfer all your experience to other projects, then probably nothing terrible. But sooner or later, everyone does, and keeping the golden browser standard helps make it easier for us to scale, and here’s why:

You don’t need to change most of the font attributes and dimensions like line-height and font-size.
You don’t need to comb through all places there you use REM on pages.

Seriously, much more easily change root size depends on media queries instead change all parameters every time you scale your library to other projects. One of the common problem that design system solve is cross-platform consistency: if you always follow the default 16px rule for all browsers then your interfaces would look good everywhere when integrating your design system.

That's why changing the root size is a bad idea — the complexity of scaling out.

If you have a 16px design system and a different size for other sites. You should configure all dimensions in tokens to scale your design system or you should reset root size to default and change all dimensions to scale the site.
If you have a 16px design system and the same size for other sites. You just keep all dimensions.
If you have a design system with a different size from the default root size. Well, I hope you know what you doing =)

But I don’t like how my font looks with 16px. I want to set my font-size as 17! May I do it? And my answer — yes, just use media queries.

Conclusion

Keep default document size and change it only with media queries. One of the main reasons then we need to change root size is a line length (text column width, also called “the measure”) more than 800px and reading distance. Relevant to this day’s article "Responsive Typography: The Basics" from Oliver Reichenstein will help you figure out what font to choose for your screens.

I prefer to use percentages for document size. It keeps root size by default but helps scale your interfaces without having to take a maths degree.

:root {
  --font-base: 100%;
}
html {
 font-size: calc(var(--font-base));
}
@media (min-width: 66rem) {
  html {
    font-size: calc(var(--font-base) + 25%);
  }
}

Thank you for reading. Do you use document root size as default? Have you had any problems with the document root font size? Feel free to give me feedback, ask a question, or just say HI!

To keep up with everything I’m doing, follow me on Twitter.

This article was originally posted on https://imalov.dev/

Another way to create themes

Ivan Malov — Sat, 13 Jun 2020 09:28:30 +0000

Recently, I have been developing design systems. It's no secret that creating themes is not possible without the specified variables. Variables in styles has long been used by libraries like Bootsrtap or Foundation. Design systems has gone much further and uses tokens to encode values. Tokens are used in components, colors, and typographic documentation. Without tokens, scaling any system becomes a very difficult task. Right written token system allows all team members to speak the same language also.

Getting started using tokens is not as difficult as it seems. You can start encoding with the site color palette. There are many resources that allow you to extract all colors from any site to analyze them, sort them, and encode palette into tokens. In this article, I will tell you how to write your first tokens from scratch, generate themes from them, automate the process and further expand them. I want to share my experience of writing themes and generating them, based on my experience that I gained when creating design systems.

For a quick start we will use @vue/cli, but you can choose another framework or pure javascript if you want. For build tokens we take Style Dictionary — great build system from Amazon, which help you to define styles once, in a way for any platform or language to consume like, IOS, Android, Web, e.t.c.

But let's first figure out what a token is? A token is a named entity that stores a visual design attribute. They are used instead of hard-coded values (such as HEX values for color or pixel values for interval) to support a scalable and consistent visual system for user interface. Nathan Curtis wrote a great article about tokens.

We will describe tokens in JSON file and generate SCSS maps from them. When SCSS variables in turn will be generated in CSS variables for each theme. You may ask what the point of this? Why not use CSS variables immediately? Well we will still use CSS variables in our CSS, but the preprocessor has great functions and language constructs, it helps keep clean our source styles and allow to generate CSS code using loops for example.

Tokens, tokens, tokens...

I'll show you result and code what we should get. You should already have @vue/cli installed and Node.js. If not, then it's time to do it. I hope to create a new project is also not problem for you, just use @vue/cli commands to do that. Then we will install the necessary dependencies and launch our project:

npm i sass-loader sass style-dictionary -D && npm run serve

Great! Do not change this template, let's deal with tokens. Since this article is an example, we will not to go deep into tokens for sizes and properties in details. Instead that, we will specify color tokens for links and typography. The structure of our token folder will be as follows:

src/lib folder for our token library;
src/lib/tokens the tokens folder. There will be /themes and /properties folders for themes and properties tokens.;
src/lib/dist generated files. Add this folder to .gitignore file;

Create the folders:

mkdir src/lib/tokens/themes && mkdir src/lib/tokens/properties

And create our first default theme in the /tokens/themes folder, containing 4 JSON files:

// background.json — background tokens
{
  "color": {
    "background": {
      "page": {
        "primary": {
          "value": "#f9f8f6"
        },
        "secondary": {
          "value": "#FFFFFF"
        }
      },
      "container": {
        "primary": {
          "value": "#FFFFFF"
        },
        "secondary": {
          "value": "#f9f8f6"
        }
      }
    }
  }
}

// interactive.json — tokens for interactive elements like buttons or navigations for example.
{
  "color": {
    "interactive": {
      "default": {
        "value": "#0c7aff"
      },
      "hover": {
        "value": "#005dcb"
      },
      "focus": {
        "value": "#00479b"
      },
      "active": {
        "value": "#00479b"
      },
      "above": {
        "value": "#ffffff"
      }
    }
  }
}

// link.json — Tokens for links
{
  "color": {
    "link": {
      "default": {
        "value": "#0c7aff"
      },
      "hover": {
        "value": "#063e7e"
      },
      "visited": {
        "value": "#5b08a3"
      }
    }
  }
}

// text.json — Text color tokens
{
  "color": {
    "text": {
      "primary": {
        "value": "#000000"
      },
      "inverse": {
        "value": "#ffffff"
      }
    }
  }
}

You should pay attention here. Style Dictionary does a deep merge of all the property JSON files to key: value token pairs. This allows you to split up the property JSON files however you want. For example, a text.json file will be generated into two tokens:

$color-text-primary: #000000;
$color-text-inverse: #ffffff;

Token names are very important and it is important to follow three basic rules when naming them:

The beginning of the name should describe the variant. Font for a font, color for a color for example;
Next, we describe the context to which the token is applied. The context can be inherited. Background for the color variant for example;
The last is a parameter. You can use a geometric progression for dimensions (2, 4, 8, 16, 32, 64) or sizes in t-shirts (XS, S, M, L, XL, XXL). For states you can use the usual values like hover, focus, or the characteristics of primary, secondary;

And the same for property tokens and sizes in the /tokens/properties folder:

// border.json tokens borders
{
  "border": {
    "element": {
      "01": {
        "value": "1px solid"
      },
      "02": {
        "value": "2px solid"
      }
    },
    "radius": {
      "s": {
        "value": "6px"
      },
      "m": {
        "value": "10px"
      },
      "l": {
        "value": "14px"
      }
    }
  }
}
// spacing.json token for indents at page layout and components
{
  "spacing": {
    "layout": {
      "01": {
        "value": "1rem"
      },
      "02": {
        "value": "1.5rem"
      },
      "03": {
        "value": "2rem"
      },
      "04": {
        "value": "3rem"
      },
      "05": {
        "value": "4rem"
      },
      "06": {
        "value": "6rem"
      },
      "07": {
        "value": "10rem"
      }
    },
    "content": {
      "01": {
        "value": "0.125rem"
      },
      "02": {
        "value": "0.25rem"
      },
      "03": {
        "value": "0.5rem"
      },
      "04": {
        "value": "0.75rem"
      },
      "05": {
        "value": "1rem"
      },
      "06": {
        "value": "1.5rem"
      },
      "07": {
        "value": "2rem"
      },
      "08": {
        "value": "2.5rem"
      }
    }
  }
}

Tokens are described. Time to turn them into SCSS variables. Let's create build.js file at the root of our library.

const { readdirSync, writeFileSync, existsSync, mkdirSync, rmdirSync } = require('fs');
const StyleDictionary = require('style-dictionary');

const baseDir = `${__dirname}/tokens`;
const distDir = `${__dirname}/dist`;

// Remove and create dist folder
if (existsSync(distDir)){
  rmdirSync(distDir, { recursive: true });
}

mkdirSync(distDir);

// Style dictionary format https://amzn.github.io/style-dictionary/#/api?id=registerformat
StyleDictionary.registerFormat({
  name: 'json/flat',
  formatter: (dictionary) => JSON.stringify(dictionary.allProperties, null, 2)
});

// Add a custom transformGroup to the Style Dictionary, which is a group of transforms.
// https://amzn.github.io/style-dictionary/#/api?id=registertransformgroup
StyleDictionary.registerTransformGroup({
  name: 'tokens-scss',
  transforms: ['name/cti/kebab', 'time/seconds', 'size/px', 'color/css']
});

// Get all theme names in tokens/themes folder
const themes = readdirSync(`${baseDir}/themes/`, { withFileTypes: true })
  .filter(dir => dir.isDirectory())
  .map(dir => dir.name);

// Save theme names in json file
writeFileSync(`${distDir}/themes.json`, JSON.stringify({
  themes: themes
}));

// Build properties
StyleDictionary.extend(getConfig()).buildPlatform('web/scss');
// Build themes
themes.map(function (theme) {
  StyleDictionary.extend(getConfig(theme)).buildPlatform('web/scss');
});

// https://amzn.github.io/style-dictionary/#/config
function getConfig(theme = false) {
  const source = theme ? `${baseDir}/themes/${theme}` : `${baseDir}/properties`;
  const buildPath = theme ? `${distDir}/${theme}/` : `${distDir}/`;
  return {
    source: [`${source}/**/*.json`],
    platforms: {
      'web/scss': {
        transformGroup: 'scss',
        buildPath: `${buildPath}`,
        files: [
          {
            destination: 'tokens-map.scss',
            format: 'scss/map-flat',
            options: {
              showFileHeader: false
            }
          }
        ]
      }
    }
  };
}

Ok, what's going on here:

Re-creating the dist folder, if it exists;
Configuring the Style-Dictionary;
For each theme, we create individual set of tokens. For properties tokens we create own set also;
Saving list of themes in the theme.json file;

Style Dictionary can do a lot more, I advise you to play with its settings. More information about the Style-Dictionary API can be found on the official website. Adding the launch to the script block package.json, as a result of running which we should have a dist folder with results of our build:

...
"scripts": {
    ...
    "tokens": "node src/lib/build.js"
}
...

Themes, themes, themes...

OK, the tokens are described and generated, now they must be assigned. But we don't have CSS variables, only SCSS arrays. To generate CSS tokens, we will use SCSS each loops, then transform each variable into CSS and apply it to the root DOM element. Create the themes.scss file in the root of our library:

:root {
  @import './dist/tokens-map';
  @each $name, $value in $tokens {
    --#{$name}: #{$value};
  }
}

:root {
  @import './dist/default/tokens-map';
  @each $name, $value in $tokens {
    --#{$name}: #{$value};
  }
}

Let's create styles.scss in the root of our app and import themes into it.

@import './lib/themes.scss';

In turn, the created file should be imported src/main.js of our app:

import Vue from 'vue';
import App from './App.vue';
import './styles.scss';

Vue.config.productionTip = false;

new Vue({
  render: h => h(App),
}).$mount('#app');

Let's launch our npm run serve app. In chrome developers tools, you should see two sets of variables assigned to the root pseudo-class:

Tokens are in DOM. Now it remains to assign them to the elements of our app. Delete styles associated with the color in the App.vue and HelloWorld.vue files. The colors should be reset to default states in the browser. In the styles.scss file, assign tokens to the elements.

@import './lib/themes.scss';

body {
  margin: 0;
  padding: 0;
  height: 100%;
  width: 100%;
  font-size: 20px;
  line-height: 1.6;
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  transition-property: background-color;
  transition-timing-function: ease-out;
  transition-duration: 0.3s;
  background-color: var(--color-background-page-primary);
  color: var(--color-text-primary);
}

a {
  color: var(--color-link-default);

  &:visited {
    color: var(--color-link-visited);
  }

  &:hover {
    color: var(--color-link-hover);
  }
}

button {
  cursor: pointer;
  outline: none;
  border-radius: var(--border-radius-m);
  padding: var(--spacing-content-03) var(--spacing-content-05);
  background-color: var(--color-interactive-default);
  border: var(--border-element-02) var(--color-interactive-default);
  color: var(--color-interactive-above);

  &:hover {
    background-color: var(--color-interactive-hover);
    border-color: var(--color-interactive-hover);
  }

  &:active {
    background-color: var(--color-interactive-active);
    border-color: var(--color-interactive-active);
  }

  &:focus {
    border-color: var(--color-interactive-focus);
  }
}

Great, we're almost there. Now we have only one theme and it is assigned to the root pseudo-class. This is the correct decision, variables should be assigned to this pseudo-class. But we need to switch our themes, and the element parameter tokens should be higher priority than the theme tokens. If :root represents the element and is identical to the selector html, the next highest priority element is body. This means that we should assign theme tokens to this body element. Let's modify our app by adding a trigger for switching themes.

<template>
  <div id="app" class="app">
    <button class="trigger" title="Theme color mode" @click="changeTheme">
      <span class="icon"></span>
    </button>
    <img alt="Vue logo" src="./assets/logo.png">
    <HelloWorld msg="Welcome to Your Vue.js App"/>
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld.vue'
import themes from './lib/dist/themes.json';

export default {
  name: 'App',
  components: {
    HelloWorld
  },
  data() {
    return {
      theme: 0
    }
  },
  watch: {
    theme(newName) {
      document.body.setAttribute('data-theme', themes.themes[newName]);
    }
  },
  mounted() {
    document.body.setAttribute('data-theme', themes.themes[this.theme]);
  },
  methods: {
    changeTheme() {
      this.theme = this.theme < (themes.themes.length - 1) ? ++this.theme : 0;
    }
  }
}
</script>

<style lang="scss">
.app {
  position: relative;
  padding: var(--spacing-layout-02) var(--spacing-layout-04);
}
.trigger {
  position: absolute;
  top: var(--spacing-layout-02);
  right: var(--spacing-layout-04);
  display: flex;
  background-color: var(--color-interactive-default);
  padding: var(--spacing-content-01) var(--spacing-content-01);
  border: var(--border-element-02) transparent;

  .icon {
    position: relative;
    display: inline-block;
    background: linear-gradient(-90deg, var(--color-background-page-primary) 50%, var(--color-interactive-default) 50%);
    border-radius: var(--border-radius-s);
    height: 20px;
    width: 20px;
  }

  &:hover {
    background-color: var(--color-interactive-hover);

    .icon {
      background: linear-gradient(-90deg, var(--color-background-page-primary) 50%, var(--color-interactive-hover) 50%);
    }
  }

  &:focus,
  &:active {
    background-color: var(--color-interactive-active);

    .icon {
      background: linear-gradient(-90deg, var(--color-background-page-primary) 50%, var(--color-interactive-active) 50%);
    }
  }
}
</style>

What's going on here? When our app is mounted, we add the default theme to the app. When click on trigger happens, next theme from the themes.json file adding to the body attribute. Everything is quite simple, let's add a new theme to check it. To do this, simply duplicate the lib/tokens/themes/default folder to a folder next to it and name it, for example, dark. Change the tokens in the theme to the desired ones and generate it using npm run tokens command. To make the themes apply, we modify our lib/themes.scss file by adding a new theme to it.

[data-theme='dark'] {
  @import './dist/dark/tokens-map';
  @each $name, $value in $tokens {
    --#{$name}: #{$value};
  }
}

Unfortunately, if you reload the page now, the theme value will be reset to the initial one. To fix this, we can use localstorage to store the selected theme. Let's fix our App.vue

watch: {
  theme(newName) {
    localStorage.theme = newName;
    document.body.setAttribute('data-theme', themes.themes[this.theme]);
  }
},
mounted() {
  if (localStorage.theme) {
    this.theme = localStorage.theme;
  }
  document.body.setAttribute('data-theme', themes.themes[this.theme]);
}

What we need! Thanks to localStorage, we can store the selected names of our themes in the user's browser and use it when the user returns to the app, even if they have closed the browser.

Last things, but not least

So our themes work and are saved in the user's browser. This way we can create as many themes as we want, limiting ourselves only to our imagination. There are a few inconvenient points. First, we need to modifying themes.scss file every time then we creating new theme. This is normal, but we developers are lazy people and it would be great to generate this file automatically. The second problem is running the generation script every time we changed the token. We could add watcher and leave this process in the background to focus on the design. Ok install dependencies:

npm i json-templater prettier -D

Let's add a function for generating a SCSS file with importing themes to our lib/build.js:

function createFiles(themes) {
    // Save theme names in json file
  writeFileSync(`${distDir}/themes.json`, JSON.stringify({
    themes: themes
  }));

  const themeImport = `[data-theme='{{theme}}'] {
      @import './{{theme}}/tokens-map';
      @each $name, $value in $tokens {
        --#{$name}: #{$value};
      }
    }`;

  const themesTemplate = [];
  themes.forEach(t => {
    themesTemplate.push(
      render(themeImport, {
        theme: t
      })
    );
  });

  const template = `
    :root {
      @import './tokens-map';
      @each $name, $value in $tokens {
        --#{$name}: #{$value};
      }
    }

    {{themes}}
  `;

  const content = render(template, {
    themes: themesTemplate.join(' ')
  });

  const prettierOptions = {
    parser: 'scss',
    singleQuote: true
  };
  // Save themes in scss file
  writeFileSync(path.join(distDir, `themes.scss`), prettier.format(content, prettierOptions));
}

Great! We don't need the lib/themes.scss file anymore, it will be generated automatically in the lib/dist folder, so we just need to replace importing themes in the /src/styles.scss file

@import './lib/dist/themes.scss';

We need to add watcher for token, because it is very dull generate tokens manually every time when we change them. A quick cross platform command line utility for viewing changes to the file system chokidar CLI will help us do this:

npm i chokidar-cli -D

Add watch command to our scripts block in package.json. We will also change the build and serve commands by adding token generation command before it. The final scripts block should look like this:

...
"scripts": {
  "serve": "npm run tokens && vue-cli-service serve",
  "build": "npm run tokens && vue-cli-service build",
  "lint": "vue-cli-service lint",
  "tokens": "node src/lib/build.js",
  "watch": "npm run tokens && chokidar \"src/lib/tokens/**/*.json\" -c \"npm run tokens\""
}
...

Congratulations! We have created a small library with token generation and themes, and may have started something bigger. Nothing prevents us from expanding the set of tokens for components and themes. The source code can be found on the github page. The result can be viewed here.

Thank you for reading. I hope you learned something new or my approach was useful to you. Whether you are writing a large application, a design system, or a personal blog, the correct use of tokens will allow you to create scalable products regardless of their purpose. You can also see the implementation of this approach on my site. This is my first article on English. Feel free to give me feedback, ask a question or just say HI!

To keep up with everything I’m doing, follow me on Twitter.

This article was originally posted on https://imalov.dev/

Forem: Ivan Malov

Front-end testing in 2024

Who is this guide for?

Table Of Contents

Understanding the necessity of testing

Unit testing

When

Example

End-to-end testing

When

Example

Accessibility testing

When

Example

Visual Regression Testing

When

Example

Integration testing

When

Example

How testing with Pact looks like

Client (Consumer) test

Server (Provider) Test

Sharing the contracts with the provider team

Testing tools you should try in 2024

Faker

MSW

UVU

Happy DOM

Conclusion

Golden document root size

REM is everywhere

What happens if you don’t follow this rule?

Conclusion

Another way to create themes

Tokens, tokens, tokens...

Themes, themes, themes...

Last things, but not least