Coder Legion - Recent posts tagged unit-testing

No More Fake DOM: Testing Library Unit Tests in the Real Browser

Mon, 31 Aug 2026 07:54:58 +0000

Every Testing Library test you have written runs against a simulated DOM. You know this. You accepted it years ago, along with the small pile of things that come with it: no real layout, nothing ever drawn on a screen, jsdom throwing on APIs it does not implement, and the quiet suspicion that a passing test and a working component are not quite the same claim.

I co-maintain twd-js, which runs tests inside your actual dev server. It was built for flow testing: visit a route, click through the app, assert on what the user sees. Component testing was the thing it did not do, and I said so in print when I compared it to Vitest Browser Mode.

Then I tried calling render() inside a TWD test, mostly to see what would break.

import { render, screen, cleanup } from "@testing-library/react";
import { describe, it, afterEach } from "twd-js/runner";
import { AppProvider } from "@/context/AppContext";
import { twd } from "twd-js";
import { Add } from "../Add";
import { componentHost, restorePage } from "@/twd-tests/support/componentHost";

describe("Add Component", () => {
  afterEach(() => {
    cleanup();
    restorePage();
  });

  it("renders the Add component", () => {
    // componentHost() is a blank div on an empty page. More on it below.
    render(<AppProvider><Add /></AppProvider>, { container: componentHost() });

    twd.should(screen.getByText("Add Item"), "be.visible");
  });
});

Nothing broke. The component mounts into the page, the sidebar shows it running, and the assertion checks an element that exists in a real browser. Same Testing Library API, no fake DOM under it.

That AppProvider is the real one, not a test double. Add uses a hook that reads from context and posts to an API, and in a real browser both of those work, so there is nothing to stand in for. That turns out to matter more than the missing jsdom.

Why this works at all

Testing Library was never tied to jsdom. @testing-library/react renders a component into a DOM node and @testing-library/dom queries it. jsdom is just the DOM most people hand it. Give it a real one and the same code runs, except now the component is actually on a screen, with a real size, a real position, and your CSS applied to it.

TWD already runs inside your app in the browser, so the real DOM is right there. render() uses it.

The setup

One helper, and no changes to your app.

render() appends its container to document.body, so the component lands after the app, a full viewport below the layout. The app is also still on the page, so screen matches its elements as well as the ones your test just rendered. Both of those are the same problem: the app is in the way.

const HOST_ID = "twd-component-host";
const APP_ROOT_ID = "root";

let appRoot: HTMLElement | null = null;
let placeholder: Comment | null = null;

export function componentHost(): HTMLElement {
  detachApp();

  let host = document.getElementById(HOST_ID);
  if (!host) {
    host = document.createElement("div");
    host.id = HOST_ID;
  }
  if (!host.isConnected) {
    document.body.prepend(host);
  }

  host.innerHTML = "";
  return host;
}

export function restorePage(): void {
  document.getElementById(HOST_ID)?.remove();
  attachApp();
}

function detachApp(): void {
  if (placeholder) return;

  const root = document.getElementById(APP_ROOT_ID);
  if (!root) return;

  appRoot = root;
  placeholder = document.createComment(" app detached by twd component test ");
  root.replaceWith(placeholder);
}

function attachApp(): void {
  if (!placeholder || !appRoot) return;

  placeholder.replaceWith(appRoot);
  placeholder = null;
  appRoot = null;
}

Detaching the app root is not the same as emptying it. root.innerHTML = "" pulls the DOM out from under React while it still holds references to those nodes, and the app does not come back. Moving the node out and putting it back leaves the references intact, so restorePage() returns a live app.

prepend rather than append puts the component at the top of the page instead of below where the app used to be, so you can watch it run without scrolling.

The payoff is that screen behaves exactly like it does in jsdom. The only thing in the document is what your test rendered, which also covers anything the component renders through a portal, since that lands on document.body rather than inside the container.

One detail worth keeping: cleanup() and restorePage() belong in afterEach, not beforeEach. In jsdom the environment is torn down for you between files. In a real browser it is not, so renders stack up, and your flow tests need the app back before they run.

That is the whole setup. Your app does not change.

Two traps

screenDom will not find your component. TWD exposes screenDom, a wrapper around Testing Library queries scoped to your app root so it never matches the TWD sidebar. Testing Library's render() mounts outside that root. I probed it in a real app to be sure:

container.parentElement=<body>   inside #root=false
screen: found   screenDom: not found   screenDomGlobal: found

So use Testing Library's own screen, or TWD's screenDomGlobal, which queries the whole document. If you pick screenDomGlobal, keep queries specific, because it can also match elements inside the sidebar.

Everything else works normally. twd.should takes any element you hand it, whether a query found it in your app or in a component you just rendered.

Your test pattern probably says .ts. Component tests are .tsx. A pattern of /**/*.twd.test.ts skips them silently, with no error and no missing-file warning. They simply never appear in the sidebar:

twd({
  testFilePattern: "/**/*.twd.test.{ts,tsx}",
}),

If you also run Vitest in the same repo, exclude the browser tests from it. Vitest matches *.test.tsx by default, collects the TWD files, finds no describe it recognises, and fails the run with No test suite found in file:

test: {
  exclude: [...configDefaults.exclude, "**/*.twd.test.*"],
},

Both kinds of test, one run

This is the part I did not expect to matter as much as it does.

Component tests and flow tests are now the same kind of artifact. They are files in the same project, running in the same browser, in the same session, against the same instrumented bundle. So one command runs both:

$ npx twd-cli run
Running 14 test(s)...
Code coverage data written to .nyc_output/out.json

