Fixing `withQase` And `it.each` Issues In Vitest

Dec 3, 2025 by Admin 49 views

Hey everyone! Today, we're diving deep into a quirky issue some of us have encountered while trying to integrate withQase from vitest-qase-reporter with Vitest's it.each. It's a bit of a technical rabbit hole, but stick with me, and we'll get through it together. We'll explore the problem, understand why it's happening, and, most importantly, figure out how to work around it. So, grab your favorite coding beverage, and let's get started!

The Problem: `withQase` and `it.each` Don't Play Nice

So, you're trying to use withQase to integrate your Vitest tests with Qase TMS, and you're using it.each to run the same test with different data sets. Sounds reasonable, right? Well, here's the catch: it doesn't quite work as expected. The main issue is that it.each seems to overwrite the context provided by withQase. This means that the qase and annotate objects, which are supposed to be injected by withQase, are nowhere to be found when the test actually runs.

Essentially, the values you provide in the it.each array (like id and name in the example) end up clobbering the qase and annotate objects that withQase is supposed to provide. This is super frustrating because it means you can't easily use Qase's features, like steps and annotations, within your data-driven tests. This is a significant roadblock when you're trying to keep your tests organized and easily reportable to Qase. Furthermore, the return type of withQase isn't directly compatible with the expected type of the it.each callback function, forcing you to use workarounds like type assertions (e.g., as Awaitable<void>).

Here’s a snippet that illustrates the problem:

import { withQase } from "vitest-qase-reporter/vitest";
import { describe, it, expect } from "vitest";
import { Awaitable } from "@vitest/utils";

describe("Some", () => {
  it.each([
    { id: 1, name: "Should be true" },
    { id: 2, name: "Should be false" },
  ])(
    "Should be true (Qase ID: $id)",
    withQase<[{ name: string }]>(
      async ({
        qase,
        name,
        annotate,
      }) => {
        console.log(name);

        await qase.step(name, () => {
          expect(true).toBe(true);
        });

        await qase.step(name, () => {
          expect(false).toBe(true);
        });
      }
    ) as unknown as Awaitable<void>
  );
});

In this example, you'd expect qase and annotate to be available inside the withQase callback, but they're not, because it.each overwrites the context. It's like inviting someone to a party and then not letting them in the door!

Why This Happens: A Deep Dive

Okay, so why exactly does this happen? To understand that, we need to delve a little deeper into how it.each and withQase are implemented and how they interact with Vitest's testing context.

it.each is designed to run the same test multiple times with different sets of data. It iterates over an array of test cases and, for each case, it executes the provided callback function. The callback function receives the data for that specific test case as arguments. This is great for data-driven testing, where you want to ensure your code works correctly with a variety of inputs.

On the other hand, withQase is a higher-order function that wraps your test function and injects the qase and annotate objects into the test context. These objects provide the functionality to interact with Qase TMS, such as creating steps, adding attachments, and updating test results. The idea is that you can use withQase to easily integrate your tests with Qase without having to manually manage the Qase API client.

The problem arises because it.each and withQase both try to modify the test context in different ways. it.each overwrites the context with the data for the current test case, while withQase injects the Qase-related objects. When you use them together, it.each wins, and the qase and annotate objects are lost. It's a classic case of two libraries trying to do conflicting things with the same underlying mechanism.

Think of it like this: Imagine you have a guest room (the test context). it.each comes along and redecorates the room with furniture specific to each guest (test case). Then, withQase tries to add some special amenities, like a fancy coffee machine and a personalized welcome note. But because it.each keeps redecorating the room for each guest, the coffee machine and welcome note get thrown out with each change. Bummer!

Workarounds and Solutions

Alright, enough with the problem! Let's talk about how to actually solve this issue. While there isn't a perfect, out-of-the-box solution (yet!), there are a few workarounds you can use to get withQase and it.each working together.

1. Manual Injection

One approach is to manually inject the qase and annotate objects into the test context. This involves calling the withQase function outside of the it.each callback and then passing the necessary data to the test function. It's a bit more verbose, but it gives you more control over the test context.

Here's how you can do it:

import { withQase } from "vitest-qase-reporter/vitest";
import { describe, it, expect } from "vitest";
import { qase } from "vitest-qase-reporter";

describe("Some", () => {
  it.each([
    { id: 1, name: "Should be true" },
    { id: 2, name: "Should be false" },
  ])(
    "Should be true (Qase ID: $id)",
    async ({ id, name }) => {
      console.log(name);

      await qase.step(name, () => {
        expect(true).toBe(true);
      });

      await qase.step(name, () => {
        expect(false).toBe(true);
      });
    }
  );
});

In this example, we're importing qase directly from "vitest-qase-reporter". This allows us to use qase.step inside the it.each callback. This removes the need to use withQase at all.

2. Custom Wrapper

Another approach is to create a custom wrapper function that combines the functionality of it.each and withQase. This wrapper would take the test data and the test function as arguments, and it would handle injecting the qase and annotate objects into the test context before calling the test function. This approach is more complex, but it can provide a cleaner and more reusable solution.

3. Awaitable workaround

As shown in the example code, you can use a type assertion to force the return type of withQase to be compatible with the it.each callback function. This is not ideal, as it can hide potential type errors, but it can be a quick fix in some cases. However, it does not fix the issue of it.each overwriting the context of withQase.

Potential Future Solutions

While these workarounds can help you get by for now, it's important to consider potential long-term solutions. Here are a few ideas:

Vitest Plugin Enhancement: The vitest-qase-reporter plugin could be updated to better handle the it.each scenario. This might involve modifying the plugin to inject the qase and annotate objects in a way that doesn't conflict with it.each's context management.
Vitest Core Changes: It might be beneficial for Vitest itself to provide a more flexible way to manage test context, allowing plugins like vitest-qase-reporter to more easily inject their own objects without conflicts.

Conclusion

So, there you have it! Integrating withQase with it.each in Vitest can be a bit of a headache, but with the workarounds and solutions we've discussed, you should be able to get your tests running smoothly and reporting correctly to Qase. Remember, the key is to understand how it.each and withQase interact with the test context and to find a way to inject the qase and annotate objects without conflicts.

Happy testing, and may your Qase reports always be green!