DEV Community: Axmin Shrestha

Mock vs. SpyOn in Vitest with TypeScript: A Guide for Unit and Integration Tests

Axmin Shrestha — Sun, 26 Jan 2025 23:56:50 +0000

When to mock dependencies and when to spy on behavior for effective testing.

Testing is the backbone of reliable software, but choosing the right tools for the job can be tricky. In Vitest with TypeScript, two powerful utilities, mock and spyOn, often cause confusion. Let’s break down their use cases, differences, and best practices to help you write better unit and integration tests.

What’s the Difference?

At a glance:

mock replaces a function/module’s implementation entirely.
spyOn observes a function’s behavior without changing it (unless you tell it to).

When to Use `mock`

Use vi.mock to isolate your code from external dependencies by replacing their implementations.

Use Cases

Unit Testing Mock dependencies (e.g., APIs, databases) to test a single component in isolation.

   // Mock an API client
   vi.mock('@/services/api', () => ({
     fetchData: vi.fn().mockResolvedValue({ data: 'fake' }),
   }));

   test('displays mocked data', async () => {
     render(<DataFetcher />);
     await waitFor(() => expect(screen.getByText('fake')).toBeVisible());
   });

Avoid Side Effects

Prevent network calls, file system operations, or other costly actions.
Simulate Edge Cases

Force errors or unusual responses (e.g., 500 status codes).

When to Use `spyOn`

Use vi.spyOn to track function calls and arguments while preserving the original behavior.

Use Cases

Integration Testing Verify interactions between modules without breaking their real behavior.

   import * as analytics from '@/utils/analytics';

   test('logs an event on button click', () => {
     const trackSpy = vi.spyOn(analytics, 'trackEvent');
     render(<SignupButton />);
     userEvent.click(screen.getByText('Sign Up'));
     expect(trackSpy).toHaveBeenCalledWith('signup_clicked');
   });

Assert Function Behavior

Check if a function was called, how many times, or with specific arguments.
Temporary Overrides

Mock a function for a single test, then restore it:

   const spy = vi.spyOn(validator, 'isValid').mockReturnValue(false);
   // Test invalid case
   spy.mockRestore(); // Restore original

Unit Tests vs. Integration Tests

Test Type	Mock (`vi.mock`)	Spy (`vi.spyOn`)
Unit Tests	Mock all dependencies to isolate code.	Rarely used. Check indirect side effects.
Integration	Mock external services (e.g., APIs).	Spy on internal logic (e.g., logging).

Key Differences

Feature	`mock`	`spyOn`
Implementation	Replaces the original function.	Retains original behavior by default.
Scope	Applies to entire modules or functions.	Works on individual object methods.
Cleanup	Auto-reset with Vitest config.	Manually restore with `mockRestore()`.

Combining Mocks and Spies

In complex scenarios, mix both tools:

// Mock an external API
vi.mock('@/services/payment', () => ({
  processPayment: vi.fn().mockResolvedValue({ success: true }),
}));

// Spy on an internal validator
const validateSpy = vi.spyOn(validator, 'validateCard');

test('processes payment with valid card', async () => {
  await submitPayment({ card: '4111 1111 1111 1111' });
  expect(validateSpy).toHaveReturnedWith(true);
  expect(processPayment).toHaveBeenCalled();
});

TypeScript Pro Tips

Type-Safe Mocks Use MockedFunction or MockedObject for better type inference:

   import type { fetchData } from '@/services/api';
   vi.mock('@/services/api');
   const mockedFetch = vi.mocked(fetchData); // Type-safe mock!

Spy Assertions Add type assertions if needed:

   const spy = vi.spyOn(console, 'log') as MockedFunction<typeof console.log>;

Final Advice

Unit Tests: Mock aggressively to isolate components.
Integration Tests: Spy to validate interactions, mock only externals.
Always Restore Spies: Use afterEach(() => vi.restoreAllMocks()) to avoid test pollution.

By mastering mock and spyOn, you’ll write tests that are faster, more reliable, and easier to debug. Happy testing! 🚀

Got questions? Drop them in the comments below!

Follow for more Vitest and TypeScript tips!

Stages of Git Hook Execution Visualization

Axmin Shrestha — Wed, 06 Mar 2024 14:14:51 +0000

