test: trim redundant e2e tests, move pure logic to unit specs - #10651
davidfirst wants to merge 110 commits into
Conversation
PR Summary by QodoTests: trim redundant add/config e2e coverage; add determineMainFile unit specs
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
1. Custom-path imports lose coverage
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
|
Code review by qodo was updated up to the latest commit 23f127b |
|
Code review by qodo was updated up to the latest commit c9b3b48 |
|
Code review by qodo was updated up to the latest commit d064888 |
|
Code review by qodo was updated up to the latest commit 8d4db88 |
|
Code review by qodo was updated up to the latest commit d15dbd2 |
|
Code review by qodo was updated up to the latest commit ec76886 |
|
Code review by qodo was updated up to the latest commit 0b6f4b3 |
|
Code review by qodo was updated up to the latest commit 42014fb |
| it('should not install a package "undefined" ', () => { | ||
| expect(path.join(helper.scopes.localPath, 'node_modules/undefined')).to.not.be.a.path; | ||
| }); | ||
| describe('after importing the file', () => { | ||
| before(() => { | ||
| helper.scopeHelper.reInitWorkspace(); |
There was a problem hiding this comment.
15. Binary exports can create an undefined package 🐞 Bug ≡ Correctness
The binary export scenario no longer checks that the export operation leaves node_modules/undefined absent. Its remaining assertions only verify remote listing output and PNG byte preservation, so a dependency-resolution regression that creates that bogus package after export reaches the workspace without failing this suite.
Agent Prompt
## Issue description
Restore the active export regression check that verifies a binary component export does not create `node_modules/undefined` in the workspace.
## Fix Focus Areas
- e2e/functionalities/binary-files.e2e.ts[23-52]
## Recommended Fix
After the binary-plus-JavaScript export setup, reintroduce an assertion that `path.join(helper.scopes.localPath, 'node_modules/undefined')` does not exist. Keep it in this scenario so the export cleanup path remains covered.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| expect(comp1.devPackageDependencies).to.be.an('object').that.has.property('chai'); | ||
| }); | ||
| it('should not save "chai" in the packages', () => { | ||
| expect(comp1.packageDependencies).to.be.an('object').that.is.empty; | ||
| }); | ||
| it('should not save anything into dependencies', () => { | ||
| expect(comp1.dependencies).to.be.an('array').that.is.empty; | ||
| }); | ||
| it('should save the flattened dev-dependencies into flattened-dependencies', () => { | ||
| expect(comp1.flattenedDependencies).to.be.an('array').with.lengthOf(2); | ||
| }); | ||
| it('bit status should not show any component as modified', () => { |
There was a problem hiding this comment.
16. Test-only packages can be classified as runtime 🐞 Bug ≡ Correctness
The "without dependencies and with dev-dependencies" case no longer checks comp1.devPackageDependencies for chai or verifies that comp1.packageDependencies is empty. It creates chai usage only in foo.spec.js, so an analyzer regression that records that package as a runtime dependency still satisfies the remaining component and flattened-dependency assertions.
Agent Prompt
## Issue description
Restore assertions that distinguish the package required solely from a test file from runtime package dependencies.
## Fix Focus Areas
- e2e/functionalities/dev-dependencies.e2e.ts[55-95]
## Recommended Fix
In the "without dependencies and with dev-dependencies" scenario, assert that `chai` exists in `comp1.devPackageDependencies` and that `comp1.packageDependencies` is empty, alongside the retained component dependency assertions.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| it('adds peer dependency to the generated package.json', () => { | ||
| const pkgJson = fs.readJsonSync( | ||
| path.join(workspaceCapsulesRootDir, `${helper.scopes.remote}_comp1/package.json`) | ||
| ); | ||
| expect(pkgJson.peerDependencies).to.deep.equal({ | ||
| [`@${helper.scopes.remote}/comp2`]: '^0.0.1-new', | ||
| }); | ||
| }); | ||
| describe('peer dependency is not broken after snap', () => { | ||
| before(() => { | ||
| helper.command.snapAllComponents(); | ||
| helper.command.build(); | ||
| workspaceCapsulesRootDir = helper.command.capsuleListParsed().workspaceCapsulesRootDir; | ||
| }); | ||
| it('should save the peer dependency in the model', () => { |
There was a problem hiding this comment.
17. Prefix peer ranges can produce invalid capsules 🐞 Bug ≡ Correctness
The prefix-range setPeer('comp2', '^') flow still builds capsules before and after snapping, but
the PR deletes both generated package.json assertions. The retained assertions inspect model and
scope dependency metadata only, whereas capsule generation must normalize the unsnapped ^0.0.1-new
range and the snapped prerelease range for a package manifest.
Agent Prompt
## Issue description
Restore capsule manifest assertions for peer dependencies configured with the `^` range prefix, both before and after snapping.
## Fix Focus Areas
- e2e/functionalities/peer-dependency-component.e2e.ts[120-183]
## Recommended Fix
Capture the workspace capsule root after each build in the prefix-range scenario and assert that the relevant generated component `package.json` has the expected peer dependency range before snapping and after snapping. Preserve the existing model and scope assertions.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| it('any bit command should not throw', () => { | ||
| expect(() => helper.command.status()).to.not.throw(); | ||
| }); | ||
| it('bit show should show the correct env', () => { | ||
| const env = helper.env.getComponentEnv('comp1'); | ||
| expect(env).to.equal(`${envId}@0.0.2`); |
There was a problem hiding this comment.
1. Status can regress for mismatched envs 🐞 Bug ⚙ Maintainability
The version-mismatch scenario removes its helper.command.status() assertion and now exercises only environment resolution and bit show. When a component references an older env version in its model while the workspace has a newer version, status-specific extension loading can fail without reaching either remaining assertion.
Agent Prompt
Issue description
The custom-env version-mismatch scenario must continue to execute `bit status`, because its extension-loading path is distinct from the remaining `bit show` and environment-resolution checks.
Fix Focus Areas
- e2e/harmony/custom-env-operations.e2e.ts[53-78]
Recommended Fix
Add back an assertion in this scenario that invokes `helper.command.status()` and verifies it does not throw, retaining the existing assertions for the resolved workspace env version and the absence of the stale model version.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| helper.scopeHelper.reInitWorkspace(); | ||
| helper.fixtures.populateComponents(2); | ||
| helper.workspaceJsonc.addKeyValToDependencyResolver('componentRangePrefix', '~'); | ||
| helper.command.snapAllComponents(); |
There was a problem hiding this comment.
2. Snap package manifests can become invalid 🐞 Bug ⚙ Maintainability
The deleted ~ prefix suite was the only test that snaps components with `componentRangePrefix: '~'` and verifies that hash versions do not receive that prefix in dependency data or generated package metadata. The remaining snap suite configures only ^, while the versioning code handles ^ and ~ as separate supported values in the conditions that must exclude snap versions.
Agent Prompt
Issue description
Snap versions must remain unprefixed when the component range configuration is `~`; this configuration is supported and has a distinct input branch from the surviving `^` scenario.
Fix Focus Areas
- e2e/harmony/dependency-resolver.e2e.ts[643-676]
Recommended Fix
Restore a `componentRangePrefix: '~'` snap scenario that asserts both dependency resolver data and the generated package manifest omit `~` from hash-version dependencies, alongside the existing caret-prefix coverage.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| const output = helper.command.mergeLane('dev', '--build --no-squash'); | ||
| expect(output).to.have.string('Total Snapped: 0'); | ||
| }); | ||
| it('should succeed despite test failures', () => { |
There was a problem hiding this comment.
20. Failed merges can create snaps unnoticed 🐞 Bug ≡ Correctness
The PR deletes the non---loose mergeLane('dev', '--build --no-squash') assertion that a failing
Jest task reports Total Snapped: 0. The surviving scenario invokes only --build --loose, while
the cited replacement injects a missing dependency and checks only .bitmap, so a tester failure
that incorrectly creates a merge snap is no longer detected.
Agent Prompt
Issue description
The non-loose `--build` merge path no longer verifies that a failing Jest task prevents creation of a merge snap. The retained `--loose` case proves the opposite behavior and the purported sibling replacement uses a different failure mechanism.
Fix Focus Areas
- e2e/harmony/lanes/merge-lanes-edge-cases-2.e2e.ts[414-443]
- e2e/harmony/lanes/merge-lanes-edge-cases.e2e.ts[40-58]
Recommended Fix
Add back a non-`--loose` merge execution using the existing failing-Jest setup and assert that it reports zero snaps (and, preferably, leaves the component head unchanged). Keep the `--loose` run isolated through a workspace clone so both flag behaviors execute from identical histories.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| describe('creating a new lane without any component', () => { | ||
| let output; | ||
| before(() => { | ||
| helper.scopeHelper.reInitWorkspace({ addRemoteScopeAsDefaultScope: false }); |
There was a problem hiding this comment.
23. Lanes without remote defaults go untested 🐞 Bug ⚙ Maintainability
Changing reInitWorkspace({ addRemoteScopeAsDefaultScope: false }) to reInitWorkspace() replaces
the local-default lane-creation case with the standard remote-default case. Lane creation derives
its tracking scope from workspace.defaultScope, so the suite no longer verifies that an empty lane
is correctly created and displayed when that scope remains the workspace's local my-scope value.
Agent Prompt
## Issue description
Preserve a lane-creation test for workspaces whose default scope is not switched to the configured remote scope. This setup exercises a distinct tracking-scope resolution path from the standard remote-default setup.
## Fix Focus Areas
- e2e/harmony/lanes/lane-basic-operations.e2e.ts[19-32]
## Recommended Fix
Add a separate scenario that calls `reInitWorkspace({ addRemoteScopeAsDefaultScope: false })`, creates a lane without an explicit `--scope`, and asserts that the active lane and its tracking data use `my-scope/dev`. Keep the consolidated remote-default scenario for default remote tracking behavior.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| expect(peerDep.version).to.eq(head); | ||
| expect(peerDep.versionRange).to.eq('0'); | ||
| }); | ||
| it('adds peer dependency to the generated package.json', () => { |
There was a problem hiding this comment.
18. Existing components can omit peer manifests 🐞 Bug ≡ Correctness
The existing-component scenario snaps both components before calling setPeer('comp2', '0'), but
its only generated capsule package.json assertion was removed. The remaining test validates model
references to the pre-existing head, so a build that persists that model data but omits or miswrites
the peer dependency in the capsule manifest is no longer detected.
Agent Prompt
## Issue description
Restore the generated capsule package assertion for setting a peer dependency after the components already have snaps.
## Fix Focus Areas
- e2e/functionalities/peer-dependency-component.e2e.ts[187-222]
## Recommended Fix
Capture the capsule root after the build in the existing-component scenario, read comp1's versioned capsule `package.json`, and assert that its `peerDependencies` contains comp2 with range `0`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| }); | ||
| describe('import with --path flag', () => { | ||
| before(() => { | ||
| helper.scopeHelper.reInitWorkspace(); |
There was a problem hiding this comment.
19. Package imports can ignore custom paths 🐞 Bug ⚙ Maintainability
The deleted import with --path flag scenario ran importComponentWithOptions() after a fresh workspace was configured with the custom resolver, while the new assertion runs only against a workspace with its remote explicitly added. When imports are resolved through that resolver for TypeScript components, no remaining test combines that route with --path, so regressions in its destination-directory or bitmap update behavior are not detected.
Agent Prompt
Issue description
The replacement `--path` test covers a locally configured remote, but the removed test was the only one that used `--path` after `NpmCiRegistry.setResolver()` in the TypeScript-component flow.
Fix Focus Areas
- e2e/harmony/import-harmony.e2e.ts[17-25]
- e2e/harmony/import-harmony.e2e.ts[57-72]
- e2e/harmony/import-harmony.e2e.ts[317-322]
Recommended Fix
Retain or add a compact test in the resolver-backed TypeScript import flow that imports `comp1` with `-p src` and asserts both that `src` exists and that the bitmap entry has `rootDir: 'src'`. The local-remote test may remain as shared coverage, but it should not replace this distinct resolution route.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
|
||
| helper.scopeHelper.reInitWorkspace(); | ||
| helper.scopeHelper.addRemoteScope(); | ||
| helper.command.importLane('lane-b'); |
There was a problem hiding this comment.
21. Remote merges can lose new files unnoticed 🐞 Bug ≡ Correctness
The deleted diverged-lane test was the only one that added comp1/new-file.ts on an exported source lane, reinitialized the workspace, imported the target lane, and merged the source through its remote lane ID. The remaining new-file test merges a locally available lane, and the remaining remote merge only validates pre-existing component files, so remote object transfer and materialization of lane-only files no longer have an end-to-end assertion.
Agent Prompt
Issue description
The remote merge path no longer verifies that a file introduced only by a divergent exported lane is fetched and written after the destination lane is imported into a fresh workspace. Local merge coverage does not exercise the remote lane transport path.
Fix Focus Areas
- e2e/harmony/lanes/merge-lanes-diverge.e2e.ts[108-132]
- e2e/harmony/lanes/diverged-from-forked.e2e.ts[23-63]
- e2e/harmony/lanes/merge-lanes-remote.e2e.ts[29-42]
Recommended Fix
Restore a focused scenario that creates and exports a lane-only file, reinitializes the workspace, imports the target lane, merges the source using its remote lane ID, and asserts that the new file exists. It can share setup with another remote merge case, but must retain the fresh-workspace remote merge step.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
|
||
| helper.scopeHelper.getClonedWorkspace(originalWs); | ||
| }); | ||
| it('checkout head should stop with an error', () => { |
There was a problem hiding this comment.
22. Pending merges can update other files 🐞 Bug ≡ Correctness
Deleting the active pending-merge scenario removes the only assertion that checkoutHead('-x')
leaves an unrelated component's working-tree content unchanged after rejecting the checkout. The
surviving scenario checks only bitmap versions after a different two-component setup, so a partial
checkout that writes another component before detecting a merge-pending component is no longer
caught.
Agent Prompt
## Issue description
Restore coverage for `bit checkout head` in a workspace containing both a merge-pending component and a separately advanced component. The command must fail without materializing the other component's newer remote content.
## Fix Focus Areas
- e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[78-115]
## Recommended Fix
Reintroduce the deleted cross-workspace pending-merge setup, or add an equivalent scenario. Advance a non-pending component in another workspace, run `checkoutHead('-x')` from the workspace with the pending merge, assert it throws, and assert that component's file still has its pre-checkout content.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| expect(result).to.include('found 2 components'); | ||
| }); | ||
|
|
||
| it('should support exclusion patterns from remote', () => { |
There was a problem hiding this comment.
3. Remote pattern exclusions can regress unnoticed 🐞 Bug ⚙ Maintainability
The deleted remote tests are the only ones that invoke bit pattern --remote with negated exact and wildcard patterns. Remote matching first excludes negations while selecting remote scopes and only then applies them to the fetched ID pool, whereas the surviving negation tests use the separate local workspace path.
Agent Prompt
## Issue description
Remote exclusion patterns have a distinct fetch-then-filter implementation path and are no longer exercised by an end-to-end test.
## Fix Focus Areas
- e2e/commands/pattern.e2e.ts[175-187]
## Recommended Fix
Restore an active `--remote` test that includes a positive scoped pattern plus an exact negated pattern, and retain or add a wildcard-negation case. Assert that excluded remote IDs are absent and the expected remaining IDs/count are returned.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| ); | ||
| expect(output).to.have.string('positive integer'); | ||
| }); | ||
| it('should error when --dependencies-depth is a fractional number', () => { |
There was a problem hiding this comment.
4. Fractional depth validation loses coverage 🐞 Bug ⚙ Maintainability
The consolidated validation test retains zero and nonnumeric values but deletes the 1.5 invocation of --dependencies-depth. The command converts the supplied string with Number() and rejects it through Number.isInteger(), so a regression accepting fractional numeric values is not exercised by the surviving cases.
Agent Prompt
## Issue description
The validation suite no longer verifies rejection of a numeric fractional dependency depth.
## Fix Focus Areas
- e2e/commands/import.e2e.ts[483-493]
## Recommended Fix
Add `--dependencies-depth 1.5` to the consolidated positive-integer validation test and assert that its output contains `positive integer`, alongside the zero and nonnumeric cases.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit d24db40 |
resolvePackageNameByPath is pure, so the whole e2e file is replaced by cases in resolve-pkg-name-by-path.spec.ts, which also covers previously untested branches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| it('should save "chai" in the dev-packages', () => { | ||
| expect(comp1.devPackageDependencies).to.be.an('object').that.has.property('chai'); | ||
| }); | ||
| it('should not save "chai" in the packages', () => { | ||
| expect(comp1.packageDependencies).to.be.an('object').that.is.empty; | ||
| }); | ||
| it('should not save anything into dependencies', () => { | ||
| expect(comp1.dependencies).to.be.an('array').that.is.empty; | ||
| }); |
There was a problem hiding this comment.
16. Dev packages can be misclassified 🐞 Bug ≡ Correctness
The consolidated dev-dependency scenario removes assertions that chai appears in devPackageDependencies and not in packageDependencies. Its remaining checks cover component dependency arrays only, so package imports from test files can enter the regular-package bucket without failing this suite.
Agent Prompt
## Issue description
The surviving test no longer verifies that an npm package imported exclusively by a test file is classified as a development package rather than a regular package.
## Fix Focus Areas
- e2e/functionalities/dev-dependencies.e2e.ts[76-94]
- scopes/dependencies/dependencies/dependencies-loader/auto-detect-deps.ts[475-493]
## Recommended Fix
Add both classification assertions to the consolidated test: require `chai` in `devPackageDependencies` and require it to be absent from `packageDependencies`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| it('adds peer dependency to the generated package.json', () => { | ||
| const pkgJson = fs.readJsonSync( | ||
| path.join(workspaceCapsulesRootDir, `${helper.scopes.remote}_comp1/package.json`) | ||
| ); | ||
| expect(pkgJson.peerDependencies).to.deep.equal({ | ||
| [`@${helper.scopes.remote}/comp2`]: '^0.0.1-new', | ||
| }); | ||
| }); | ||
| describe('peer dependency is not broken after snap', () => { | ||
| before(() => { | ||
| helper.command.snapAllComponents(); | ||
| helper.command.build(); | ||
| workspaceCapsulesRootDir = helper.command.capsuleListParsed().workspaceCapsulesRootDir; | ||
| }); | ||
| it('should save the peer dependency in the model', () => { |
There was a problem hiding this comment.
17. Peer manifests can omit dependencies 🐞 Bug ≡ Correctness
The deleted capsule assertions were the only checks that component peer dependencies are emitted into generated package.json files. The surviving model assertions bypass manifest conversion, so capsules can retain correct scope metadata while exposing an incorrect or missing peer dependency to package consumers.
Agent Prompt
## Issue description
Model-level peer dependency assertions do not verify the separate conversion into generated capsule package manifests.
## Fix Focus Areas
- e2e/functionalities/peer-dependency-component.e2e.ts[127-161]
- scopes/dependencies/dependency-resolver/dependencies/dependency-list.ts[155-176]
## Recommended Fix
Keep one focused assertion that builds a capsule, reads its generated package.json, and verifies the component dependency appears under peerDependencies with the expected range.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| @@ -227,12 +211,10 @@ describe('compile extension', function () { | |||
| helper.command.setEnv('comp1', EMPTY_ENV); | |||
There was a problem hiding this comment.
19. Multiple directory compilation loses coverage 🐞 Bug ☼ Reliability
The removed compile case is the only scenario that supplies two component root-directory paths in one command invocation. The retained mixed-input test combines one directory with an ID instead, leaving multi-directory parsing and component selection unverified.
Agent Prompt
Issue description
Compilation with multiple root-directory arguments is no longer tested, although it is a distinct command-input form from a directory plus component ID.
Fix Focus Areas
- e2e/harmony/compile.e2e.ts[185-204]
Recommended Fix
Restore a test that invokes compile with `nested/comp1 nested/comp2` and asserts both components are selected and compiled.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| helper.fs.createFile('bar', file1); | ||
| helper.fs.createFile('bar', file2); | ||
|
|
||
| const addCmd = () => helper.command.addComponent('bar', { n: 'test' }); |
There was a problem hiding this comment.
15. Adding unresolved components goes untested 🐞 Bug ≡ Correctness
The deleted bit add scenario was the only integration test for automatic main-file resolution exhausting every strategy and throwing MissingMainFile. The new unit suite checks a missing user-specified file but not the default unresolved case or its propagation through the add command.
Agent Prompt
## Issue description
The replacement unit suite does not cover failure after automatic main-file resolution exhausts every strategy, and no command test now verifies that error propagation.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[108-115]
- e2e/commands/add.e2e.ts[72-82]
## Recommended Fix
Add a unit case with multiple files, no explicit main file, and no recognized index or directory-named file, asserting `MissingMainFile`. Retain a focused command-level assertion if propagation through `bit add` is not covered elsewhere.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| expect(output).to.have.string('initialized a bit workspace'); | ||
| }); | ||
|
|
||
| it('should skip interactive mode with --external-package-manager flag', () => { |
There was a problem hiding this comment.
18. Flagged initialization can still prompt 🐞 Bug ☼ Reliability
The deleted initialization cases were the only tests proving that external-package-manager, standalone, and reset modes bypass runInteractiveMode(). These flags reach an explicit short-circuit in the command, and a regression there can make scripted initialization wait for interactive input.
Agent Prompt
## Issue description
Initialization flags intended for scripted operation no longer have coverage proving that they bypass the interactive setup path.
## Fix Focus Areas
- e2e/commands/init.e2e.ts[510-527]
- scopes/harmony/host-initializer/init-cmd.ts[76-125]
## Recommended Fix
Retain a parameterized test for the external-package-manager, standalone, and reset options. Assert that each invocation completes successfully without emitting or entering interactive setup.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| expect(componentFileLocation).to.be.a.file(); | ||
| }); | ||
| }); | ||
| describe('when the destination is an existing empty directory', () => { |
There was a problem hiding this comment.
1. Custom-path imports lose coverage 🐞 Bug ☼ Reliability
The deleted bit import --path destination suite was the only command-level coverage for successful writes to an empty directory, rejection and content preservation for a non-empty directory, overwrite behavior with --override, and rejection when the target is an existing file. These cases reach separate component-writer conflict branches from the surviving non-existent-destination test, so regressions in destination handling and safeguards against overwriting user files no longer fail an integration test.
Agent Prompt
## Issue description
The `bit import --path` destination scenarios were removed even though empty directories, occupied directories, existing file targets, and override behavior follow distinct component-writer paths. Command-level coverage should verify both successful destination handling and safeguards that preserve existing user content.
## Fix Focus Areas
- e2e/commands/import.e2e.ts[160-223]
- scopes/component/component-writer/component-writer.main.runtime.ts[333-358]
## Recommended Fix
Restore focused destination tests that verify import into an empty directory, rejection of a non-empty destination without deleting or changing its existing content, successful replacement of a directory with `--override`, and rejection when the destination is a file both with and without `--override`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| // Note: getClonedWorkspace destroys the current dir and restores from the snapshot, | ||
| // so each runAsFirstCommand call starts fresh from the same pre-CI state. | ||
|
|
||
| it('`bit status` as first command syncs bitmap', () => { |
There was a problem hiding this comment.
20. Status no longer checks automatic sync 🐞 Bug ☼ Reliability
The PR deletes the first-command scenario that invokes helper.command.status() after the CI merge. The retained first-command tests cover list, show, log, and compile, so a status-specific failure to trigger bitmap synchronization is no longer detected.
Agent Prompt
Issue description
The suite no longer verifies that status triggers bitmap synchronization when it is the first Bit command after the CI merge.
Fix Focus Areas
- e2e/harmony/ci-bitmap-auto-sync.e2e.ts[340-372]
Recommended Fix
Restore the first-command status test using `runAsFirstCommand(() => helper.command.status())` and assert the bitmap records version `0.0.2`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| helper.scopeHelper.addRemoteScope(); | ||
| helper.command.importLane('dev'); | ||
|
|
||
| helper.fs.outputFile(`${helper.scopes.remote}/comp3/index.js`, 'console.log("v2");'); |
There was a problem hiding this comment.
21. Pending merges can update other components 🐞 Bug ☼ Reliability
The deleted pending-merge scenario uniquely creates a pending merge through a main-to-lane merge and then publishes a changed unrelated component from another workspace before calling checkout. The retained test only compares component heads after a different import-based setup, so it no longer verifies that checkout leaves an unrelated component's files untouched when it aborts.
Agent Prompt
Issue description
Checkout failure with a pending merge is no longer tested when another component has a newly published remote file revision.
Fix Focus Areas
- e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[78-115]
- e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[15-45]
Recommended Fix
Restore the scenario that creates a pending merge for one component, exports a changed unrelated component from a second workspace, runs checkout, and asserts the unrelated workspace file was not updated.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| }); | ||
| describe('rename lane using the alias', () => { | ||
| before(() => { | ||
| helper.scopeHelper.setWorkspaceWithRemoteScope(); |
There was a problem hiding this comment.
22. Aliased lane renames lose coverage 🐞 Bug ☼ Reliability
The deleted test creates and exports a lane with --alias before renaming it, whereas the purported replacement creates an ordinary lane. Alias creation is otherwise only exercised when switching to remote lanes, so a rename regression involving alias-backed lane state is no longer covered.
Agent Prompt
Issue description
Renaming an exported lane created with an alias is no longer tested; the retained exported-lane test does not use an alias.
Fix Focus Areas
- e2e/harmony/lanes/rename-lane.e2e.ts[16-33]
- e2e/harmony/lanes/lane-management.e2e.ts[18-52]
Recommended Fix
Restore the aliased-lane scenario: create `dev` with `--alias d`, snap and export it, rename it, then assert status succeeds and `.bitmap` contains the new lane name.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit a244936 |
# Conflicts: # .circleci/config.yml
…tester-spec-files Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
||
| helper.scopeHelper.getClonedWorkspace(originalWs); | ||
| }); | ||
| it('checkout head should stop with an error', () => { |
There was a problem hiding this comment.
14. Forced checkout can update unrelated components 🐞 Bug ☼ Reliability
The deleted pending-merge scenario was the only one to call checkoutHead('-x') after a
merge-pending component was created and to verify that another component did not advance. The
surviving pending-merge setup invokes checkoutHead() without the force flag, while its only forced
checkout scenario has no merge-pending component, so the force-specific safeguard is no longer
exercised.
Agent Prompt
Issue description
The forced `checkoutHead('-x')` path is no longer tested when a workspace contains a merge-pending component. Preserve the assertion that the command fails and does not advance an unrelated component.
Fix Focus Areas
- e2e/harmony/lanes/bit-checkout-on-lanes.e2e.ts[78-115]
Recommended Fix
Restore the deleted pending-merge setup and assertions, or add an equivalent isolated scenario that invokes `checkoutHead('-x')`, expects the merge-pending failure, and verifies that the unrelated component remains at its original revision.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| helper.fs.deletePath('comp1/foo.js'); | ||
| helper.command.snapAllComponentsWithoutBuild(); | ||
| helper.command.export(); | ||
| helper.command.switchLocalLane('main', '-x'); |
There was a problem hiding this comment.
15. Fast-forward merges can retain deleted files 🐞 Bug ≡ Correctness
The PR deletes the only scenario in merge-lanes-edge-cases.e2e.ts that merges a lane containing a file deletion into unchanged main, which exercises direct remote-component application without three-way results. Because the retained scenario creates a new main tag before merging, it covers only the diverged three-way path, allowing obsolete workspace files left by fast-forward merges to escape the suite.
Agent Prompt
## Issue description
The cleanup removes the only integration scenario verifying that a fast-forward lane merge deletes files removed on the source lane. The retained scenario deliberately diverges main before merging and therefore exercises the separate three-way merge path, which cannot cover regressions in direct remote-component application.
## Fix Focus Areas
- e2e/harmony/lanes/merge-lanes-edge-cases.e2e.ts[379-405]
## Recommended Fix
Restore an isolated non-diverged integration scenario: leave main at the common base, remove and snap the file on the source lane, switch to unchanged main, merge the lane, and verify both the removal status in the command output and the file's absence from the workspace.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| }); | ||
| }); | ||
|
|
||
| describe('when no components in workspace', () => { |
There was a problem hiding this comment.
16. Empty workspace searches can misreport results 🐞 Bug ≡ Correctness
The deleted when no components in workspace block was the only command test that reinitialized an empty workspace before invoking local-only search. All surviving search cases populate and tag components first, even though SearchCmd.report() has a dedicated zero-local-results rendering branch for workspaces.
Agent Prompt
Issue description
The suite no longer executes `bit search --local-only` in an empty workspace. Preserve a test for the empty-workspace local output path.
Fix Focus Areas
- e2e/commands/search.e2e.ts[73-80]
Recommended Fix
Add a separate describe that reinitializes an empty workspace, runs `bit search anything --local-only`, and asserts that the local no-match message is rendered.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| const statusOutput = helper.command.runCmd('bit status'); | ||
| expect(statusOutput).to.have.string('modified components'); | ||
| }); | ||
| it('should update bitmap with the imported version', () => { |
There was a problem hiding this comment.
17. Manual merges can retain the old version 🐞 Bug ≡ Correctness
The PR removes the bitmap-version assertion from the manual conflict merge branch, leaving that branch checked only for conflict markers and modified status. A manual merge can therefore leave comp2 recorded at its prior revision while still satisfying every remaining assertion in that branch.
Agent Prompt
Issue description
The manual merge scenario no longer verifies that importing revision `0.0.2` updates the component revision stored in the bitmap. Keep this bookkeeping assertion alongside the conflict-content checks.
Fix Focus Areas
- e2e/functionalities/merge.e2e.ts[111-114]
Recommended Fix
After the manual merge completes, read the bitmap and assert that `comp2.version` equals the imported version. Keep the assertion specific to the manual conflict strategy.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| expect(peerDep.version).to.eq('latest'); | ||
| expect(peerDep.versionRange).to.eq('^0.0.1-new'); | ||
| }); | ||
| it('adds peer dependency to the generated package.json', () => { |
There was a problem hiding this comment.
18. Built packages can omit peer dependencies 🐞 Bug ≡ Correctness
The PR deletes the capsule package.json assertions after setPeer('comp2', '^') and after the
subsequent snap, leaving only model and scope metadata checks. Capsule manifest generation
separately maps dependency lifecycle entries into peerDependencies, so persistence of the model
data does not establish that the generated package contains the required peer range.
Agent Prompt
Issue description
The `set-peer` scenarios no longer verify the peer dependency emitted into the generated capsule package manifest. Retain checks before and after snapping so model metadata and generated package output stay aligned.
Fix Focus Areas
- e2e/functionalities/peer-dependency-component.e2e.ts[154-161]
- e2e/functionalities/peer-dependency-component.e2e.ts[194-202]
Recommended Fix
Read the relevant workspace capsule `package.json` after each build and assert that `peerDependencies` contains the component package with the expected range.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit 1f81463 |
1 participant
This PR reduces the number of slow e2e tests. The work goes file by file. Each commit covers one e2e file.
Done so far: add.e2e.ts (24 to 13 tests), config.e2e.ts (13 to 11 tests). More commits will follow on this branch.