Spies

/

Introduction

Why spy or mock?
👺 Why "test" mocks? It's fake!
Spies observe functions
Spies gather information on function calls
👺 But spies break functions!

Testing real-world apps like our blogging platform is tricky when code hits databases or APIs. Spies watch functions to check their behavior—how many calls, what arguments—while mocks replace real code with fake versions we control. This keeps tests fast, reliable, and focused on our logic, not external systems.

Some think spying or mocking makes tests “fake.” Not true! Spies observe real code, and mocks isolate your logic, ensuring you test what matters without flaky dependencies.

In Vitest, spies track function calls without changing what the function does. They’re like a logbook, recording how many times a function ran and with what arguments, perfect for verifying user interactions in our app.

Suppose a user filters posts by tag. We need to ensure our getPostsByTag function is called correctly. Spies let us check this without worrying about what the function returns, focusing on behavior.

Students often think spies fake the function. Nope! Spies let the real code run—they just watch it. Confusing spies with mocks leads to this error, but we’ll clarify both today.

Spies

/

Example

    // tests/posts.test.ts
import { describe, it, expect, vi } from "vitest";
import { getPostsByTag } from "../utils/posts";
import { prisma } from "../utils/client"

describe("getPostsByTag", () => {
  it("calls getPostsByTag with correct tag", () => {
    // Arrange
    const spy = vi.spyOn(prisma.posts, "findMany");
    
    // Act
    getPostsByTag("tech"); 
    
    // Assert
    expect(spy).toHaveBeenCalledWith({
      where: { tag: "tech" }
    }); 
  });
});

Let’s test a function that fetches posts by tag in our blog app. We’ll spy on it to ensure it’s called with the right tag when a user filters posts, a real scenario for our UI. The application uses Prisma ORM.

First, we import the function getPostsByTag that we are going to test.

Then, we import the prisma client, which we will be spying on to make sure it is used correctly.

We need to arrange and prepare objects before we can run the test. In this line, we create the spy, observing calls of findMany on "prisma.posts". Thus, whenever "prisma.posts.findMany" is called, we will know about it.

We arranged our test case, it is time to act. We call getPostsByTag with the tech parameter.

We acted, time to assert. This time, we check whether the spy has been called with the expected parameter, filtering for the tag "tech".

Spies

/

Matchers

    it("logs view", () => {
  const log = vi.spyOn(console, "log");
  console.log("View"); 
  expect(log).toHaveBeenCalled(); 
});

toHaveBeenCalled

how many the spy has been called

Spies

/

Matchers

    it("retries twice", () => {
  const spy = vi.spyOn({ getPostsByTag }, "getPostsByTag");
  getPostsByTag("tech");
  getPostsByTag("tech"); 
  expect(spy).toHaveBeenCalledTimes(2); 
});

toHaveBeenCalledTimes

Ensures exact call count, great for retry logic in failed queries

Spies

/

Matchers

    it("sorts by date", () => {
  const sort = vi.fn();
  const spy = vi.spyOn({ sort }, "sort");
  sort("tag", "ascending"); 
  sort("date", "descending"); 
  expect(spy).toHaveBeenCalledWith("date", "ascending"); 
  expect(spy).not.toHaveBeenCalledWith("date", "descending"); 
  expect(spy).toHaveBeenCalledWith("tag", "descending"); 
});

toHaveBeenCalledWith

Verifies arguments, key for dynamic inputs like tags

Spies

/

Matchers

    it("sorts by date last", () => {
  const sort = vi.fn();
  const spy = vi.spyOn({ sort }, "sort");
  sort("tag"); 
  sort("date"); 
  expect(spy).toHaveBeenLastCalledWith("date"); 
});

toHaveBeenLastCalledWith

Checks the last call’s arguments, useful for sequences.

Spies

/

Example

    // tests/admin.test.ts
import { describe, it, expect, vi } from "vitest";
import { bulkUpdateTags } from "../src/admin";
import * as posts from "../src/utils/posts";

describe("bulkUpdateTags", () => {
  it("updates multiple posts", () => {
    const spy = vi.spyOn(posts, "updatePost"); 
    bulkUpdateTags([1, 2], "news"); 
    expect(spy).toHaveBeenCalledTimes(2); 
    expect(spy).toHaveBeenCalledWith(1, { tag: "news" }); 
    expect(spy).toHaveBeenLastCalledWith(2, { tag: "news" });
  });
});

Spies

/

Takeaways

Spies track behaviour
Best Practices
- vi.restoreAllMocks()
- spy.restore()
Pitfalls