Here's a brief explanation of each hook:

                +--------------------+
                |   Pre-Commit Hook  |
                +--------------------+
                          |
                          v
                +--------------------+
                |   Commit-Msg Hook  |
                +--------------------+
                          |
                          v
                +--------------------+
                |     Commit Hook    |
                +--------------------+
                          |
                          v
                +--------------------+
                |  Pre-Rebase Hook   |
                +--------------------+
                          |
                          v
         +-------------------------------+
         |            Rebase             |
         |           (Pre-Rebase,        |
         |       Post-Rebase Hooks)      |
         +-------------------------------+
                          |
                          v
                +--------------------+
                |   Post-Rebase Hook |
                +--------------------+
                          |
                          v
                +--------------------+
                |   Pre-Receive Hook |
                +--------------------+
                          |
                          v
                +--------------------+
                |    Update Hook     |
                +--------------------+
                          |
                          v
                +--------------------+
                |   Post-Receive Hook|
                +--------------------+
                          |
                          v
                +--------------------+
                |   Post-Commit Hook |
                +--------------------+
                          |
                          v
                +--------------------+
                |   Post-Merge Hook  |
                +--------------------+

The commit-msg hook runs after the commit message has been entered and before the commit is recorded. This hook can be used to validate the commit message format, enforce commit message conventions, or perform any other checks or modifications related to the commit message.

The commit-msg hook receives the path to the temporary file containing the commit message as an argument. If the script exits with a non-zero status, the commit operation will be aborted.

Pre-Commit Hook: Runs before you commit any changes to the local repository. It can be used to validate the commit message, check code style, run tests, etc.

Commit Hook: Runs after the commit data has been committed to the local repository. It can be used for tasks like updating a commit message template or firing a deployment script.

Pre-Rebase Hook: Runs before a rebase operation starts. It can be used for tasks like stopping the rebase if certain conditions are met.

Rebase Hooks: Several hooks are available during the rebase operation:

pre-rebase: Runs before the rebase operation starts.
post-rebase: Runs after the rebase operation completes successfully.

Post-Rebase Hook: Runs after a successful rebase operation.
Pre-Receive Hook: Runs on the remote repository before any references are updated by the git push command. It can be used to enforce repository policies.

Update Hook: Runs on the remote repository after the references have been updated by the git push command. It can be used to update external systems or triggers.

Post-Receive Hook: Runs on the remote repository after the references have been updated by the git push command. It can be used for deployment scripts or notifications.

Post-Commit Hook: Runs after a successful commit operation.
Post-Merge Hook: Runs after a successful merge operation.

9 Key Rules for Using Git

Axmin Shrestha — Fri, 21 Jul 2023 11:23:36 +0000

Here are some important rules to follow when using Git:

Work on a feature branch: This is important because it means you do all your work in a separate branch, not the main one. It lets you submit more than one pull request without any mix-ups. Plus, you can make changes without risking any instability in the master branch with unfinished code.
Always branch out from develop: By doing this, you make sure that the code in the master branch can be used for releases almost always without any problems. (This might not be necessary for some projects.)
Don't push directly into develop or master branch. Instead, make a Pull Request: This lets your team know that you've finished a feature. It also makes it easy for your peers to review your code and provides a space to discuss the feature you're proposing.
Update your local develop branch and do an interactive rebase before pushing your feature and making a Pull Request: This merges in the requested branch (master or develop) and puts the commits you've made locally at the top of the history. This means the history will be neat and tidy.
Solve any conflicts while rebasing and before making a Pull Request. When you rebase your branch before a Pull Request, you're integrating changes from one branch into another. During this process, conflicts may arise if Git can't decide how to merge the changes. It's crucial to resolve these conflicts during the rebase, before creating your Pull Request. This way, you ensure a clean, conflict-free branch that can be smoothly merged into the main codebase. Resolving conflicts early avoids potential issues down the line and facilitates a faster, more efficient review process for your Pull Request.
Delete your local and remote feature branches after they've been merged: This stops your list of branches from getting cluttered with branches you're not using anymore. It also makes sure you only merge the branch back into master or develop once.
Before making a Pull Request, check your feature branch to make sure it's working properly and passes all tests (including style checks): This is because you're about to add your code to a stable branch. If your tests fail, there's a high chance the destination branch will fail too. Also, doing a style check before making a Pull Request helps keep everything readable and makes sure any formatting fixes are separate from the actual changes.
Use .gitignore file: This file already has a list of system files that you shouldn't include in your remote repository. It also excludes certain folders and files for most editors, as well as most common dependency folders.
Protect your develop and master branch: This keeps your ready-to-go branches safe from unexpected changes.