--- Run complete ---
  Passed: 14 | Failed: 0 | Skipped: 0
  Duration: 6.9s

Ten of those drive the whole app through routing, search, sorting and deletion. Four render a single dialog component in isolation. One coverage file comes out the other end, covering both.

That last part is usually where multi-runner setups get tedious. Component coverage in one report, end-to-end coverage in another, and a merge step that someone maintains. Here there is nothing to merge, because there was only ever one run.

Where each style fits

Rendering a component in isolation is the right move when the component is the subject: a form's validation states, a dialog that opens and closes, a table that sorts. You skip the navigation, you skip the fixtures, and the test says exactly what it is about.

Flow tests stay the right move for anything that crosses a boundary. Routing, data loading, a sequence of screens, state that survives a navigation. Rendering a component in isolation to test those means rebuilding the app around it, which is how component test files end up longer than the components.

The useful change is not that one replaced the other. It is that choosing between them is now a decision about scope, made per test, instead of a decision about which runner and which DOM you are committing to.

Try it

If you already have Testing Library tests, the fastest way to see this is to copy one, change the imports for describe and it to twd-js/runner, and hand render() the component host.

The example app from this post is on GitHub, with the same component tested in jsdom and in the browser side by side: kevinccbsg/frontend-challenge.

In the next post I look at what happened when I put those two versions next to each other. The jsdom test mocked the hook it was testing through, and once I stopped mocking, it turned out the mocks had been doing most of the work.

Architectural Elegance in Frontend Testing: Mastering the Builder Pattern and Test Directory Layouts

Thu, 11 Jun 2026 11:01:04 +0000

As frontend applications scale, their architectures mature. We regularly decouple our systems into clean state management layers, dedicated service modules, and isolated data repositories. However, while our production code advances, our testing suites frequently lag behind.

Two critical pain points eventually stall any scaling frontend test suite, whether built on Vue 3 or React:

The Static Mock Graveyard: Uncontrolled, brittle data mocking that breaks with every contract change.
Directory Sprawl: The endless debate of where to place test files, leading to a messy, unmaintainable codebase.

This article tackles both challenges by introducing the Test Data Builder Pattern and establishing a "Goldilocks" Hybrid Directory Layout designed for modern frontend environments.

1. The Problem: Why Traditional Mocking Scales Horribly

When testing components or services that rely on complex, contract-backed data types, developers usually fall into two traps:

Trap A: Inline Literal Hardcoding

Declaring massive object literals directly inside local describe or it blocks.

// tests/components/UserCard.spec.ts
it('renders user details', () => {
  const mockUser = { id: '1', name: 'John', email: '*Emails are not allowed*', role: 'user', status: 'active', permissions: [] /* ... 20 more fields */ };
  const wrapper = mount(UserCard, { props: { user: mockUser } });
});

Why it fails: If your backend schema changes and a new required field is introduced, you must manually hunt down and update thousands of lines of inline configurations across hundreds of test files.

Trap B: The "Centralized Mock Folder of Doom"

Creating a root-level static folder (e.g., /fixtures) packed with frozen JSON payloads like user.json, adminUser.json, and bannedAdminUser.json.

The Mutation Nightmare: If Test A imports a shared mock file and accidentally mutates a nested property inline, Test B (running concurrently) will suddenly fail with a mysterious state bug.
The Naming Explosion: Your folder quickly becomes a graveyard of user1.json, user2.json, and updatedUserFinal.json as tests demand slight data variations.

2. The Solution: The Test Data Builder Pattern

The Builder Pattern replaces rigid static files with a dynamic, fluid assembly line. Instead of maintaining discrete states across countless individual files, you configure a single class that maintains sensible, contract-satisfying defaults. It exposes chainable methods to alter just the pieces of data a specific test cares about.

By having configuration methods return this, your test code reads like an expressive sentence. Crucially, the termination method (.build()) returns a completely fresh, deeply unlinked clone of the payload, preventing cross-test state contamination.

The TypeScript Implementation

Imagine an entity generated from a backend database contract:

// src/types/user.ts
export interface UserProfile {
  id: string;
  username: string;
  email: string;
  role: 'admin' | 'subscriber' | 'guest';
  status: 'active' | 'suspended';
  permissions: string[];
}

Instead of copying raw objects, create a reusable UserProfileBuilder:

// tests/builders/UserProfileBuilder.ts
import type { UserProfile } from '@/types/user';

export class UserProfileBuilder {
  // 1. Sensible default values that satisfy the TS contract
  private data: UserProfile = {
    id: 'usr_default_101',
    username: 'test_user',
    email: '*Emails are not allowed*',
    role: 'subscriber',
    status: 'active',
    permissions: ['view:dashboard']
  };

  // 2. Chainable semantic modifiers
  asAdmin(): this {
    this.data.role = 'admin';
    this.data.permissions = ['view:dashboard', 'write:settings', 'delete:users'];
    return this; // Crucial for method chaining
  }

  asSuspended(): this {
    this.data.status = 'suspended';
    return this;
  }

  withCustomUsername(name: string): this {
    this.data.username = name;
    return this;
  }

  // 3. Finalization mechanism providing deep safety guarantees
  build(): UserProfile {
    // Return a deep clone to guarantee total test isolation
    return JSON.parse(JSON.stringify(this.data));
  }
}

3. Integrating Builders into Component Testing

Look at how expressive and readable your unit and integration specs become. You don't have to wade through lines of irrelevant object properties; the code tells you exactly what state is being evaluated.

In Vue 3 (Vitest + Vue Test Utils)

import { describe, it, expect } from 'vitest';
import { mount } from '@vue/test-utils';
import UserCard from '@/components/UserCard.vue';
import { UserProfileBuilder } from 'tests/builders/UserProfileBuilder';

