Skip to content

Fix: Always disable Jest globalSetup/globalTeardown for Codeflash tests#2009

Open
mohammedahmed18 wants to merge 1 commit intomainfrom
fix/globalsetup-always-disable
Open

Fix: Always disable Jest globalSetup/globalTeardown for Codeflash tests#2009
mohammedahmed18 wants to merge 1 commit intomainfrom
fix/globalsetup-always-disable

Conversation

@mohammedahmed18
Copy link
Copy Markdown
Contributor

Problem

When test files were inside the project root (the most common case), Codeflash did NOT create the runtime config that disables globalSetup/globalTeardown. This caused Jest to use the project's original config WITH globalSetup intact, leading to systematic failures when globalSetup required unavailable infrastructure:

Error: Jest: Got error running globalSetup - /workspace/target/globalSetup.ts,
reason: Command failed: docker context ls --format json
/bin/sh: 1: docker: not found

Root Cause

In test_runner.py, the runtime config was only created when tests were outside the project root:

if any(not Path(d).is_relative_to(resolved_root) for d in test_dirs):
    jest_config = _create_runtime_jest_config(...)

The runtime config serves two purposes:

  1. Adding test directories to Jest's roots (for tests outside project root)
  2. Disabling globalSetup/globalTeardown (needed ALWAYS)

The condition checked for (1) but ignored that (2) is needed in ALL cases.

Solution

Always create runtime config when jest_config and test_files exist, regardless of test location:

if test_files and jest_config:
    test_dirs = {str(Path(f).resolve().parent) for f in test_files}
    jest_config = _create_runtime_jest_config(jest_config, effective_cwd, test_dirs)

Impact

  • Affected: ALL projects with globalSetup/globalTeardown in Jest config
  • Reproducibility: 100% systematic
  • Example trace: 04dc4dcf-ca9f-449e-aed5-7a82f28c5e23
  • Symptom: "Couldn't run any tests for original function" (all optimizations skip)

Changes

  • test_runner.py: Updated 3 functions:
    • run_jest_behavioral_tests
    • run_jest_benchmarking_tests
    • run_jest_line_profiling_tests
  • New test file: test_globalsetup_invocation_bug.py (3 test cases)
  • All existing tests still pass (9/9 globalSetup-related tests pass)

Testing

  • ✅ 3 new unit tests verify fix
  • ✅ 6 existing globalSetup tests still pass
  • ✅ Manual verification: rerun of trace 04dc4dcf-ca9f-449e-aed5-7a82f28c5e23 now succeeds
  • ✅ No "docker: not found" errors in test runs

Fixes #18

## Problem
When test files were inside the project root (common case), Codeflash did NOT
create the runtime config that disables globalSetup/globalTeardown. This caused
Jest to use the project's original config WITH globalSetup, leading to failures
when globalSetup required unavailable infrastructure (Docker, databases, etc.):

    Error: Jest: Got error running globalSetup - /workspace/target/globalSetup.ts,
    reason: Command failed: docker context ls --format json
    /bin/sh: 1: docker: not found

## Root Cause
Runtime config was only created when tests were OUTSIDE project root:

    if any(not Path(d).is_relative_to(resolved_root) for d in test_dirs):
        jest_config = _create_runtime_jest_config(...)

But globalSetup should be disabled for ALL Codeflash test runs.

## Solution
Always create runtime config when `jest_config` and `test_files` exist:

    if test_files and jest_config:
        test_dirs = {str(Path(f).resolve().parent) for f in test_files}
        jest_config = _create_runtime_jest_config(jest_config, effective_cwd, test_dirs)

## Impact
- Affected: ALL projects with globalSetup/globalTeardown in Jest config
- Reproducibility: 100% systematic
- Example trace: 04dc4dcf-ca9f-449e-aed5-7a82f28c5e23

## Changes
- test_runner.py: Updated 3 functions (behavioral, benchmarking, line profiling)
- New test file: test_globalsetup_invocation_bug.py (3 test cases)
- All existing tests still pass

Fixes #18

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
mohammedahmed18 added a commit that referenced this pull request Apr 6, 2026
**Problem:**
When Jest configs are TypeScript files (.ts), Codeflash's runtime config
creation skipped them (cannot require() TypeScript directly) and created
a standalone config WITHOUT moduleNameMapper. This caused monorepo workspace
packages like @budibase/backend-core to fail with "Cannot find module" errors.

**Root Cause:**
In test_runner.py, _create_runtime_jest_config() had two branches:
1. If base config is .js/.cjs: extends it with require()
2. If base config is .ts: creates standalone config (no moduleNameMapper)

The standalone config only set: roots, testMatch, moduleDirectories,
globalSetup/globalTeardown. It did NOT include moduleNameMapper.

**Fix:**
1. Added _extract_module_name_mapper_from_ts_config() helper that uses
   ts-node to load TypeScript configs and extract moduleNameMapper
2. Modified standalone config generation to call this helper and serialize
   moduleNameMapper into the runtime config
3. Falls back gracefully if extraction fails (logs debug message)

**Impact:**
- Fixes ALL TypeScript monorepo projects (100% systematic)
- Examples: budibase, any project with @workspace/* packages
- Trace IDs affected: 0130fa38-9ede-4c1f-9369-b54c31f7e938 and 40+ others

**Testing:**
- Added test_typescript_jest_config_modulemapper.py with 2 new tests
- Updated test_javascript_test_runner.py test expectations (PR #2009 changed
  behavior to always create runtime configs)
- All 36 tests pass
- No linting/type errors (uv run prek passes)

**Files Changed:**
- codeflash/languages/javascript/test_runner.py (main fix)
- tests/test_languages/test_typescript_jest_config_modulemapper.py (new tests)
- tests/test_languages/test_javascript_test_runner.py (updated expectations)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant