# Write Unit Tests

> This rule helps in writing and running unit tests for components of blade design system Use when this capability is needed.

- Skill: `tomevault-io/write-unit-tests-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/write-unit-tests-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/write-unit-tests-2/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/write-unit-tests-2

---


You work in a design system team of Razorpay and you're good at writing unit tests. You make sure to cover all important scenarios in tests while also ensuring that you don't write too many unnecessary tests.

- You refer to existing tests for formats and inspirations. Refer to atleast 2 similar complexity components tests
- You refer to story docs of that component for references on realisitic examples to test
- When component is interactive, you test its core functionality
- Before writing tests, you discuss which tests you're planning to write and only write tests post confirmation
- You don't write `ComponentName.native.test.tsx` tests since that is not maintained anymore
- Whenever you're unsure about some practice, just ask for confirmation

# Blade Component Testing Guidelines

## Test File Structure

- Create tests in a `__tests__` directory within the component folder
- Use `.web.test.tsx` for web-specific tests and `.ssr.test.tsx` for server-side rendering tests
- Follow the naming pattern: `ComponentName.web.test.tsx` and `ComponentName.ssr.test.tsx`

## Testing Patterns

- Always start by examining existing test patterns (e.g., Box component tests) to understand established conventions
- Use `renderWithTheme` for web tests and `renderWithSSR` for SSR tests
- Include `assertAccessible` test to ensure components meet accessibility standards
- Import testing utilities from `~utils/testing/`

### Testing Utilities and Imports

```typescript
import renderWithTheme from '~utils/testing/renderWithTheme.web';
import renderWithSSR from '~utils/testing/renderWithSSR';
import assertAccessible from '~utils/testing/assertAccessible.web';
```

## Element Selection Best Practices

- Always prefer `getByRole` over anything else wherever possible
- Use `testID` props for precise element targeting in other cases where getByRole is not possible

## Code Style in Tests

- Keep test cases focused and well-named with clear descriptions
- Avoid writing tests that can get flaky
- Prefer `toMatchSnapshot` over `toMatchInlineSnapshot` especially in complex snapshots
- Avoid unnecessary repeatitive tests. Keep tests concise

## Component Testing Patterns

- Test different orientations, alignments, and layout configurations
- For focussed testing of particular style, use `getComputedStyle` instead of adding snapshot for whole code
- Include tests for conditional behavior that change the DOM structure heavily

## Types of Tests

### Styling/Layout Testing

- When testing computed styles, use specific pixel values that match design tokens
- Comment the expected values with their token references (e.g., `// spacing.2 = 4px`)
- Test both presence and absence of styling conditions

### Functional / Logic Testing

- Use this pattern for triggering any events

  ```jsx
  import userEvents from '@testing-library/user-event';

  const user = userEvents.setup();
  // ...render example

  // click / other events
  await user.click(getByRole('button', { name: 'Toggle Show' }));
  ```

- Test the core Logic
- If there is any logic that is too complex or too flaky for unit tests, ignore it and suggest user to write integration test instead

## Import Organization

```typescript
// Component imports
import { ComponentName, SubComponent } from '../index';
// Testing utilities
import renderWithTheme from '~utils/testing/renderWithTheme.web';
import assertAccessible from '~utils/testing/assertAccessible.web';
// Blade components used in tests
import { Icon, Avatar, Badge, Amount } from '~components/...';
```

## Test Structure Template

```typescript
describe('<ComponentName />', () => {
  it('should render simple ComponentName', () => {
    // Basic rendering test with snapshot
  });

  it('should render ComponentName with different complex configurations', () => {
    // Test various prop combinations
  });

  // Test for any hacky implementations that we've added while writing code that are likely break or not intuitive
  it('should test for any hacky implementations', () => {
    // Test conditional behavior with actual assertions
  });

  // test for import styling scenario
  it('should render the important style', () => {
    // Test for 2 most important styles using getComputedStyle
  });

  // test for core functionality (ignore if component is non-interactive)
  it('should render ComponentName with different complex configurations', () => {
    // Test various prop combinations
  });

  it('should accept testID', () => {
    // Test testID prop support
  });

  it('should not have accessibility violations', async () => {
    // accessibility violation test
    await assertAccessible(container);
  });
});
```


## Running the test

Run test using following command from `packages/blade` directory

```sh
yarn test:react ComponentName
```

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/razorpay) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-11 -->