describe('UserCard.vue', () => {
  it('hides delete action for standard subscribers', () => {
    const standardUser = new UserProfileBuilder().build(); // Fresh default user
    const wrapper = mount(UserCard, { props: { user: standardUser } });
    
    expect(wrapper.find('.btn-delete').exists()).toBe(false);
  });

  it('reveals danger actions for admin users', () => {
    const adminUser = new UserProfileBuilder().asAdmin().build(); // Instant admin state
    const wrapper = mount(UserCard, { props: { user: adminUser } });
    
    expect(wrapper.find('.btn-delete').exists()).toBe(true);
  });
});

In React (Vitest + React Testing Library)

import { describe, it, expect } from 'vitest';
import { render, screen } from '@testing-library/react';
import UserCard from '@/components/UserCard';
import { UserProfileBuilder } from 'tests/builders/UserProfileBuilder';

describe('UserCard Component', () => {
  it('hides delete action for standard subscribers', () => {
    const standardUser = new UserProfileBuilder().build();
    render(<UserCard user={standardUser} />);
    
    expect(screen.queryByRole('button', { name: /delete/i })).not.toBeInTheDocument();
  });

  it('reveals danger actions for admin users', () => {
    const adminUser = new UserProfileBuilder().asAdmin().withCustomUsername('Boss').build();
    render(<UserCard user={adminUser} />);
    
    expect(screen.getByText('Boss')).toBeInTheDocument();
    expect(screen.getByRole('button', { name: /delete/i })).toBeInTheDocument();
  });
});

The Maintenance Win: If your API shifts tomorrow and a user profile now requires a phoneNumber field, you add it once to the defaults inside UserProfileBuilder. None of your component tests will break.

4. Resolving the `tests` Directory Layout Conflict

Where do you actually put these test files? Frontend teams often flip-flop between two extreme layouts, both of which degrade at scale:

The Problem with Pure Collocation (__tests__ Bloat): Grouping tests inside isolated __tests__ folders under every single feature sub-layer introduces massive visual noise. It clutters your tree, making standard file navigation frustrating.
The Problem with Pure Centralization: Moving every single test outside the src/ directory into a massive top-level /tests folder detaches specs from code lifetimes. When you delete or refactor a component, finding and maintaining its parallel test target across the repository introduces heavy cognitive overhead.

The "Goldilocks" Hybrid Strategy

The ideal layout divides your testing ecosystem based on the operational scope of the test.

Collocate Implementation Tests (No __tests__ Folders): Put unit and integration tests (.spec.ts) directly next to their matching components or domain modules. If you move or delete a feature, its test naturally follows it. Ditch the nested __tests__ directory to minimize visual noise.
Centralize Test Infrastructure Machinery: Global assets like your custom Test Data Builders, Mock Service Worker (MSW) interceptors, and framework setup scripts are shared resources. They belong in a centralized root-level /tests chamber.
Isolate End-to-End Specs: Black-box test frameworks (Playwright, Cypress) treat your application as an independent environment. They live completely outside of src/.

The Production Blueprint File Tree

my-application/
├── e2e/                     # Centralized End-to-End suite
│   └── auth-flow.spec.ts
├── src/
│   ├── components/          # UI Components with collocated tests
│   │   ├── CustomButton.vue
│   │   ├── CustomButton.spec.ts
│   │   ├── UserProfileCard.vue
│   │   └── UserProfileCard.spec.ts
│   ├── domains/             # Domain-driven backend abstractions
│   │   └── user/
│   │       ├── UserRepository.ts
│   │       ├── UserRepository.spec.ts  # Clean, close proximity
│   │       └── UserService.ts
├── tests/                   # Shared Test Infrastructure Hub
│   ├── vitest.setup.ts      # Framework bootstrap configuration
│   ├── builders/            # The Central Builder Room
│   │   ├── UserProfileBuilder.ts
│   │   └── ProductPayloadBuilder.ts
│   └── msw/                 # Global Network Mock Handlers
│       ├── browser.ts
│       └── handlers.ts
└── vitest.config.ts

Summary: Designing for the Future

By organizing your testing framework with this approach, you enforce two strict architectural principles:

Decouple Data Arrangement from Assertions: Leave your component tests to focus purely on mounting, user interaction, and output evaluation. Delegate the complex assembly of mock states to structured Builders.
Match Proximity to File Lifetime: If a test verifies a singular implementation file (a specific component, service, or composable hook), keep them side-by-side. If a file exists purely to support other tests across your application (like global builders), lift it to the centralized infrastructure hub.

Adopting these practices shifts your frontend testing environment from a fragile maintenance bottleneck into a scalable, developer-friendly validation system.

Exploring Testing Strategies for Node.js Projects

Thu, 26 Feb 2026 18:42:27 +0000

Testing is often overlooked in rapid development cycles, but it's crucial for delivering robust applications. In Node.js, effective testing can be achieved through various strategies:

Unit Testing with Mocha and Chai: Mocha provides a flexible testing framework, while Chai offers an expressive assertion library. For example, you can test a function like so:
```
const assert = require('chai').assert;
const app = require('../app');
   
describe('App', function() {
  it('should return hello world', function() {
    assert.equal(app(), 'hello world');
  });
});
```
Running your tests with Mocha ensures early bug detection.

Integration Testing with Supertest: Supertest can help test your RESTful APIs effectively. It allows you to simulate HTTP requests and validate responses. For instance:

const request = require('supertest');
const app = require('../app');
   
