testing library

Drives a Command the way the framework drives it, for tests that hold one command rather than a whole ModularCli.

import 'package:modular_cli_sdk/testing.dart';

test('opens the requisition', () async {
  final output = await applyCommand(OpenRequisition(input));
  expect(output.dir, 'docs/requisitions/20260812-billing');
});

Why this is a separate library. A command is built from steps, and something else previews or performs them — in production, always the framework. PreviewExecutor is therefore not exported by modular_cli_sdk.dart: a command that could reach it could run steps outside the gate, with no plan shown, no approval taken and no check that what happened is what was announced, which is the one thing the whole arrangement exists to prevent.

Tests need what production must not have. Putting it here rather than in the main library is what lets both be true: production code imports modular_cli_sdk.dart and cannot reach the executor; a test imports this and gets a lifecycle it did not have to reimplement.

And reimplementing it is the real hazard. These three functions do what ModuleBuilder does and nothing more. A host that hand-rolled them instead would hold a second description of the same lifecycle, with nothing keeping the two in agreement — so the day the framework changes, that host's suite stays green while testing a flow the CLI no longer takes. That is the dryRun flag all over again, in the test suite.

Classes

Functions

modular_cli_sdk package

testing library