Mocks

/

Introduction

Mocks replace code
Mocks = speed and control
👺 Mocking fakes the whole app

Mocks

/

Example

    // tests/posts.test.ts
import { describe, it, expect, vi } from "vitest";
import { getPostsByTag } from "../utils/posts";
import { prisma } from "../utils/client";

describe("getPostsByTag", () => {
  it("returns mocked posts", async () => {
    vi.mock(prisma.posts, "findMany").mockResolvedValue([
      { id: 1, title: "Mocked Post", tag: "tech" },
    ]); 
    const posts = await getPostsByTag("tech"); 
    expect(posts).toEqual([{ 
      id: 1, title: "Mocked Post", 
      tag: "tech" 
    }]); 
  });
});

Mocks

/

Methods

    // Mock local import
const validate = new DataValidation();
vi.spyOn(validate, "validatePost").mockReturnValue(true);

// Mock local variables
vi.mocked(formatTag)
    .mockImplementation((tag) => tag.toUpperCase()); 

// Mock node module
vi.mock("db-client", () => ({
  query: vi.fn().mockReturnValue([{ id: 1 }]),
})); 

// Mock whole module
vi.mock("../src/utils/posts", () => ({
  getPostsByTag: vi.fn().mockReturnValue([{ id: 1 }]),
}));

Mocks

/

Options

    // Calls
vi.mocked(savePost).mockReturnValue({ id: 1 });
savePost({ title: "Test" });
expect(savePost.mock.calls[0][0]).toEqual({ title: "Test" }); 
expect(savePost).toHaveBeenCalledWith({ title: "Test" })

// Functions
vi.mocked(formatTag).mockImplementation(
    (tag) => tag.toUpperCase()
); 

// Promises
vi.mocked(savePost).mockRejectedValue(new Error("DB error"));

Mocks

/

Example

    import { describe, it, expect, vi } from "vitest";
import { createPost } from "../src/admin";
import * as posts from "../src/utils/posts";
import * as validate from "../src/utils/validate";

describe("createPost", () => {
  it("saves valid post", async () => {
    // Arrange
    vi.spyOn(validate, "validatePost").mockReturnValue(true); 
    vi.spyOn(posts, "savePost").mockResolvedValue({ 
      id: 42, 
      title: "Test" 
    }); 
    
    // Act
    const post = { title: "Test", tag: "tech" };
    const result = await createPost(post); 
    
    // Assert
    expect(validate.validatePost).toHaveBeenCalledWith(post); 
    expect(posts.savePost).toHaveBeenCalledWith(post); 
    expect(result).toEqual({ id: 42, title: "Test" });
  });
});

Let's take a look at a more complex example, where we mock a validator and database save to test the admin’s post creation, representing a complex flow with validation and async logic.

Let's arrange our test. First, we will spy on the validatePost call, but mocking the return value, specifying that the post is valid.

Next, we spy on the savePost methods and again mock the return value with the fake data of the new post.

Next, we act and call the subject under the test, which is the createPost method.

It's time to assert whether everything went as expected. First, we check whether the post validation was called with the post data we created.

Then, we check whether the savePost was called with the same data. Imagine that in another test, we would mock the validation's return value to false and then check that the savePost was not called.

Last, we'll check whether the return value of the savePost function is the expected mocked value.

Mocks

/

To mock or not to mock ...

Mock for isolation
Don’t mock internals
Overmocking

In our last example, we've mocked quite a lot here, so when should we mock and when not? The golden rule is to mock everything that slows down your unit tests or is challenging to set up for unit test execution, such as external API calls and services.

So, mock when your code depends on external systems like databases or APIs. In our blog app, mock savePost to avoid real database calls, ensuring tests are fast and reliable.

Avoid mocking your app’s internal logic, like a post validator. Test real code to catch bugs—mocking too much hides real behavior. You can mock internals if they perform slow computations or heavy operations hindering speed of your unit tests.

Overmocking is like faking every function, makes tests unrealistic. If we mock all post logic, we’re not testing the app, just our mocks. Mock only what’s necessary. And keep it type safe! That's it for today lecture, go mock!

Full Stack Development

Spying and Mocking

Spies

Introduction

Spies

Example

Spies

Matchers

Spies

Matchers

Spies

Matchers

Spies

Matchers

Spies

Example

Spies

Takeaways

Mocks

Introduction

Mocks

Example

Mocks

Methods

Mocks

Options

Mocks

Example

Mocks

To mock or not to mock ...