describe('GET /api/users', function() {
  it('responds with json', function(done) {
    request(app)
      .get('/api/users')
      .expect('Content-Type', /json/)  
      .expect(200, done);
  });
});

End-to-End Testing with Cypress: For comprehensive application testing, Cypress allows you to write end-to-end tests in a user-centric way. You can simulate real user interactions and validate features.

Example:

describe('My First Test', function() {
  it('Visits the Kitchen Sink', function() {
    cy.visit('https://example.cypress.io');
    cy.contains('type').click();
    cy.url().should('include', '/commands/actions');
  });
});

Continuous Integration with GitHub Actions: Implementing CI/CD pipelines ensures that your tests run automatically upon code commits. You can define a .github/workflows/node.js.yml that runs tests on various Node.js versions.
Code Coverage with Istanbul: Ensure your tests cover critical parts of your codebase by using Istanbul. It helps visualize untested parts and enables you to focus your testing efforts effectively.

In conclusion, by embracing these testing strategies, you not only improve your application's quality but also enhance team collaboration and project sustainability. Start integrating these methods into your Node.js projects today!

The Hidden Power of Your Test Setup and Mocks

Wed, 27 Aug 2025 11:55:39 +0000

Have you ever looked at a test file and seen the same setup code repeated over and over? Maybe you're mocking the same API service, or setting up a global localStorage mock in dozens of different files. This isn't just a nuisance; it's a huge problem. This leads to duplication and tight coupling, making your tests difficult to maintain.

We need a way to decouple our tests from our dependencies.

Centralizing with `vitest.setup.ts`

The vitest.setup.ts or jest.setup.ts file is a central place for code that should run before every test file. Its main advantage is that it allows you to configure global test settings and, most importantly, set up global mocks.

Imagine you have an API service for user authentication that's used across your application. Instead of mocking it in every test file, you can do it once in your setup file.

Here's a simple vitest.setup.ts example:

// vitest.setup.ts

import { vi } from "vitest";
import * as authService from "@/services/authService";

// We export the mocked functions so we can access and override them
export const isUserLoggedIn = vi.spyOn(authService, "isLoggedIn").mockReturnValue(true);
export const getCurrentLoggedInUser = vi
  .spyOn(authService, "getCurrentUser")
  .mockReturnValue({ id: 1, name: "Test User" });

Now, every single test you run will automatically use this mock for authService. You no longer need to write vi.mock() at the top of every file. This saves time, reduces duplication, and makes your tests much cleaner.

The primary benefit is maintainability. If you need to update the authService mock, you only have to change it in one place.

Flexibility: Overriding Mocks in Specific Tests

This is where the real power comes in. While you have a global default mock, sometimes you need a specific test to behave differently. By exporting the mocked functions from your setup file, you can easily override their return values for a particular test case.

Let's say you have a component that should show a different message if the user is not logged in. You can write a test for this specific scenario like this:

// SomeComponent.test.ts

import { mount } from "@vue/test-utils";
import SomeComponent from "@/components/SomeComponent.vue";
import { isUserLoggedIn } from "../../vitest.setup.ts"; // Import the mocked function

describe("SomeComponent", () => {
  it("should show a login message if the user is not logged in", async () => {
    // Override the globally mocked function for this specific test
    isUserLoggedIn.mockReturnValueOnce(false);

    const wrapper = mount(SomeComponent);
    expect(wrapper.text()).toContain("Please log in to continue.");
  });

  // Other tests will still use the default mock of `isUserLoggedIn` returning true.
});

This approach combines the best of both worlds: a global default mock for most tests, but the flexibility to customize the mock's behavior for tests that require a different scenario. This is a crucial aspect of writing robust and comprehensive tests.

Advanced Mocking: Partial Mocks and Hoisting

Sometimes you don't want to mock an entire module; you just want to replace one or two functions while keeping the rest of the original implementation. This is where more advanced mocking techniques come into play.

Mocking with `vi.hoisted`

Normally, you can't access variables from your test file inside a vi.mock factory. vi.hoisted solves this by "hoisting" the mock definition to the top of the file, allowing you to create dynamic mocks. This is useful when your mock's behavior depends on a variable you define in your test.

You can also use vi.hoisted to create a reusable mock function that can be used inside multiple vi.mock calls, making your mock logic cleaner and more consistent.

// SomeComponent.test.ts

import { vi } from "vitest";

const mockedGetPosts = vi.hoisted(() => {
  return vi.fn(() =>
    Promise.resolve([
      { id: 1, title: "Mock Post 1" },
      { id: 2, title: "Mock Post 2" },
    ]),
  );
});

vi.mock("@/api", () => ({
  getPosts: mockedGetPosts, // Reusing the hoisted mock function
}));

describe("SomeComponent", () => {
  it("should fetch and display posts on mount", async () => {
    // The `getPosts` function is already the mocked version
    const wrapper = shallowMount(SomeComponent);
    await wrapper.vm.$nextTick();
    expect(mockedGetPosts).toHaveBeenCalled();
  });
});

This is a more complex but very powerful way to create flexible mocks.

Partial Mocks with `vi.importActual`

For more fine-grained control, you can use vi.importActual (or vi.importOriginal for CommonJS modules) inside a mock factory. This function gives you access to the real, un-mocked module, allowing you to only mock the parts you need.

Let's say you only want to mock the isLoggedIn function but keep the original getCurrentUser function.

// authService.test.ts

import { vi } from "vitest";

vi.mock("@/services/authService", async (importActual) => {
  const actualAuth = await importActual<typeof import("@/services/authService")>();
  return {
    ...actualAuth, // Use all original exports
    isLoggedIn: vi.fn(() => true), // But override this one
  };
});

