/**
 * Which test runner does this project use, and how do you get a report out of
 * it?
 *
 * smart_test only ever spoke Jest. It appended Jest's flags to `npm test`,
 * parsed Jest's `--json`, and on any other project failed with
 *
 *     Failed to parse Jest output: Expected property name or '}' in JSON at
 *     position 4
 *
 * -- a parser's disappointment, offered to a user whose project simply uses
 * something else. A tool named smart_test should run the tests the project
 * actually has.
 *
 * Each framework here is described by three things: how to recognise it, which
 * flags make it emit a machine-readable report, and how to turn that report
 * into the one shape the rest of the tool understands.
 */
export type FrameworkId = 'jest' | 'vitest' | 'mocha' | 'node' | 'ava' | 'unknown';
export interface NormalisedTestResult {
    numTotalTests: number;
    numPassedTests: number;
    numFailedTests: number;
    numPendingTests: number;
    testResults: Array<{
        name: string;
        status: 'passed' | 'failed' | 'pending' | 'skipped';
        duration: number;
        failureMessage?: string;
        /**
         * Jest and Vitest report a FILE per entry with the individual tests nested
         * here. The flat runners have no such level, and their entries carry
         * failureMessage directly -- consumers must handle both.
         */
        assertionResults?: Array<{
            title: string;
            status: 'passed' | 'failed' | 'pending';
            failureMessages: string[];
        }>;
    }>;
}
export interface FrameworkAdapter {
    id: FrameworkId;
    /** Human name, for messages. */
    label: string;
    /** Flags that make this runner emit something parseable. */
    reportArgs: (options: {
        coverage?: boolean;
    }) => string[];
    /**
     * Flags that must reach the runner through NODE_OPTIONS rather than argv.
     *
     * `node --test` parses its own options only BEFORE `--test`; anything after
     * is taken as a file glob. Since smart_test appends to the project's own
     * `npm test` script, a trailing `--test-reporter=tap` is silently swallowed
     * -- measured on Node 24, which then reported in its default `spec` format
     * while we looked for TAP. NODE_OPTIONS is the seam that actually works.
     */
    nodeOptions?: (options: {
        pattern?: string;
    }) => string[];
    /** Turns its output into the shape everything downstream expects. */
    parse: (stdout: string, stderr: string) => NormalisedTestResult | null;
}
export declare const ADAPTERS: Record<Exclude<FrameworkId, 'unknown'>, FrameworkAdapter>;
/**
 * Works out which runner a project uses, from its manifest.
 *
 * The test SCRIPT is the strongest signal -- it is what `npm test` will
 * actually execute -- with the dependency list as the fallback.
 */
export declare function detectFramework(pkg: {
    scripts?: Record<string, string>;
    dependencies?: Record<string, string>;
    devDependencies?: Record<string, string>;
}): FrameworkId;
/**
 * Parses output without knowing the framework.
 *
 * Used when detection was inconclusive: rather than refusing, try each shape
 * and accept whichever one actually fits. A report that parses is a report,
 * whoever produced it.
 */
export declare function parseAnyKnownFormat(stdout: string): {
    result: NormalisedTestResult;
    framework: FrameworkId;
} | null;
//# sourceMappingURL=test-frameworks.d.ts.map