W-20893569 adding b2c-cli unit tests

[charithaT07]

Summary

Brief description of what this PR does.

This PR delivers a comprehensive unit test suite for the b2c-cli package, covering key CLI commands such as WebDAV, Docs, Job, Sites, MRT, Auth, Code, and ODS.

In addition to expanding test coverage, it standardizes and improves test patterns by introducing shared helpers for:

• Isolating config and environment to ensure tests run hermetically without depending on local developer settings.
• Providing a unified command creation utility to guarantee consistent initialization across tests.
• Refactoring tests to remove redundant patterns and ensure compliance with Mocha and ESLint best practices.

To enable testing, minor, controlled changes were made to source files of some commands. These test seams allow stubbing internal behavior in isolation without affecting functionality, avoiding reliance on network, filesystem, or local environment.

The PR also consolidates test helper logic by removing ODS-specific helpers and aligning ODS tests with the new common testing approach, improving maintainability and readability across the test suite.

b2c-cli package coverage is now 85%

Testing

How was this tested?

---

• Tests pass (pnpm test)
• Code is formatted (pnpm run format)

[clavery]

Few comments on the style of dependency injection for testing here. I'd like to keep the number of lines supporting tests in the commands to a minimum so if the patterns I mentioned work that would be a better approach I think

[clavery]

It seems this might be to mock the underlying SDK with sinon. But it's adding quite a bit of lines and noise. Can we try simplifying the dependency injection pattern here. Maybe we can support the run method with default arguments set to the imported SDK methods? So the tests can pass in their mocks.

  async run(
    // we'll have to disable this eslint globally but that's ok
    // eslint-disable-next-line unicorn/no-object-as-default-parameter
    operations = {
      uploadCartridges,
      deleteCartridges,
      getActiveCodeVersion,
      reloadCodeVersion,
    },
  ): Promise<DeployResult> {
    const {uploadCartridges, deleteCartridges, getActiveCodeVersion, reloadCodeVersion} = operations;

That way only the run method needs to change and the rest of the code stays the same.

Or maybe using a protected member with the operations we want to mock and then mock this in the tests?

   protected operations = {
     uploadCartridges,
     deleteCartridges,
     getActiveCodeVersion,
     reloadCodeVersion,
   };

//

await operations.uploadCartridges

[charithaT07]

Sure, Thanks Charles! I’ll look at simplifying the dependency injection pattern for these commands and see how we can reduce the test scaffolding.

[charithaT07]

For DI, I’m now using a protected operations object as suggested so tests can override only what they need

[clavery]

This seems very similar to the config-isolation in the SDK. Any way we can share that helper code to keep it consistent?

[charithaT07]

For config isolation, I’ve switched CLI tests to import from @salesforce/b2c-tooling-sdk/test-utils so we share the same helper to keep consistent.

[clavery]

The pattern of duplicating the type of the function here is brittle. We should just use the name verbatim, i.e. uploadCartridges so type inference can work. If we're using the operations pattern it should just be a simple object of the operations.

There's no need to capture this.instance here we can pass that in the code deploy.

[charithaT07]

I’ve updated operations to use the SDK functions (no wrapper lambdas or copied parameter types) and now pass this.instance at the call sites.

[clavery]

Thank you