This ensures that your test only overrides the specific behavior it needs to, further reducing the coupling between your test and the implementation details of the module.

The Magic of the `mocks` Directory

While vitest.setup.ts is great for global mocks, the __mocks__ directory is the perfect solution for automatic mocking of modules.

When you place a file with the same name as a module inside a __mocks__ directory, Vitest (and Jest) will automatically use that file as the mock whenever the original module is imported. You can even use vi.importActual within this mock file to create partial mocks automatically.

The __mocks__ directory provides loose coupling between your tests and your implementation. Your test file has no idea that fetchPosts is being mocked; it simply imports it and uses it. This makes your tests more robust and less likely to break when you refactor your original code.

The Ultimate Payoff: Decoupled and Resilient Tests

The real power of these tools is that they allow you to create tests that only care about the behavior of your code, not its internal dependencies.

vitest.setup.ts is for global, application-wide mocks that apply to all your tests. You can also export these mocks for overriding.
__mocks__ is for automatic, module-level mocks that apply whenever a specific module is imported.
vi.hoisted and vi.importActual provide the necessary flexibility for creating advanced, partial mocks when simple mocking isn't enough.

By using these tools, you're not just making your tests shorter. You're building a testing strategy that's resilient to change. You can refactor your services, change your API endpoints, or switch data libraries, and your tests will remain intact, as long as the mocked behavior is consistent.

How I Started Writing Unit Tests for Vue Components

Sun, 30 Mar 2025 02:37:53 +0000

At some point, every frontend developer realizes that it would be great to somehow verify that their code is working as expected. For me, this moment came after a painful migration from Vue 2 to Vue 3, with tons of bugs and defects. It left me with yet another strand of gray hair, and I wasn’t the only one suffering.

My project and technology stack

The current project I’m working on is a classic CRM, full of forms upon forms, list rendering, modals, and constant data transformation. The technology stack includes Vue 3, Pinia, Vite, and ElementPlus, which allows for fast and flexible interface development.

Why unit tests?

After reading up on the theory behind pyramids and testing cups, I concluded that it’s easier to gradually add “unit” tests for new components and features, as well as cover any bugs with tests.

Just a quick note on the testing pyramid. This concept, introduced by Martin Fowler, helps organize tests in a project. It involves three levels of testing:

Unit Tests: the most basic level of testing, which checks individual modules or functions. Unit tests are fast, easy to set up
and ensure that components work correctly in isolation.
Integration Tests: test the interaction between multiple components or modules, like how components work together on a page.
They are more complex and slower, but provide an understanding of the
correctness of the integrations.
E2E tests (End-to-End Tests): test the entire application, simulating real user actions. E2E tests are slower and require
complex infrastructure but ensure that the app works as a whole.

The word "unit" is in quotes here because, when testing components in a framework, there’s a nuance: testing components isn’t always about isolating them completely.

Ideally, unit tests check isolated functions, (like the famous SUM () function), but in reality, we cannot entirely "mock" the framework. So, tests for Vue components are technically integration tests. However, for simplicity, the community continues to call them “unit tests” and I’ll stick with that terminology.

Testing options and my choice

Of course, there were other options. For example, I considered E2E testing with Playwright, which runs tests in real browsers simulating user actions. While Playwright is a powerful tool,I faced several infrastructure difficulties, which I’ll discuss later in the article.

Spoiler: the backend wasn't ready for this, and realistically, E2E tests should be written under the guidance of QA engineers - they are experts at breaking systems.

Ultimately, I decided to go with Vitest and Vue Test Utils as the main tools for testing. Vitest, as a test runner, was ideal, since Vite was already installed in the project, and Vue Test Utils provided all the necessary tools for mounting and modifying Vue components.

Why Vue Test Utils and not Testing Library? First, Vue Text Urils is recommended by the Vue community (Testing Library was a bit late in supporting Vue 3). Second, I follow "London School" of testing, where we mock everything around our component to keep tests as fair isolated as possible. In addition, the Testing Library is built on top of VTU, and I wanted fewer dependencies.

Installing and setting up

To get started, we need to install and configure Vitest and Vue test utils.

npm i -D vitest @vue/test-utils

Since our tests will run in a Node.js environment, we need DOM implementers. Vitest recommends either happy-dom or jsdom.

I chose jsdom because it’s more popular and faster, though happy-dom is an option as well as you can switch quickly.

npm i jsdom -D

Configuring the testing environment

Let's add the necessary configuration to vite.config.js.

defineConfig({
...
test: {
environment: 'jsdom',
deps: {
  inline: ['element-plus'], // optional field
},
},
})

Since Pinia is in the stack, we can either use a real store or a test store for testing. I opted for a test store, as it’s easier to mutate directly during tests.

npm i -D @pinia/testing

What and how to test?

Let's take a component with a button and a modal as an example.

Component diagram and description

Here’s the basic flow:

There is a button (which is enabled if the user has permission).
When clicked, it opens a form in a modal window (a separate
component).
When the form is filled and the "Add" button is clicked, a request is
sent to the server.
After a successful response, an event is emitted to indicate that the
document has been added.

Component code:

<template>
 <div>
   <button :disabled="!isAddDocumentAvailable" class="button button--primary" @click="addIncomingMail">Add incoming correspondence</button>
   <popup drawer :is-form-open="isFormOpen" @closed="closeForm">
     <add-incoming-mail-modal :lawsuit-id="lawsuitId" @closeForm="closeForm" @mail-added="onMailChanged" >
   </popup>
 </div>
</template>

<script setup >
import { ref } from 'vue';
import AddIncomingMailModal from '@/.../AddIncomingMailModal.vue';
const isFormOpen = ref(false);

const emits = defineEmits(['mail-added']);
defineProps({
 lawsuitId: {
   type: Number,
   required: true,
 },
});

function addIncomingMail() {
 isFormOpen.value = true;
}

function closeForm() {
 isFormOpen.value = false;
}
function onMailChanged() {
 emits('mail-added');
}
const isAddDocumentAvailable = computed(() => {
 return checkAvailabilityByClaim(...);
});
</script>

A bit of theory.

To start, we need to decide what should be tested. The general advice is to follow the user's behavior and avoid focusing on implementation details, which makes sense. Essentially, we’ll treat the component as a black box: changing (preparing) its input data and testing the output.

Note: if the component has a complex function with heavy calculations, it should ideally be extracted and tested separately as a traditional unit test.

Mocks and stubs play a key role in isolating tests. Mocks replace real dependencies, while stubs simplify interaction with external systems (API, for example). The main rule is not to mock everything: only mock what affects the functionality being tested. This reduces test dependence on the mock.

Input data includes properties, components, dependency injections, external stores, and slots. For a fair test, we should replace real components, stores, and DIs with stubs. This minimizes the risk of false positives.

Output: we should test the resulting HTMLcheck API calls (which should also be stubbed to avoid affecting the backend), and verify that events are emitted and handled correctly outside the component.

Let's move on to writing the test. First, we need to define what we are testing (as they say, "draw a circle").

describe('Adding incoming correspondence - AddIncomingMail', () => {

 it.todo('The "Add incoming correspondence" button is active if the user has rights', async () => {});

 it.todo('By clicking on the "Add incoming correspondence" button, a modal window for adding a new document opens', async () => {});

 it.todo('When adding incoming correspondence, we generate an event outside the component', async () => {});
});

Notice how these test descriptions serve as self-documenting code — in theory.

I prefer placing tests as close to the components as possible. This approach seems better suited for understanding how the component works.

In general, we draw another circle, add details, and - we have a test.

import { getButtonByText } from '@/mocks/helpersForTesting/searchElements/index.js';
import { mount } from '@vue/test-utils';
import AddIncomingMail from '@/components/AddIncomingMail.vue';
import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
import { createTestingPinia } from '@pinia/testing';

let wrapper; // storing a component instance

beforeEach(() => { // before each test we mount the component with the initial settings
 wrapper = mount(AddIncomingMail, {
   global: {
plugins:[    
createTestingPinia({ // Create a test instance of Pinia
         createSpy: vi.fn,
         stubActions: false,
         initialState: {
           user: {
             state: {
               claims: [1,2],
             },
           },
         },
       }),]
     stubs: { // Since this is unit testing, we replace all child components with stubs
       AddIncomingMailModal: {
         name: 'AddIncomingMailModal',
         emits: ['mail-added'],
         template: '<div><h2 >Add correspondence</h2></div>',
       },
       popup: {
         props: { isFormOpen: false },
         template: '<div v-if="isFormOpen"><slot></div>',
       },
     },
   },
   props: {
     lawsuitId: 15,
   },
 });
});

afterEach(() => { // After each test, we reset the stubs and destroy the instance
 wrapper.unmount();
 vi.resetAllMocks();
});

describe('Adding incoming correspondence - AddIncomingMail', () => {
 it('The "Add incoming correspondence" button is active if the user has rights', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' }); // Made a helper for quick search of buttons

expect(button.element.disabled).toBe(false);
});

 it('By clicking on the "Add incoming correspondence" button, a modal window for adding a new document opens', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' });

   await button.trigger('click');
   await wrapper.vm.$nextTick(); //Since Vue makes changes asynchronously, it is important to wait

   expect(wrapper.text()).contain('Add correspondence');
 });

it('When adding incoming correspondence, we generate an event outside the component', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' });
   await button.trigger('click');
   await wrapper.vm.$nextTick();
   const modalStub = wrapper.findComponent({ name: 'AddIncomingMailModal' });

   modalStub.vm.$emit('mail-added');
   expect(wrapper.emitted()).toHaveProperty('mail-added');
 });
});

I would like to draw your attention to how element searching occurs. You should try to search for elements the way a user would search. A less recommended, but more popular approach is using data-testid=”foo”.

Note: Settings like the ones below:

afterEach(() => { // After each test, we reset the stubs and destroy the instance
  wrapper.unmount();
  vi.resetAllMocks();
});

can be moved to external files and connected in the vite.config.js settings as a global setting:

// vite.config.js
export default defineConfig({
  test: {
    // ...
    setupFiles: ['path to your file'],
    // ...
  },
});

Problem with unit tests

Ultimately, unit tests help establish a contract between components. However, there's a downside: if we change the modal’s code, for example, its emitted events, the test for AddIncomingMail won’t fail.

This is where integration tests (as mentioned earlier) come in, testing larger sections of the app.

I haven’t fully implemented those tests yet, as I’m still thinking about the infrastructure and mocks (particularly for server requests), through a conditional msw. However, there is a problem with maintaining the relevance of mocked responses (fixtures). Ideally, I'd like to use “Vitest browser mode” or “Playwright CT”, but these tools are still in their infancy.

Start testing your code early and don’t treat testing as something separate from development. Yes, at first it will be tough, and yes, it will continue to be tough, but soon enough, you’ll just get used to it.

Author: Dmitry Simonov, Frontend Developer at ByteMinds

Unit Testing in Python

Thu, 04 Apr 2024 23:40:16 +0000

