# How to Run Apache Superset Tests in the Bun Monorepo

> Easily run Apache Superset tests in the Bun monorepo with simple commands. Execute the full test suite or target specific packages efficiently.

- Repository: [Superset/superset](https://github.com/superset-sh/superset)
- Tags: how-to-guide
- Published: 2026-03-08

---

**Run `bun run test` from the repository root to execute the entire test suite across all workspaces, or use `bun test --filter=@superset/<workspace>` to target specific packages without switching directories.**

The `superset-sh/superset` repository is organized as a **Bun + Turbo monorepo** where all test suites are written with **Bun test**, a built-in test runner compatible with Vitest. Whether you are validating a single utility function or preparing a pull request, understanding how to run Apache Superset tests efficiently will save time and ensure CI consistency.

## Understanding the Testing Architecture

Superset’s testing infrastructure relies on **Bun** as both the runtime and test runner, replacing traditional Node.js and Jest setups. The **Turbo** pipeline orchestrates test execution across workspaces, enabling parallel runs and intelligent caching. Each workspace—whether an app in `apps/` or a package in `packages/`—defines its own test script in its local [`package.json`](https://github.com/superset-sh/superset/blob/main/package.json), ensuring modularity while maintaining a unified command interface at the root.

## Running Tests Across the Entire Repository

To validate the entire codebase, execute the test pipeline from the repository root:

```bash
bun run test

```

This command invokes **Turbo** as defined in `/package.json#L25`, where the root script `"test": "turbo test"` triggers every workspace’s test suite in parallel. The continuous integration pipeline uses this exact approach in `/.github/workflows/ci.yml#L82`, ensuring that local results match CI outcomes.

Alternatively, you can invoke Turbo directly:

```bash
turbo test

```

## Testing Individual Workspaces and Packages

When iterating on a specific module, running the entire suite is inefficient. Superset provides granular control through directory-specific commands and Turbo filters.

### Running Tests for a Specific Package

Navigate to the target workspace and execute Bun’s test runner directly:

```bash
cd packages/shared
bun test

```

Each package declares its test command in its local [`package.json`](https://github.com/superset-sh/superset/blob/main/package.json). For example, `/packages/shared/package.json#L39` specifies `"test": "bun test"`, which executes all `*.test.ts` files within that package’s directory tree.

### Using Turbo Filters for Targeted Testing

Remain in the root directory and use Turbo’s `--filter` flag to run tests for a specific workspace without changing directories:

```bash
bun test --filter=@superset/desktop

```

This command targets the workspace defined in `/apps/desktop/package.json#L35`, executing only the tests relevant to the desktop application. Filtering is particularly useful when working with interdependent packages, as Turbo automatically builds dependencies before running tests.

## Advanced Testing Workflows

### Running Specific Test Files

During debugging, isolate a single test file to reduce feedback time:

```bash
bun test packages/shared/src/auth/authorization.test.ts

```

This pattern works from any directory, provided you supply the correct relative path.

### Generating Coverage Reports

To analyze code coverage locally, append the coverage flag:

```bash
bun test --coverage

```

Bun writes the coverage report to the `coverage/` directory by default, generating HTML and LCOV outputs compatible with most CI visualization tools.

## CI/CD Integration

The repository’s GitHub Actions workflow ensures that every pull request passes the full test suite. The configuration in [`/.github/workflows/ci.yml`](https://github.com/superset-sh/superset/blob/main//.github/workflows/ci.yml) executes:

```yaml
- name: Run tests
  run: bun run test

```

This mirrors the local development command, eliminating "works on my machine" discrepancies. The workflow also runs `bun run lint` (using `/biome.jsonc` configuration) and type checking before the test stage, ensuring that only valid code reaches the test runner.

## Troubleshooting Common Issues

| Issue | Solution |
|-------|----------|
| **Flaky or unrelated test failures** | Isolate the relevant workspace using `--filter` to avoid noise from other packages, then investigate the specific failure. |
| **Missing dependencies** | Execute `bun install` after pulling new changes. The monorepo uses workspace hoisting, and a fresh install resolves inter-package links defined in `/turbo.jsonc`. |
| **TypeScript compilation errors** | Run `bun run typecheck` before testing. Many packages rely on generated types from Drizzle ORM that must be built first. |
| **Linting failures** | Run `bun run lint` to check against the Biome configuration in `/biome.jsonc`. The CI pipeline enforces linting before test execution. |

## Summary

- **Bun test** is the unified test runner for the entire Superset monorepo, replacing Jest or Vitest.
- Execute `bun run test` from the root to run all workspace tests via Turbo, matching the CI behavior in `/.github/workflows/ci.yml#L82`.
- Target specific packages with `bun test --filter=@superset/<workspace>` or by running `bun test` inside the package directory.
- Generate coverage reports with `bun test --coverage` and isolate specific files by passing their path directly to the command.

## Frequently Asked Questions

### What test runner does Apache Superset use?

The `superset-sh/superset` repository uses **Bun test**, a built-in test runner that is API-compatible with Vitest. This eliminates the need for separate test frameworks like Jest or Mocha and provides native TypeScript support without transpilation steps.

### How do I run tests for only one package in the Superset monorepo?

Navigate to the specific package directory and execute `bun test`, or remain in the root directory and use Turbo’s filter flag: `bun test --filter=@superset/<workspace>`. For example, `bun test --filter=@superset/shared` executes only the tests defined in `/packages/shared/package.json#L39`.

### Can I generate test coverage reports locally?

Yes. Append the `--coverage` flag to any test command: `bun test --coverage`. Bun generates an HTML report and LCOV data in the `coverage/` directory, allowing you to inspect line-by-line coverage for any workspace in the monorepo.

### Why are my tests failing in CI but passing locally?

Discrepancies usually stem from missing linting or type-checking steps. The CI pipeline in [`/.github/workflows/ci.yml`](https://github.com/superset-sh/superset/blob/main//.github/workflows/ci.yml) runs `bun run lint` (using `/biome.jsonc`) and type checks before executing tests. Ensure you run `bun install` after pulling changes, and execute `bun run typecheck` to validate generated types from Drizzle ORM before testing.