feat(@angular/cli): add "test" and "e2e" MCP tools, and some test cleanup

[amishne]

1. Add "test" and "e2e" MCP tools, with their tests.
2. Add an "all" experimental tool group so it's easy to enable them all at once.
3. Make the default project use the actual project name instead of the "" string.
4. Test cleanup, including centralizing test-only utilities into a new file.

In addition to the unit tests, the test tool was also tested manually installed into Gemini-CLI.

[dgp1130]

Lots of random thoughts and code suggestions, but overall LGTM. Thanks for adding this!

[dgp1130]

Consider: We should either link to documentation or call out direct usage of the ng e2e command as a mechanism to configure these tests.

Also typo: I think "setup" is a noun, "set up" would be using it as a verb.

[dgp1130]

Consider: Can this be refactored to a shared primitive somewhere? Seems like it would overlap pretty heavily with other executions of the CLI in the MCP server.

[dgp1130]

Question: I probably should have asked this on an earlier PR (maybe I did and forgot), but how is ng resolved? Is that looking for a global installation on the $PATH? Is it resolving within the project's node_modules somehow? I'm wondering if we want to call process.argv[0] to reuse the existing Angular CLI binary rather than attempting to find it again in the environment?

[dgp1130]

Suggestion: A test which executes ng e2e successfully with the default project. I only see the error case here.

[dgp1130]

Consider: What if someone doesn't have Chrome installed and instead uses Firefox or Safari?

@clydin is there a way to trigger "headless" without specifying a specific browser? The alternative I can think of is setting the CI=true environment variable.

[dgp1130]

Consider: Add tests for these utilities directly. It can potentially reduce the need for some test coverage in the MCP tools as well.

[dgp1130]

Consider: Could we put the auto-incrementing port number implementation here and potentially reuse it across all affected tests?

[dgp1130]

Consider: If we can make this mock setup easier (potentially with the fake implementation proposed in a separate comment) we can move this out of the beforeEach and into each test, so each one can get a unique environment for its needs rather than attempting to share and then retroactively configure a base environment.

[dgp1130]

Consider: Is there a path to a "fake" host instead of a "mock" host? Could we provide fake implementations for stat and existsSync if we accept a virtual file system (or create a real one in a temp directly from inputs)?

Faking implementation of runCommand and spawn is likely a bit harder, but we could either delegate the command to an input function or actually run a real subprocess to get more accurate error behavior. I'm thinking something along the lines of:

import * as fs from 'fs/promises';

class FakeHost implements Host {
  private nextPort = 0;

  private constructor(private readonly cmdImpls: Record<string, (...args: string[]) => CommandResult>, private readonly root: string) {}

  static async from(cmdImpls: Record<string, (...args: string[]) => CommandResult>, fs: Record<string, string | Buffer> = {}): Promise<FakeHost> {
    const tempDir = await fs.mkdtemp();

    for (const [path, content] of Object.entries(fs)) {
      await fs.writeFile(path, content);
    }

    return new FakeHost(cmdImpls, tempDir);
  }

  stat() { /* Check in `root` */ }
  existsSync() { /* Check in `root` */ }

  getAvailablePort(): number {
    return this.nextPort++;
  }

  runCommand(binary: string, args: string[]): /* ... */ {
    return this.cmdImpls[binary](args);
  }
  spawn() { /* Similar to `runCommand`... */ }

  await dispose(): Promise<void> {
    await fs.rmdir(this.root);
  }
}

I'm thinking this can avoid the need to define spies unique to each test and increase overall test confidence. If we can make this specific to each test as suggested in a separate comment, it can potentially remove the need to mutate the environment after the beforeEach within a test.

Downside is that we do need to explicitly call dispose to clean up the temp directory if we're using a real file system. If we can run these tests on Node 24, we can potentially get away with using and Symbol.dispose which would help.

it('does a thing', () => {
  await using host = await FakeHost.from(...);
  await runE2e(host, ...);
  // Host implicitly disposed at end of scope.
});

[dgp1130]

Question: This is the case where we run the MCP server outside of a specific Angular CLI project right? I wonder if we should just fail in that case rather than attempting to run an ng e2e command which will almost certainly fail.

Thoughts @clydin?