There are two types of developers in the programming world. The first one writes code and walks away, does not watch it run. They assume everything will go according to plan. There is the second type, who is writing unit tests. With Python built-in test modules, you can effectively write code to test your software's modules. It will give you peace of mind that eludes all too many programmers. Most companies and teams require their code to be thoroughly examined. This saves you a lot of time and also gives you confidence that your updates and refactoring don't have any unintended consequences to break your code execution in a way.
So, in this article, I will cover the details of the basic understanding of unit testing, its importance, the key principles and benefits while writing code in Python, how to write tests, its environment setup, and some best practices.

Understanding Unit Testing

Definition of Unit Testing

Unit testing is the practice or software testing framework used for examining the smallest piece of code, referred to as a unit, and testing them individually to check if they are functioning as intended. Additionally, it isolates the smallest piece of testable software from the remainder of the code to determine if it behaves as expected and according to the requirement in operation.

Purpose of Unit Testing

The primary purpose of unit testing is to verify each unit or component of the software individually and whether each functionality is working based on the user's requirements. It encourages the developer to write cleaner and modular code that is independent of other modules. Using unit testing, you can easily maintain the software application over time.

Key Principles of Unit Testing

Unit testing is the initial phase of software testing, where an individual unit or component of the software is tested against the needs and requirements of the user. Several key principles help us to ensure the correct testing mechanism so that each unit performs the expected designed functionality. Here are the principles:

1. Isolation

The first fundamental testing principle is isolation, which means that each unit that has undergone testing should not be independent of other modules. Each functionality is tested separately, like the module having one specific functionality. It ensures that the issue in one module does not affect the working of another module. So, make sure each tested unit is isolated.

2. Independence

Independence is another principle that requires consideration while testing. It means that each unit test is independent of the other unit test. In this way, the test failure of one unit does not impact the execution of another unit. Also, it ensures that the unit testing is done in any order and that one module testing is not waiting for another unit result.

3. Repeatable

This principle is most widely used for automated test suites, where results should be consistent irrespective of how many times we run the unit test. Therefore, the unit test code should be repeatable.

4. Fast

Each unit test should be able to quickly identify the defect when the testing fails. This principle ensures the fastest way of testing the individual unit instead of testing the whole application at once.

Benefits of Unit Testing

1. Early Bug Detection

Unit testing helps us find software bugs early. It is carried out by developers who test individual code prior to integrating multiple modules. Bugs or issues are identified very early and resolved without impacting other pieces of code, thus facilitating early detection of errors in the software.

2. Simplified Debugging

Unit testing also makes debugging easier and quicker. It helps simplify the debugging process, if a test fails only then the latest changes made in the code need to be debugged.

3. Code Documentation

Code documentation mostly shows how little code documentation gets written. Unit testing can make the documentation burden a little easier by encouraging better coding practices and leaving behind the piece of code that describes what your program is going to achieve.

4. Refactoring Confidence

It makes the coding process more agile when you add more and more features to software applications and sometimes need to change the old design and code. However, changing the already-tested code is both risky and extremely costly. If we have a unit test in place, then we can proceed with refactoring very confidently to verify each part of a code is working properly.

Getting Started with Unit Testing in Python

1. Introduction to Python's Built-in Unit Testing Framework: unittest

Python has introduced two main modules for performing unit testing, i.e. unittest and pytest. The unitest module is part of the Python standard library. So, there is no need to pip install it. It is a testing framework that allows us to write and execute unit tests for our Python modules. It has a set of classes and methods that provide us the functionality to write unit tests and execute them, working based on object-oriented concepts.

2. Setting up a project for Unit Testing

Before starting the technical details to understand the unit testing, make sure you installed Python with the VS Code on your machine and also set up the project in the necessary directory. So, let's get started.

2-1. Project Structure

First, create a directory and name it according to your choice. Then, create two subdirectories in it; the first one is named src, used for saving the main source code without unit testing. The second one is named test, where you put the unit test code. So, this is the way to set up the project in Python using the necessary directory structure. Let's say we have the following project structure:

![][1]

2-2. Installation of necessary Libraries

As discussed above, unittest is the testing framework and is part of the Python standard library. So, there is no need for additional installation. Also, just make sure that the python is installed on your computer.

Unit Testing Algorithm

![][2]

Let us see a simple algorithm of unit testing in which you can start by writing test code and adding these tests to the test suit. Then you run the unit test, if the test passes, you add one more test or add to the next level of testing. In case of test failure, you make the necessary changes and execute the unit test again but failed. However, you repeat the cycle and make changes until the code is perfectly working and returns the expected results. On the other hand, after making changes if the test passes, you can add it to the test suite and move on to the next unit test. After completing all the tests and checking the functionality you can stop the testing.

3. Writing your First Unit Test

3-1. Creating Source Code

Before demonstrating the testing, you require the source code upon which unit testing is performed. Suppose you are making a simple calculator that performs basic math operations like addition, subtraction, multiplication, and division. All these operations are written in the file named calculator.py, which is placed in the src directory. Let's move towards the coding part.

print("SIMPLE CALCULATOR") print("Having operation '+', '-', '*' and '/'") class calculator: def addition(num1, num2): #function for addition num3 = num1 + num2 return num3 def subtraction(num1, num2): #function for subtraction num3 = num1 - num2 return num3 def multiplication(num1, num2): #function for multiplication return num1 * num2 def division(num1, num2): #function for division num3 = num1 / num2 return num3 result1 = addition(10, 5) result2 = multiplication(5, 5) print("Addition of two numbers:" , result1) print("Multiplication of two numbers:" , result2)

3-2. Writing Test Methods

Now, we want to test the methods inside the above code. For that, we need to import the unittest module, then required to create a test method which is based on the base class TestCase containing functions for performing unit testing.

