test: trim redundant e2e tests, move pure logic to unit specs

[davidfirst]

This PR reduces the number of slow e2e tests. The work goes file by file. Each commit covers one e2e file.

• Remove e2e tests that a unit spec already covers.
• Remove e2e tests that repeat the same code path as a sibling test.
• Move tests of pure functions to unit specs. Example: main-file resolution now has a unit spec (determine-main-file.spec.ts) with 9 tests.
• Keep all tests that need a real workspace or scope.

Done so far: add.e2e.ts (24 to 13 tests), config.e2e.ts (13 to 11 tests). More commits will follow on this branch.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Tests: trim redundant add/config e2e coverage; add determineMainFile unit specs

🧪 Tests 🕐 10-20 Minutes

AI Description

• Remove redundant/overlapping e2e cases in bit add and bit config suites to reduce runtime.
• Add focused unit coverage for determineMainFile() main-file resolution strategies.
• Simplify e2e assertions where coverage is already exercised by remaining tests.

Diagram

graph TD
  E2EAdd(["e2e/commands/add.e2e.ts"]) --> CLI["bit CLI"] --> AddComp["AddComponents"] --> DMF["determineMainFile()"]
  E2EConfig(["e2e/commands/config.e2e.ts"]) --> CLI
  UnitSpec(["scopes/component/tracker/determine-main-file.spec.ts"]) --> DMF

Loading

High-Level Assessment

The approach is appropriate: keep e2e coverage for behaviors requiring a real workspace/CLI, and move deterministic strategy logic (main-file resolution) into fast unit specs to reduce suite time. Alternatives like keeping all scenarios as e2e or introducing a mid-level integration harness would be slower or add more framework surface area without clear benefit here.

Files changed (3) +87 / -110

Tests (3) +87 / -110

add.e2e.tsRemove redundant 'bit add' e2e cases (main-file + invalid id/name) +1/-88

Remove redundant 'bit add' e2e cases (main-file + invalid id/name)

• Drops multiple 'bit add' e2e tests that duplicate existing validation or are better covered at the logic level (e.g., missing main file, invalid name/id, multiple index-file main resolution, bitmap sorting). Simplifies the gitignore scenario by removing redundant output/bitmap presence assertions while keeping the key file-filtering check.

e2e/commands/add.e2e.ts

config.e2e.tsRemove 'bit config' git propagation e2e block +0/-22

Remove 'bit config' git propagation e2e block

• Eliminates the e2e suite section that validated config precedence/propagation via git config layers, keeping the remaining local workspace/scope config tests intact. This reduces slow/permission-sensitive git-dependent coverage.

e2e/commands/config.e2e.ts

determine-main-file.spec.tsAdd unit spec for 'determineMainFile()' resolution strategies +86/-0

Add unit spec for 'determineMainFile()' resolution strategies

• Introduces a dedicated unit test suite covering the main-file selection strategies: no-match error, single-file selection, closest index preference, immediate-dir filename fallback, Angular entry point, preservation of existing component-map mainFile, and user-specified main file behavior (present vs missing). This replaces several slower e2e scenarios with direct logic validation.

scopes/component/tracker/determine-main-file.spec.ts

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (2) 📜 Skill insights (0)

1. --override conflict coverage removed 📘 Rule violation ≡ Correctness ⭐ New

Description

The PR deletes the only real-workspace test proving import rejects a non-empty custom path and
succeeds with --override. This filesystem-sensitive branch cannot be covered by the surviving
nonexistent-path case, leaving necessary E2E behavior unverified.

Code

e2e/commands/import.e2e.ts[L193-195]