That's it! By following these rules, you can make sure your Git workflow is smooth and efficient.

Test-Driven Development (TDD) with React/Nextjs

Axmin Shrestha — Fri, 14 Jul 2023 21:07:47 +0000

Test-driven development (TDD) with a React frontend that uses libraries like react-query, react-table, Tailwind CSS, and Mock Service Worker (MSW) involves writing tests that assert the behavior of your application. Here are some areas you might consider when writing your tests:

Components:

Use Jest/vitest and React Testing Library for testing components. Assert that components render correctly based on different props.
With react-table, test that your table components render the expected data and support the necessary interactions, such as sorting or filtering.
API Interactions:

With react-query, you can test your query and mutation functions to ensure they behave as expected. This includes how your app reacts to success, error, and loading states.
MSW allows you to create a mock server in the browser. Use this to simulate API responses and errors for your tests, ensuring your app behaves correctly given different server responses.
Styling and Layout:

With Tailwind, since the focus is more on utility classes and less on custom styles, it's less likely that you need to write specific tests for styles.
You can still perform visual regression testing using tools like Cypress, Jest Snapshot, or Storybook to ensure your UI does not change unexpectedly.
You can also use accessibility testing tools to ensure your site is accessible, which is particularly important if you are heavily customizing the styles.
Integration and End-to-End tests:

Once you have the individual units of your app tested, write some integration tests to make sure they work well together.
Tools like Cypress or Puppeteer/Playwright can be used to automate browser-based interactions, testing flows that involve several components.
Simulate user interactions like button clicks, form submissions, etc., and check if the app behaves as expected.
Edge Cases and Error Handling:

Make sure you have tests for any edge cases you can think of.
It's especially important to test your error handling to ensure your app can recover gracefully from errors.

Remember, TDD is about writing your tests first and then writing the code to make those tests pass. So you would first write tests for a small piece of functionality, run the tests to make sure they fail, then write the code to make them pass, and finally refactor the code while keeping the tests green. This cycle is often referred to as Red-Green-Refactor.

How to avoid Technical Debt? Discover the foolproof strategies to steer clear of technical debt.

Axmin Shrestha — Fri, 14 Jul 2023 21:03:20 +0000

In the fast-paced world of technology, staying ahead of the curve is essential for any startup. But amidst the excitement of innovation and growth, there lurks a silent menace known as technical debt. To steer clear of this treacherous trap that can undermine your success, it's crucial to adopt a strategic approach. By following a set of best practices, you can ensure that your codebase remains clean, maintainable, and scalable, paving the way for long-term growth and prosperity.

Educate non-technical team members about technical debt and its consequences.
Hire technical staff or consultants with web development experience.
Prioritize thorough planning that considers technical debt mitigation.
Establish coding standards and guidelines for developers to follow.
Conduct regular code reviews to identify potential technical debt.
Implement a strong testing strategy with automated tests.
Leverage external resources like online communities and conferences.
Encourage continuous learning and skill development.
Allocate time and resources for addressing existing technical debt.
Foster a collaborative culture across the team.

Avoiding technical debt is crucial for long-term success in software development. By educating team members, hiring technical expertise, planning effectively, setting coding standards, conducting code reviews, prioritizing automated testing, utilizing external resources, emphasizing continuous learning, planning for debt repayment, and fostering a culture of collaboration, startups can mitigate technical debt and maintain a healthy codebase. With a proactive approach and commitment to these best practices, startups can ensure sustainable growth and minimize the risks associated with technical debt.

DEV Community: Axmin Shrestha

Mock vs. SpyOn in Vitest with TypeScript: A Guide for Unit and Integration Tests

When to mock dependencies and when to spy on behavior for effective testing.

What’s the Difference?

When to Use mock

Use Cases

When to Use spyOn

Use Cases

Unit Tests vs. Integration Tests

Key Differences

Combining Mocks and Spies

TypeScript Pro Tips

Final Advice

Stages of Git Hook Execution Visualization

9 Key Rules for Using Git

Test-Driven Development (TDD) with React/Nextjs

How to avoid Technical Debt? Discover the foolproof strategies to steer clear of technical debt.

When to Use `mock`

When to Use `spyOn`