import unittest #importing the module from src_code.calculation import calculator # importing the function form the main class class Testing(unittest.TestCase): #used the base class for creating testing subclass def test_addition(self): #create the test function self.assertEqual(calculator.addition(5,5), 10) #takes the values and its answer and check its correctness self.assertEqual(calculator.addition(6,7), 13) def test_multiplication(self): #another function self.assertEqual(calculator.multiplication(5,5), 25) #takes the values and its answer and check its correctness self.assertEqual(calculator.multiplication(4,2),8) if __name__ == '__main__': #used to class the main class of unittest unittest.main()

In the above code, addition() and multiplication() functions of calculator.py are tested. To achieve this, we have to do the following:

Import the unittest library and the calculator class from calculator.py.
Then, create the testing method for both addition() and multiplication() methods using the calculator instance.
Use the assertEqual function that checks that the given values output or the expected output should be the same and equal.

3-3. Running Tests

For running the unit test, we use unittest.main(), which will execute the test when the program runs. It will displays the output when the program tested successfully but, if the program fails, the compiler will highlight the error in the terminal and show that the testing failed.

![][3]

If we change the excepted output values of the multiplication() function, then testing fails and this will be displayed in the terminal:

![][4]

Note: Remember, it is the convention that all the testing methods should start with the keyword test_ because this way unittest can easily identify the method that needs to be executed.

Anatomy of a Unit Test

1. Test fixture setup and teardown

After understanding the basics of the unittest module, we move towards the more advanced concepts of the testing framework used for optimizing the code. Test fixture setup and teardown are widely used for initializing and cleaning up the task before and after the test execution. Suppose we create a class called employee having all employee details. Now, we want to test the emails and payment increment of each employee, for that, we have to write the test code for each employee, and it's hectic. Also, it creates redundant code repeatedly. So, to resolve this problem, I am going to use two components in the unittest modules used for optimizing the code.

1-1. setUp() method

The setUp() method will run its code before every single test is executed. It is helpful when you have to perform the same task again and again in each test function. Therefore, placing that piece of code in the setUp() function will help you in redundancy reduction and optimization. Let's move towards the coding part for better understanding.

employee.py class Employee: #employee class increment_amt = 1.05 #variable with increment value def __init__(self, name, pay): #function for taking values self.name = name self.pay = pay @property def email(self): #email function return '{}@gmail.com'.format(self.name) def increment(self): #function of incremeting the payment self.pay = int(self.pay * self.increment_amt) emp_testing.py import unittest #importing the module from src_code.employee import Employee class Testing(unittest.TestCase): #used the base class for creating testing subclass def setUp(self): #setup the resource before each execution self.emp1 = Employee('john', 50000) self.emp2 = Employee('stephen', 60000) def test_email(self): self.assertEqual(self.emp1.email, '*Emails are not allowed*') self.assertEqual(self.emp2.email, '*Emails are not allowed*') def test_increment(self): self.emp1.increment() self.emp2.increment() self.assertEqual(self.emp1.pay, 52500) self.assertEqual(self.emp2.pay, 63000) if __name__ == '__main__': #used to class the main class of unittest unittest.main() ![][5]

1-2. tearDown() method

The tearDown() will run its code after the test execution. It is for releasing the resources after using it like database connection or some cleanup activities.

def setUp(self): #setup the resource before each execution self.emp1 = Employee('john', 50000) self.emp2 = Employee('stephen', 60000) def tearDown(self): #deleting the employee del self.emp1

2. Writing Assertions

2-1. Using Assert Statements

In Python, the assert is the built-in statement used for checking the conditions. If the condition is true, it will not show anything but in case of error or the false condition, it will raise the error. Most assert statements are considered as exceptions and errors, but developers prefer their utilization for testing and debugging purposes.

n = 1 assert 1 < n, 'This condition is false' #checks and print only if its false Output ![][6]

2-2. Common Assert Methods

As we discussed the assert statement above, there is no need to use it separately in the program. The unittest module contains the base class TesCase and provides all the assert functions that work exactly like assert statements without detailed coding. These methods are used within the test method to check whether the resulting output matches the excepted output. Here, I will discuss the common assert methods provided by the TestCase class of unittest.

![][7]

Tip: Always try to avoid testing the external dependencies like databases, files, or network connections because they slow down tests and make them brittle.

FAQs Q: What is the unittest.TestCase in the unittest module?
A: unittest.TestCase is the base class of the unittest module that serves as a container for all individual test Q: When should I start writing the test cases?
A: The best approach is to write when you are developing the application because it ensures that application is free of bugs from the early stage.

Wrapping Up

To sum up, we discussed the basics of unit testing and got to know its importance in the development and maintenance of software. We also learn the unit testing techniques by using the coding examples. It shows that unit testing is a very crucial phase before other testing. It also ensures that the individual module is error-prone and modular. Developer needs to understand that the use of unit testing during the application developement will save most of their time and ensure the quality of software. I hope this guide is helpful for you. Also, if you have any questions or concerns, then feel free to ask and give feedback. Thank you for following this guide. Happy Coding!

Reference

Unit Testing [1]: https://logiclair.org/?qa=blob&qa_blobid=16541390965964414061 [2]: https://logiclair.org/?qa=blob&qa_blobid=4202928536661986523 [3]: https://logiclair.org/?qa=blob&qa_blobid=7841557182954355083 [4]: https://logiclair.org/?qa=blob&qa_blobid=9280295931013992206 [5]: https://logiclair.org/?qa=blob&qa_blobid=1643797813287049192 [6]: https://logiclair.org/?qa=blob&qa_blobid=3774790010506432385 [7]: https://logiclair.org/?qa=blob&qa_blobid=12721698954172678740