-          it('should import successfully if the --override flag is used', () => {
-            helper.command.runCmd(`bit import ${helper.scopes.remote}/global/simple -p my-custom-location --override`);
-            expect(componentFileLocation).to.be.a.file();

Evidence

Rule 2 requires retaining E2E tests for behavior that needs a real workspace. The deleted
command/assertion exercised the actual import, remote, and filesystem conflict flow, while
production separately rejects non-empty directories when throwForExistingDir is set and permits
the override path; the surviving custom-path test only covers a nonexistent destination.

CLAUDE.md: Prefer Unit Tests and Minimize Necessary E2E Tests
scopes/component/component-writer/component-writer.main.runtime.ts[340-357]
e2e/commands/import.e2e.ts[144-160]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The cleanup removes the only E2E coverage for importing into a non-empty custom path and retrying with `--override`.

## Issue Context
Production has a dedicated real-filesystem conflict branch for non-empty directories. Preserve one concise scenario that creates an occupied destination, verifies rejection without `--override`, and verifies success with it.

## Fix Focus Areas
- e2e/commands/import.e2e.ts[144-160]
- scopes/component/component-writer/component-writer.main.runtime.ts[340-357]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Remote exclusions now untested 📘 Rule violation ☼ Reliability

Description

Deleting all --remote exclusion cases leaves getRemoteIds() tested only with positive matching
and invalid input, while local exclusion tests do not exercise its dedicated negation-handling
branch. Regressions that fetch !scope/pattern as a remote, extract the wrong scope, or fail to
exclude matching IDs could therefore pass the suite.

Code

e2e/commands/pattern.e2e.ts[176]

-      const result = helper.command.pattern(`${scopeName}/utils/is/*, !${scopeName}/utils/is/type`, '--remote');

Evidence

Rule 2 requires effective, minimal E2E coverage for scenarios that genuinely need remote scopes. The
removed test passed both a positive and negated pattern to --remote, exercising production logic
that omits negations while determining which scopes to fetch and then applies the complete pattern
set when filtering fetched IDs; the surviving remote tests at lines 110-144 cover only positive **
matching and malformed input, so they do not prove this behavior.

CLAUDE.md: Prefer Minimal Unit Tests and Reserve E2E Tests for Genuine Cross-Command Scenarios: CLAUDE.md: Prefer Minimal Unit Tests and Reserve E2E Tests for Genuine Cross-Command Scenarios: CLAUDE.md: Prefer Minimal Unit Tests and Reserve E2E Tests for Genuine Cross-Command Scenarios: CLAUDE.md: Prefer Minimal Unit Tests and Reserve E2E Tests for Genuine Cross-Command Scenarios
scopes/workspace/workspace/pattern.cmd.ts[77-92]
e2e/commands/pattern.e2e.ts[110-122]
e2e/commands/pattern.e2e.ts[110-144]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Restore E2E coverage for exclusion patterns combined with `bit pattern --remote`; the remaining remote tests do not exercise negation handling in `getRemoteIds()`.
## Issue Context
The remote implementation has dedicated logic that removes negated patterns while extracting which remote scopes to fetch, then applies the complete pattern set when filtering IDs fetched from the remote pool. Keep one minimal, focused case proving that a positive remote pattern combined with a negated remote pattern fetches the correct scope and excludes the matching component.
## Fix Focus Areas
- e2e/commands/pattern.e2e.ts[175-180]
- scopes/workspace/workspace/pattern.cmd.ts[77-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Init bypass branches untested 🐞 Bug ⚙ Maintainability

Description

Removing the flag-specific interactive-mode tests leaves the explicit externalPackageManager,
standalone, and reset bypass conditions unverified in a Git repository. The surviving
--skip-interactive test cannot catch a regression where any of those separate flags stops
suppressing the prompt.

Code

e2e/commands/init.e2e.ts[L510-513]

-      it('should skip interactive mode with --external-package-manager flag', () => {
-        const output = helper.command.init('--external-package-manager', true);
-        expect(output).to.not.have.string('Interactive setup for existing Git repository');
-        expect(output).to.have.string('initialized a bit workspace');

Evidence

Production checks these flags as separate OR operands. The current interactive suite verifies only
--skip-interactive, while the other uses of --external-package-manager initialize workspaces
without establishing the Git-repository state needed to test this bypass.

scopes/harmony/host-initializer/init-cmd.ts[76-104]
e2e/commands/init.e2e.ts[424-435]
e2e/commands/init.e2e.ts[285-321]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Restore focused tests proving that each independently supported init flag bypasses interactive setup in an existing Git repository.
## Issue Context
`handleInteractiveMode()` has separate conditions for reset variants, `standalone`, `skipInteractive`, and `externalPackageManager`; testing only `--skip-interactive` does not cover the others.
## Fix Focus Areas
- e2e/commands/init.e2e.ts[510-527]
- scopes/harmony/host-initializer/init-cmd.ts[76-104]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Wildcard internalization becomes untested 🐞 Bug ⚙ Maintainability

Description

Deleting the only bit internalize '**' scenario leaves multi-match pattern resolution untested;
all surviving internalize calls use exact component names. A regression that resolves or updates
only one ID would therefore pass despite setByPattern() promising to internalize every ID returned
by idsByPattern().

Code

e2e/harmony/internalize.e2e.ts[L96-99]

-      helper.command.internalizeComponents('**');
-    });
-    it('should mark all matching components as internal', () => {
-      const list = helper.command.internalizeListParsed();

Evidence

The production path resolves an arbitrary pattern to an ID array and applies internalization to that
entire array. Every remaining E2E invocation passes comp1 or comp2, so none verifies a multi-ID
result.

scopes/component/internalize/internalize.main.runtime.ts[80-85]
e2e/harmony/internalize.e2e.ts[14-20]
e2e/harmony/internalize.e2e.ts[74-80]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Add a focused test that internalizes multiple components through one wildcard pattern and verifies every match is marked internal.
## Issue Context
Exact-name tests still cover basic internalization, but not propagation across all IDs returned for a glob.
## Fix Focus Areas
- e2e/harmony/internalize.e2e.ts[91-102]
- scopes/component/internalize/internalize.main.runtime.ts[80-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. History forms claim is false ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The new comment says the suite covers every history-diff argument form, but the rewritten tests
exercise only zero and one argument and never the distinct fromId toId branch. This misleading
coverage claim can hide regressions where explicit history-to-history comparison assigns or resolves
either endpoint incorrectly.

Code

e2e/harmony/lanes/lane-history-diff.e2e.ts[R15-16]

+   * Verifies that `bit reset` removes lane-history entries for the reset snaps, and that
+   * history-diff works over the resulting history in each of its argument forms.

Evidence

The current file contains no two-ID invocation despite the added 'each of its argument forms'
statement. Production separately maps two arguments to fromId and toId, while the tested
zero/one-argument forms use predecessor-selection logic.

e2e/harmony/lanes/lane-history-diff.e2e.ts[14-16]
e2e/harmony/lanes/lane-history-diff.e2e.ts[55-75]
scopes/lanes/diff/lane-history-diff.cmd.ts[55-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Make the new coverage claim accurate by adding a `bit lane history-diff <from-id> <to-id>` test, or narrow the comment if that form is intentionally outside this suite.
## Issue Context
Production handles two arguments in a separate branch rather than predecessor lookup.
## Fix Focus Areas
- e2e/harmony/lanes/lane-history-diff.e2e.ts[14-16]
- e2e/harmony/lanes/lane-history-diff.e2e.ts[55-75]
- scopes/lanes/diff/lane-history-diff.cmd.ts[55-76]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. Tilde snap coverage removed 🐞 Bug ⚙ Maintainability

Description

Deleting the ~ snap suite leaves only the ^ variant, although production handles ~ as a
separate accepted range-prefix value on the same snap-sensitive branches. A regression that writes
invalid ~ dependency ranges would now pass the suite.

Code

e2e/harmony/dependency-resolver.e2e.ts[L723-724]

-        helper.workspaceJsonc.addKeyValToDependencyResolver('componentRangePrefix', '~');
-        helper.command.snapAllComponents();

Evidence

The remaining snap range suite exercises only ^, while production explicitly branches on both ^
and ~ before deciding whether to add a range prefix; therefore the removed ~ scenario covers a
distinct supported input with no remaining assertion.

e2e/harmony/dependency-resolver.e2e.ts[643-675]
scopes/component/snapping/version-maker.ts[644-663]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Restore coverage ensuring `componentRangePrefix: '~'` is not applied to snap hashes in dependency metadata or generated package JSON.
## Issue Context
The remaining `^` tests do not cover the separately supported `~` configuration value.
## Fix Focus Areas
- e2e/harmony/dependency-resolver.e2e.ts[643-675]
- scopes/component/snapping/version-maker.ts[644-663]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. Pending-merge checkout untested 🐞 Bug ⚙ Maintainability

Description

Removing this scenario eliminates the only checkout test proving checkout --head rejects a
during-merge component without updating unrelated components. The checkout implementation has a
dedicated unmerged-component guard, but the remaining unit and lane checkout tests never exercise
it.

Code

e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[L108-113]

-    it('checkout head should stop with an error', () => {
-      expect(() => helper.command.checkoutHead('-x')).to.throw();
-    });
-    it('should not merged the head of other components', () => {
-      const comp3File = helper.fs.readFile('comp3/index.js');
-      expect(comp3File).to.not.include('v2');

Evidence

Checkout has an explicit repo.unmergedComponents early-return branch. The remaining checkout unit
spec covers only reset and ancestor checkout, and the shortened lane e2e file ends after ordinary
checkout behavior, leaving the during-merge guard and partial-update invariant uncovered.

scopes/component/checkout/checkout.main.runtime.ts[497-515]
scopes/component/checkout/checkout.spec.ts[21-90]
e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[50-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Restore an integration test that creates pending-merge state, runs checkout head, and verifies both rejection and no partial update of other components.
## Issue Context
This exercises checkout's dedicated unmerged-component guard and its all-components behavior; ordinary checkout tests are not equivalent.
## Fix Focus Areas
- e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[74-76]
- scopes/component/checkout/checkout.main.runtime.ts[497-515]
- scopes/component/checkout/checkout.spec.ts[21-90]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

8. Error details no longer tested ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The replacement no-main-file unit test accepts any MissingMainFile instance, so regressions that
report the wrong component ID, expected main-file pattern, file list, or user-facing message now
pass. The removed e2e assertion constructed the expected component-specific error, while production
still builds those details separately from the exception type.

Code

scopes/component/tracker/determine-main-file.spec.ts[22]

+      expect(() => determineMainFile(addedComponent, null)).to.throw(MissingMainFile);

Evidence

The production function independently assembles and passes three error arguments, and
MissingMainFile stores them and formats the displayed message. A class-only assertion cannot
detect incorrect values in any of those paths.

scopes/component/tracker/determine-main-file.ts[38-43]
components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]
scopes/component/tracker/determine-main-file.spec.ts[18-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The replacement unit test verifies only the `MissingMainFile` class, losing coverage of the component-specific error details that the removed e2e test checked.
## Issue Context
`determineMainFile()` supplies the component ID, expected main-file pattern, and candidate files to `MissingMainFile`; these values determine its user-facing message.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[18-23]
- scopes/component/tracker/determine-main-file.ts[38-43]
- components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

9. Depth validation branch untested ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The renamed test claims to cover any non-positive-integer depth but still passes only 0, so it
exercises the < 1 branch while the distinct Number.isInteger() rejection for abc and 1.5 now
has no test. A regression that accepts nonnumeric or fractional depths would therefore pass this
suite despite violating the command contract.

Code

e2e/commands/import.e2e.ts[R483-486]

+      it('should error when --dependencies-depth is not a positive integer', () => {
const output = helper.general.runWithTryCatch(
`bit import ${helper.scopes.remote}/comp1 --dependencies --dependencies-depth 0`
);

Evidence

The remaining test invokes only depth 0, whereas command parsing has a separate
Number.isInteger() condition needed to reject both NaN from abc and fractional values such as
1.5; the PR deleted the only shown cases exercising those inputs.

e2e/commands/import.e2e.ts[483-488]
scopes/scope/importer/import.cmd.ts[324-331]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The consolidated dependencies-depth test only supplies zero, leaving the non-integer validation path uncovered while claiming all invalid positive-integer inputs are tested.
## Issue Context
`ImportCmd.report()` converts the option with `Number()` and rejects it using two distinct checks: `!Number.isInteger(...)` and `< 1`. Keep zero coverage and add at least one non-integer input (preferably both nonnumeric and fractional cases), either here or in a focused unit spec for the parser.
## Fix Focus Areas
- e2e/commands/import.e2e.ts[483-488]
- scopes/scope/importer/import.cmd.ts[324-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

10. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]

+    peerDependencies:
+      chai: 5.2.1

Evidence

The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.

scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 23f127b

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit c9b3b48

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit d064888

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 8d4db88

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit d15dbd2

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit ec76886

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 0b6f4b3

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 42014fb

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 1b4ccc3

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 0e39945

[qodo-free-for-open-source-projects]

1. --override conflict coverage removed 📘 Rule violation ≡ Correctness

The PR deletes the only real-workspace test proving import rejects a non-empty custom path and
succeeds with --override. This filesystem-sensitive branch cannot be covered by the surviving
nonexistent-path case, leaving necessary E2E behavior unverified.

Agent Prompt

## Issue description
The cleanup removes the only E2E coverage for importing into a non-empty custom path and retrying with `--override`.

## Issue Context
Production has a dedicated real-filesystem conflict branch for non-empty directories. Preserve one concise scenario that creates an occupied destination, verifies rejection without `--override`, and verifies success with it.

## Fix Focus Areas
- e2e/commands/import.e2e.ts[144-160]
- scopes/component/component-writer/component-writer.main.runtime.ts[340-357]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 2e3b3cf