How to Run Apache Superset Tests in the Bun Monorepo

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, 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:

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:

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:

cd packages/shared
bun test

Each package declares its test command in its local 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:

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:

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:

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 executes:

- 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}