SmartTest

SMARTTEST

Complete Product Requirements Document & Technical Design Specification #

Document Version: 2.0
Document Status: Master Specification
Product Name: SmartTest (working name)
Product Type: Intelligent Testing Platform
Distribution: npm, CLI, SDK, Desktop/Web Studio, CI/CD, SaaS
Business Model: Open Source Core + Commercial Cloud
Initial Languages: TypeScript / JavaScript
Future Languages: Python, Java, Go, C#, PHP, Rust, Kotlin, and more
Core Philosophy: Intelligent by default. Deterministic at its core. AI-enhanced. Developer-first.

This is the master specification, kept as the source of truth. It covers the intelligent testing engine, automated setup, Git/SVN/native version tracking, AI-powered test engineering, a Cypress-like GUI, multi-language architecture and the commercial SaaS model. It is written for developers, AI coding agents, architects and QA engineers. Scope for v1.0.0 is defined in the roadmap (what is built so far: delivery log; the first 103 stories: foundation backlog). Section numbers (§) are what the backlog and ADRs cite.

Table of Contents #

  1. Executive Summary
  2. Target Users and Use Cases
  3. Product Scope and Delivery Priorities
  4. System Architecture
  5. Smart Init — Fully Automated Setup
  6. Adaptive Configuration Engine
  7. Universal Version Control System
  8. SmartTest Native Snapshot Engine
  9. Source Code Intelligence Engine
  10. Dependency Graph Engine
  11. Intelligent Test Impact Engine
  12. Runtime Tracing Engine
  13. Automatic Test Architecture Generator
  14. Custom Rules Engine
  15. Smart Test Execution Engine
  16. Coverage Intelligence
  17. SmartTest AI — Universal AI Testing Assistant
  18. AI Provider Setup and Model Discovery
  19. AI Command System
  20. AI Test Generation Engine
  21. AI Coverage Audit and Gap Detection
  22. AI Test Repair, Improvement, and Review
  23. SmartTest Autopilot
  24. SmartTest Studio — Interactive GUI
  25. Reporting Engine
  26. CLI Developer Experience
  27. Plugin SDK and Multi-Language Support
  28. SmartTest Cloud — Commercial Platform
  29. Business Model and Monetization
  30. Security and Privacy
  31. Performance Requirements
  32. Reliability and Correctness
  33. Metrics and KPIs
  34. Engineering Backlog
  35. Release Roadmap
  36. Definition of Done
  37. Key Technical Risks
  38. Product Success Criteria
  39. Final Product Positioning
  40. Final Product Objective

1. Executive Summary

1.1. Product Vision #

SmartTest is a next-generation software testing intelligence platform designed to automatically understand source code changes, identify affected components, select the most relevant tests, execute them efficiently, and generate detailed, interactive reports.

Unlike conventional testing tools, SmartTest should understand the relationship between source code, dependencies, tests, runtime execution, coverage, and code history.

SmartTest must also automatically discover and configure existing software projects, generate organized test architectures, adapt to changing development environments, and optionally use artificial intelligence to generate, audit, repair, and improve tests.

The platform will include:

  1. SmartTest Core: Intelligent code analysis and test-impact engine.
  2. Smart Init: Fully automated project discovery and configuration.
  3. Universal Version Control: Support for Git, SVN, Mercurial, Perforce, and a native snapshot engine.
  4. Adaptive Configuration: Automatic detection of project and environment changes.
  5. Automatic Test Architecture: Source-aware organization and generation of test directories.
  6. Rules Engine: Custom testing policies at project, package, class, and method levels.
  7. Smart Execution: Selective, risk-aware, parallelized test execution.
  8. Coverage Intelligence: Analysis of code coverage and missing test protection.
  9. SmartTest AI: Optional AI-driven test generation, auditing, repair, and optimization.
  10. SmartTest Studio: An interactive testing GUI inspired by the usability of Cypress.
  11. Reporting Engine: Modern, detailed, explainable test and coverage reports.
  12. SmartTest Cloud: Collaboration, CI optimization, historical analytics, and enterprise capabilities.

1.2. Main Objective #

Transform software testing from a mostly static and repetitive process into a continuously adaptive system that understands:

1.3. Product Statement #

SmartTest — Understand the change. Test what matters.

1.4. Fundamental Principles #

Local-first: Core functionality must work without cloud services or user accounts.

Framework-agnostic: SmartTest orchestrates existing testing frameworks rather than replacing them.

Deterministic-first: Critical decisions must be based on verifiable analysis and explicit policies.

AI-optional: Artificial intelligence enhances the experience but is not required.

Non-destructive: SmartTest must preserve existing source files, tests, and custom configurations unless explicitly authorized to modify them.

Explainable: Every test-selection decision must have a traceable explanation.

Adaptive: SmartTest should evolve with the project without requiring repeated manual setup.

Secure: Source code, credentials, and execution artifacts must be protected.

Performance-oriented: Analysis overhead must remain lower than the savings it enables whenever selective execution is appropriate.

Extensible: New languages, frameworks, providers, and version-control systems must be supported through plugins.

1.5. Important Engineering Constraint #

No static or dynamic analysis engine can universally guarantee that a skipped test could not detect a regression.

Dynamic imports, reflection, shared state, external services, environment changes, and other runtime behaviors create uncertainty.

SmartTest must therefore use conservative fallbacks, explicit risk policies, and periodic full-suite validation.

The product must never present skipped tests as passed tests.

2. Target Users and Use Cases

2.1. Independent Developers #

Primary needs:

2.2. Development Teams #

Primary needs:

2.3. Engineering Managers #

Primary needs:

2.4. QA Engineers #

Primary needs:

2.5. Enterprise Organizations #

Primary needs:

3. Product Scope and Delivery Priorities

3.1. Priority Definitions #

P0 — Core MVP: Essential for a usable, publicly distributable package.

P1 — Advanced Product: High-value enhancements after the core is stable.

P2 — Platform Expansion: Commercial, AI, and multi-language extensions.

3.2. Functional Modules #

ModulePriorityDescription
Smart InitP0Automatic project setup
Project DetectorP0Technology and structure discovery
Git AdapterP0Git change tracking
Native Snapshot EngineP0Local changes without Git
Source ParserP0AST and semantic analysis
Dependency GraphP0Code relationship mapping
Impact EngineP0Change-impact calculation
Test DiscoveryP0Existing test identification
Test SelectorP0Intelligent test selection
Rules EngineP0Custom testing policies
Test GeneratorP0Automatic test structure and scaffolding
Jest AdapterP0Jest integration
Vitest AdapterP0Vitest integration
Report EngineP0Local HTML and machine-readable reports
CLI UXP0Interactive and scriptable terminal
Adaptive ConfigurationP1Project evolution detection
SVN AdapterP1Subversion integration
Runtime TracerP1Execution-to-test mapping
Advanced CoverageP1Diff and branch coverage intelligence
SmartTest StudioP1Interactive local GUI
Watch ModeP1Continuous incremental testing
Intelligent CacheP1Validated execution caching
CI IntegrationsP1GitHub Actions and other CI systems
AI Provider ManagerP1LLM connection and model discovery
AI Test GenerationP1Automated test creation
AI Coverage AuditP1Coverage and behavior analysis
AI Test RepairP2Assisted test maintenance
Mercurial AdapterP2Mercurial integration
Perforce AdapterP2Perforce integration
Cloud SaaSP2Commercial platform
Multi-language SDKP2New language support
Enterprise FeaturesP2Governance and private deployment

3.3. Initial Compatibility #

The MVP must support:

Framework-specific detection should initially prioritize:

The architecture must not assume that every supported project uses one of these frameworks.

4. System Architecture

4.1. Architectural Overview #

SmartTest will use a modular architecture separating project discovery, source intelligence, change tracking, test selection, execution, reporting, and optional AI capabilities.

                         SMARTTEST
                             |
                   CLI / Studio / SDK
                             |
                  APPLICATION CORE
                             |
       +---------------------+--------------------+
       |                     |                    |
   PROJECT ENGINE        CODE ENGINE         TEST ENGINE
       |                     |                    |
   Smart Init            AST Analysis         Test Discovery
   Configuration         Symbol Index         Test Selection
   Environment           Dependency Graph     Execution
   VCS Adapters          Semantic Diff        Coverage
   Native Snapshots      Impact Analysis      Runtime Tracing
       |                     |                    |
       +---------------------+--------------------+
                             |
                     RULES & SAFETY ENGINE
                             |
                    LOCAL INTELLIGENCE STORE
                             |
                 Cache / Traces / Graph / Runs
                             |
                      REPORTING ENGINE
                             |
                  CLI / HTML / JSON / CI
                             |
                    OPTIONAL AI ENGINE
                             |
                    OPTIONAL CLOUD API

4.2. Monorepo Structure #

smarttest/
├── apps/
│   ├── studio/
│   ├── docs/
│   ├── playground/
│   ├── cloud-console/
│   └── cloud-api/
│
├── packages/
│   ├── cli/
│   ├── core/
│   ├── config/
│   ├── shared/
│   │
│   ├── smart-init/
│   ├── project-detector/
│   ├── environment-scanner/
│   ├── adaptive-config/
│   │
│   ├── vcs-core/
│   ├── vcs-git/
│   ├── vcs-svn/
│   ├── vcs-mercurial/
│   ├── vcs-perforce/
│   ├── native-snapshots/
│   │
│   ├── source-parser/
│   ├── symbol-index/
│   ├── semantic-diff/
│   ├── dependency-graph/
│   ├── impact-engine/
│   │
│   ├── test-discovery/
│   ├── test-selector/
│   ├── test-generator/
│   ├── test-executor/
│   ├── runtime-tracer/
│   ├── coverage-engine/
│   ├── rules-engine/
│   ├── quality-engine/
│   ├── cache-engine/
│   │
│   ├── report-engine/
│   ├── studio-server/
│   │
│   ├── ai-core/
│   ├── ai-provider-manager/
│   ├── ai-test-generator/
│   ├── ai-test-auditor/
│   ├── ai-test-repair/
│   ├── ai-test-review/
│   │
│   ├── adapter-jest/
│   ├── adapter-vitest/
│   ├── adapter-playwright/
│   ├── adapter-cypress/
│   │
│   ├── language-typescript/
│   ├── language-javascript/
│   └── plugin-sdk/
│
├── examples/
│   ├── node/
│   ├── react/
│   ├── nextjs/
│   ├── nestjs/
│   ├── monorepo/
│   └── no-vcs/
│
├── benchmarks/
├── fixtures/
├── integration-tests/
├── e2e-tests/
├── scripts/
└── documentation/

4.3. Technology Stack #

Core #

SmartTest Studio #

Cloud #

Future Native Acceleration #

High-cost CPU operations may be migrated to Rust if measured benchmarks justify the complexity.

This must not be a prerequisite for the initial npm package.

5. Smart Init — Fully Automated Setup

5.1. Objective #

smarttest init must provide a near-zero-configuration installation experience.

The developer should not need to manually identify their test framework, source directories, module structure, or version-control system.

SmartTest should inspect the project, create a recommended setup plan, explain it, and apply authorized changes.

5.2. Main Commands #

smarttest init
smarttest init --auto
smarttest init --advanced
smarttest init --dry-run
smarttest init --yes --non-interactive
smarttest doctor
smarttest sync

5.3. Project Discovery #

Smart Init must detect:

Runtime Environment #

Project Structure #

Frameworks #

Detect frameworks through package manifests, configuration files, source imports, and known project conventions.

Existing Tests #

Detect:

Version Control #

Detect:

CI/CD #

Detect supported configuration files for:

5.4. Smart Init Pipeline #

START
  |
Environment Scan
  |
Project Discovery
  |
Framework Detection
  |
Test Runner Detection
  |
Version Control Detection
  |
Existing Test Analysis
  |
Rules & Coverage Discovery
  |
Compatibility Checks
  |
Recommended Setup Plan
  |
User Review
  |
Apply Authorized Changes
  |
Validate Installation
  |
Generate Setup Report
  |
READY

5.5. Setup Recommendation Engine #

The initialization engine should determine:

Recommendations must include a reason.

Example:

Detected: NestJS + TypeScript + Jest

Recommended:
  Test layout: Mirror source
  Unit tests: Jest
  Integration tests: Jest
  Source tracking: Git + Native Snapshots
  Impact mode: Balanced
  Coverage: Existing Jest provider
  Cache: Local persistent

Warnings:
  4 modules have no matching tests
  2 configuration files may affect all suites

5.6. Setup Modes #

Interactive #

Guided setup with suggested defaults.

Automatic #

Applies only permitted, low-risk actions.

Advanced #

Exposes all configuration options.

Non-Interactive #

Designed for CI, scripts, and automated environments.

Missing required configuration must produce a deterministic error rather than an interactive prompt.

Dry Run #

Displays the proposed changes without writing files.

5.7. Installation Safety #

Smart Init must:

5.8. Idempotency #

Executing smarttest init repeatedly must not create duplicated configuration, scripts, or directories.

Existing user customizations must be retained.

5.9. Acceptance Criteria #

6. Adaptive Configuration Engine

6.1. Objective #

SmartTest must adapt to changes in the project after initial setup.

A project may begin without version control, adopt Git later, change test frameworks, introduce new packages, or migrate to a monorepo.

SmartTest should identify these changes and propose the necessary updates.

6.2. Events to Detect #

6.3. Adaptation Process #

  1. Detect environment change.
  2. Compare with the previous known configuration.
  3. Identify affected SmartTest components.
  4. Invalidate stale metadata.
  5. Build a migration or synchronization plan.
  6. Preserve existing user settings.
  7. Request approval when modifications are required.
  8. Apply changes.
  9. Validate the new state.
  10. Record the adaptation event.

6.4. Commands #

smarttest sync
smarttest sync --check
smarttest sync --vcs
smarttest sync --tests
smarttest sync --frameworks

smarttest doctor
smarttest doctor --fix
smarttest migrate

6.5. Example: Adding Git After Initialization #

Initial state:

Project:
  Version control: None
  Change tracking: Native Snapshots

Developer runs:

git init

SmartTest detects Git.

Suggested adaptation:

New version control detected: Git

Recommended actions:
  Connect Git adapter
  Preserve native snapshots
  Establish a new Git baseline
  Reconcile source fingerprints
  Validate existing impact graph

SmartTest must not silently assume that old native snapshot identifiers are equivalent to Git commits.

6.6. Acceptance Criteria #

7. Universal Version Control System

7.1. Objective #

The impact engine must work independently of the source-control provider.

Supported providers should produce a common normalized representation of changes.

7.2. Planned Providers #

ProviderSupport
GitInitial
SmartTest NativeInitial
SVNAdvanced
MercurialExtension
PerforceExtension
Custom VCSPlugin SDK

7.3. Common Adapter Contract #

interface VersionControlAdapter {
  readonly id: string;

  detect(root: string): Promise<boolean>;

  getWorkingState(): Promise<WorkingState>;

  getChanges(base: RevisionRef, target?: RevisionRef): Promise<ChangeSet>;

  getFileContent(path: string, revision: RevisionRef): Promise<Uint8Array | null>;

  getCapabilities(): VersionControlCapabilities;
}

Each adapter must declare supported capabilities.

Git branches, SVN revisions, and Perforce changelists must not be treated as semantically identical.

7.4. Unified ChangeSet #

interface ChangeSet {
  provider: string;

  baseRevision?: string;
  targetRevision?: string;

  changes: FileChange[];

  completeness: "complete" | "partial" | "unknown";

  warnings: string[];
}

interface FileChange {
  path: string;
  previousPath?: string;

  type: "added" | "modified" | "deleted" | "renamed";

  changedRanges?: SourceRange[];

  previousHash?: string;
  currentHash?: string;
}

7.5. Git Integration #

Support:

Example:

smarttest run --base main
smarttest run --staged
smarttest run --uncommitted

7.6. SVN Integration #

Support:

Example:

smarttest run --vcs svn --base r142

7.7. Mercurial and Perforce #

Provide extension adapters for:

7.8. Multiple VCS Detection #

If multiple providers are detected, SmartTest must:

8. SmartTest Native Snapshot Engine

8.1. Objective #

Allow intelligent change tracking without Git, SVN, or another VCS.

Native Snapshots are a testing-oriented history system, not a full source-control replacement.

8.2. Features #

8.3. Local Storage Structure #

.smarttest/
├── state/
│   ├── index.db
│   ├── snapshots/
│   ├── graph/
│   └── fingerprints/
├── traces/
├── cache/
├── runs/
├── reports/
└── logs/

Actual storage paths must be configurable.

Generated files should be excluded from source-control commits by default.

8.4. Storage Strategy #

Prefer:

Snapshots must not copy entire repositories unnecessarily.

8.5. Hybrid Mode #

SmartTest should support:

Git / SVN / Perforce
        +
SmartTest Native Snapshots
        |
Semantic Change Analysis
        |
Impact Graph
        |
Test Selection

Native snapshots provide local incremental analysis while external VCS providers supply official repository revisions.

8.6. Commands #

smarttest snapshot create
smarttest snapshot list
smarttest snapshot inspect
smarttest snapshot diff
smarttest snapshot prune

smarttest vcs detect
smarttest vcs status
smarttest vcs connect

8.7. Snapshot Reliability #

A source snapshot must be distinguished from a verified testing baseline.

A verified baseline requires associated execution evidence.

Snapshot comparisons must indicate missing or incomplete content.

9. Source Code Intelligence Engine

9.1. Objective #

Analyze code at a finer level than files.

SmartTest must understand symbols, references, exports, and dependency relationships.

9.2. Supported Symbol Types #

9.3. Symbol Data Model #

interface SourceSymbol {
  id: string;

  filePath: string;
  qualifiedName: string;

  kind: "module" | "class" | "interface" | "function" | "method" | "property" | "type";

  signature?: string;

  sourceRange: SourceRange;

  parentSymbolId?: string;

  visibility?: "public" | "protected" | "private";

  decorators: string[];

  dependencies: string[];
}

9.4. Semantic Change Detection #

Classify changes such as:

Classification must report uncertainty.

9.5. Incremental Analysis #

Only changed and invalidated portions of the project should be reparsed when possible.

The engine must maintain persistent indexes and update dependent relationships incrementally.

9.6. Generated Code #

Generated code must be handled separately.

The engine should understand whether generated output must be rebuilt, tested, or excluded based on explicit rules.

10. Dependency Graph Engine

10.1. Objective #

Build a graph representing relationships between source code, tests, configuration, and observed execution paths.

10.2. Node Types #

10.3. Edge Types #

10.4. Static Dependency Graph #

Built through source analysis.

Captures known code relationships.

10.5. Dynamic Execution Graph #

Built from observed test execution and coverage information.

Captures which source elements were exercised by tests.

10.6. Hybrid Graph #

Combines static and dynamic information, preserving provenance and confidence.

A relationship observed during execution must not automatically invalidate other potential static relationships.

10.7. Reverse Dependency Analysis #

Example:

AuthService.validateToken()
          |
          +-- AuthService.test.ts
          |
          +-- AuthController
          |       |
          |       +-- AuthController.test.ts
          |
          +-- AuthenticationMiddleware
                  |
                  +-- ProtectedRoutes.test.ts

10.8. Graph Requirements #

11. Intelligent Test Impact Engine

11.1. Objective #

Identify a defensible set of tests relevant to a change.

The selection engine must combine:

11.2. Impact Selection Pipeline #

Changed Files
     |
Semantic Diff
     |
Affected Symbols
     |
Static Dependencies
     |
Runtime Execution Traces
     |
Risk and Safety Policies
     |
Candidate Test Set
     |
Confidence and Completeness Check
     |
Final Test Selection
     |
Execution Plan

11.3. Selection Modes #

FAST #

Optimized for local feedback.

Characteristics:

BALANCED #

Recommended default for pull requests.

Characteristics:

SAFE #

Recommended for releases and critical code.

Characteristics:

11.4. Mandatory Test Selection #

Certain events must trigger broader verification.

Examples:

11.5. Selection Result Model #

interface ImpactDecision {
  selectedTests: SelectedTest[];

  skippedTests: SkippedTest[];

  affectedFiles: string[];

  affectedSymbols: string[];

  analysisStatus: "complete" | "partial" | "fallback";

  safetyMode: "fast" | "balanced" | "safe";

  reasons: SelectionReason[];

  warnings: string[];

  fallbackApplied: boolean;
}

11.6. Explainability #

Every selected test must expose its selection reasons.

Example:

SELECTED: AuthService.test.ts

Reasons:
  Modified symbol: AuthService.validateToken
  Direct dependency relationship
  Previously observed execution coverage
  Matched rule: authentication-critical

For skipped tests:

SKIPPED: CatalogService.test.ts

Reasons:
  No detected static dependency
  No valid observed execution overlap
  No mandatory rule matched
  Baseline available

Confidence:
  Limited to the analyzed dependency model

11.7. Safety Validation #

Provide:

smarttest validate-selection

The validation workflow should compare selective execution against a full reference run.

Measure:

The product must not guarantee zero missed regressions beyond what its evidence supports.

12. Runtime Tracing Engine

12.1. Objective #

Record which source elements are actually exercised by each test.

12.2. Supported Granularity #

Depending on adapter capabilities:

12.3. Trace Record #

interface TraceRecord {
  testId: string;
  runId: string;

  sourceFingerprint: string;

  environmentFingerprint: string;

  granularity: "suite" | "test" | "file" | "symbol";

  coveredFiles: string[];

  coveredSymbols: string[];

  collectedAt: string;

  valid: boolean;
}

12.4. Requirements #

12.5. Important Limitation #

Individual test-to-method mapping cannot be assumed universally available for every framework and execution mode.

Adapters must declare what they actually support.

If only suite-level tracing is available, SmartTest must select at suite granularity or use additional conservative evidence.

13. Automatic Test Architecture Generator

13.1. Objective #

SmartTest should automatically create and maintain a well-organized test architecture derived from the source code.

13.2. Example Source Structure #

src/
├── modules/
│   ├── auth/
│   │   ├── AuthController.ts
│   │   ├── AuthService.ts
│   │   └── TokenManager.ts
│   └── users/
│       ├── UserController.ts
│       ├── UserService.ts
│       └── UserRepository.ts
└── shared/
    └── validators/
        └── EmailValidator.ts

13.3. Generated Test Structure #

tests/
├── unit/
│   ├── modules/
│   │   ├── auth/
│   │   │   ├── AuthController.test.ts
│   │   │   ├── AuthService.test.ts
│   │   │   └── TokenManager.test.ts
│   │   └── users/
│   │       ├── UserController.test.ts
│   │       ├── UserService.test.ts
│   │       └── UserRepository.test.ts
│   └── shared/
│       └── validators/
│           └── EmailValidator.test.ts
├── integration/
├── e2e/
├── fixtures/
├── mocks/
├── helpers/
└── setup.ts

13.4. Organization Strategies #

MIRROR #

Mirror the source structure.

COLOCATED #

Place tests alongside source files.

DOMAIN #

Group tests by business domain.

CUSTOM #

Use user-defined path and naming templates.

13.5. Naming Tokens #

Supported template variables should include:

{ClassName}
{FunctionName}
{MethodName}
{FileName}
{ModuleName}
{PackageName}
{DomainName}
{Type}
{Extension}

Example:

{ClassName}.{Type}.test.ts

13.6. Generation Modes #

SCAFFOLD #

Create directories and explicit test placeholders.

ANALYZE #

Inspect public behavior, dependencies, and likely scenarios.

AI GENERATE #

Produce meaningful proposed tests using the configured AI provider.

SYNC #

Compare test architecture with the current source layout.

REFACTOR #

Propose a non-destructive reorganization of existing tests.

13.7. Commands #

smarttest generate
smarttest generate --mode scaffold
smarttest generate --mode analyze
smarttest generate --sync

smarttest generate --class UserService
smarttest generate --module auth
smarttest generate --type integration

smarttest generate --dry-run
smarttest generate --ai

13.8. Safety Requirements #

The generator must:

Incomplete test skeletons must not count as meaningful test coverage.

13.9. Architecture Synchronization #

When source code changes, SmartTest should identify:

The generator should propose updates rather than silently restructuring user code.

14. Custom Rules Engine

14.1. Objective #

Allow developers to define fine-grained test requirements based on source architecture.

14.2. Rule Scopes #

14.3. Supported Selectors #

14.4. Rule Types #

Generation Rules #

Define test folder layout and templates.

Coverage Rules #

Define required line and branch coverage.

Execution Rules #

Define mandatory tests and execution policies.

Risk Rules #

Classify critical components.

Quality Rules #

Define limits for instability, redundancy, and excessive execution time.

CI Rules #

Define pass/fail quality gates.

14.5. Example Configuration #

export default defineConfig({
  rules: [
    {
      name: "service-tests",

      match: {
        class: "*Service",
      },

      require: ["unit"],

      coverage: {
        lines: 90,
        branches: 85,
      },

      generate: {
        template: "service",
      },
    },

    {
      name: "repository-tests",

      match: {
        class: "*Repository",
      },

      require: ["unit", "integration"],

      generate: {
        template: "database",
      },
    },

    {
      name: "authentication-critical",

      match: {
        path: "src/modules/auth/**",
      },

      risk: "critical",

      execution: {
        alwaysRunOnAffected: true,
        mode: "safe",
      },
    },
  ],
});

14.6. Rule Precedence #

Rule evaluation must be deterministic.

Mandatory safeguards cannot be weakened by lower-priority rules.

Conflicting destination paths or incompatible templates must produce an explicit error.

Rule decisions must be inspectable.

14.7. Commands #

smarttest rules list
smarttest rules validate

smarttest rules explain \
  src/modules/auth/AuthService.ts

15. Smart Test Execution Engine

15.1. Objective #

Execute selected tests efficiently through existing test frameworks.

SmartTest should not unnecessarily rebuild the full functionality of Jest, Vitest, Playwright, or Cypress.

15.2. Features #

15.3. Intelligent Scheduling #

The scheduler may consider:

15.4. Cache Requirements #

Cache validity must consider relevant inputs, including:

Tests dependent on uncontrolled external state should be excluded from caching unless a valid reproducibility contract exists.

15.5. Result Statuses #

Required statuses:

A cached result must not appear as a fresh execution.

15.6. Flaky Test Detection #

Track:

A test that fails and later passes on retry must remain visibly marked as unstable.

16. Coverage Intelligence

16.1. Supported Measurements #

16.2. Coverage Types #

SmartTest must clearly distinguish:

Full Coverage: Coverage from a complete test-suite execution.

Selected Coverage: Coverage from the selected subset.

Diff Coverage: Coverage of changed lines or branches.

These figures must never be combined or substituted without explanation.

16.3. Coverage Gaps #

Detect:

16.4. Quality Gates #

Examples:

Changed line coverage >= 90%
Critical branch coverage >= 95%
No untested critical public API changes
No required integration tests missing

Thresholds must be configurable.

16.5. Commands #

smarttest coverage
smarttest coverage --changed
smarttest coverage --explain

smarttest generate --missing-coverage

16.6. Coverage Quality Principle #

High execution coverage does not automatically imply strong assertions.

Coverage quality should also be evaluated through behavioral tests, edge-case analysis, and optional mutation testing.

17. SmartTest AI — Universal AI Testing Assistant

17.1. Objective #

Provide an optional AI engineering assistant that can understand project structure, generate tests, analyze coverage, explain failures, suggest improvements, and maintain test quality.

The AI system must use SmartTest's existing project indexes and impact graph to minimize unnecessary context and repeated analysis.

17.2. Architecture #

SmartTest AI CLI / Studio
             |
       AI Task Manager
             |
        Context Builder
             |
   Provider Abstraction Layer
             |
    Model Discovery & Routing
             |
       AI Model Endpoint
             |
      Structured Proposal
             |
   Validation & Safety Engine
             |
     Review / Apply Changes

17.3. AI Must Remain Optional #

All deterministic source analysis, test selection, rule evaluation, and execution must work with AI disabled.

AI must not become a required dependency for the core engine.

18. AI Provider Setup and Model Discovery

18.1. Main Commands #

smarttest ai setup
smarttest --ai setup

smarttest ai providers list
smarttest ai providers add
smarttest ai providers remove

smarttest ai models
smarttest ai models --refresh

smarttest ai test-connection
smarttest ai config

18.2. Interactive Setup Flow #

The user provides:

  1. Provider type.
  2. API base URL.
  3. API key if required.
  4. Preferred model.

SmartTest should automatically:

18.3. Supported Provider Types #

18.4. Model Discovery #

For compatible APIs, SmartTest should attempt:

GET {baseURL}/models
Authorization: Bearer <API_KEY>

The base URL must be normalized carefully to avoid duplicated API prefixes.

When model discovery is unavailable:

18.5. Capability Detection #

Where supported, determine:

Capability detection must not assume that all OpenAI-compatible servers implement identical parameters.

Unknown capabilities must remain explicitly unknown.

18.6. Multiple AI Profiles #

Support multiple provider configurations.

Example:

Profiles:

default
  Provider: Custom API
  Model: coding-model

fast
  Provider: Local Ollama
  Model: lightweight-model

review
  Provider: Remote API
  Model: reasoning-model

18.7. Model Routing #

Allow models to be assigned to different tasks:

18.8. Credential Security #

Requirements:

18.9. Usage Budgets #

Support:

If reliable pricing information is unavailable, SmartTest must not present an estimated cost as guaranteed.

19. AI Command System

19.1. CLI Design #

Primary syntax:

smarttest ai <command>

Compatibility alias:

smarttest --ai <command>

Optional enhancement syntax:

smarttest generate --ai
smarttest coverage --ai
smarttest run --ai

The CLI parser must define these behaviors consistently and avoid ambiguous command combinations.

19.2. AI Command Catalog #

CommandResponsibility
ai setupConfigure a provider
ai modelsDiscover and select models
ai generate-testsGenerate tests
ai auditAudit overall test quality
ai gapsIdentify missing scenarios
ai coverageAnalyze coverage weaknesses
ai fixPropose test repairs
ai improveImprove existing tests
ai explainExplain failures
ai reviewReview code changes and tests
ai mutationSuggest or analyze mutation tests
ai mocksGenerate mocks
ai fixturesGenerate fixtures
ai edge-casesDiscover boundary conditions
ai refactorRefactor tests
ai rulesSuggest testing rules
ai optimizeIdentify expensive or redundant tests
ai planCreate a testing strategy
ai doctorDiagnose setup and testing issues

20. AI Test Generation Engine

20.1. Objective #

Generate meaningful tests for selected source files, modules, classes, methods, or complete repositories.

20.2. Targeting Commands #

smarttest ai generate-tests

smarttest ai generate-tests --module auth

smarttest ai generate-tests --class AuthService

smarttest ai generate-tests \
  --method AuthService.login

smarttest ai generate-tests \
  --path src/modules/users

smarttest ai generate-tests --changed

smarttest ai generate-tests --missing

smarttest ai generate-tests --all

20.3. Generation Pipeline #

Step 1 — Analyze #

Collect:

Step 2 — Plan #

Build a testing plan containing:

Step 3 — Generate #

Produce:

Step 4 — Validate #

Check:

Step 5 — Improve #

Revise invalid or weak tests within a configured retry and cost budget.

Step 6 — Review #

Display proposed changes and validation evidence.

Step 7 — Apply #

Write only explicitly approved changes.

20.4. Full Project Generation #

--all must not attempt to place the entire repository into one model prompt.

Instead:

  1. Analyze the complete source index.
  2. Build a dependency-aware work plan.
  3. Split work into modules or symbols.
  4. Estimate requests and resource usage.
  5. Obtain approval.
  6. Generate in bounded batches.
  7. Validate each batch.
  8. Store resumable checkpoints.
  9. Produce a consolidated report.

20.5. Non-Destructive Behavior #

Default behavior must be:

Analyze
  -> Propose
  -> Generate Draft
  -> Validate
  -> Review
  -> Apply

Automatic application must be an explicit opt-in.

20.6. Generated Test Quality #

Tests should not be considered valid merely because they pass.

SmartTest should detect suspicious patterns such as:

21. AI Coverage Audit and Gap Detection

21.1. Commands #

smarttest ai audit

smarttest ai audit --coverage

smarttest ai gaps

smarttest ai gaps --module auth

smarttest ai coverage --changed

21.2. Audit Dimensions #

21.3. Findings #

Each finding should contain:

21.4. Example #

AI COVERAGE AUDIT

Module: Authentication

Line Coverage:   87%
Branch Coverage: 63%

Potential gaps:
  [HIGH] Expired token behavior
  [HIGH] Password validation boundaries
  [MED]  Database connection failure
  [LOW]  Optional parameter behavior

Suggested:
  6 additional test scenarios

Coverage findings must be supported by verifiable source or test evidence rather than unsupported model guesses.

22. AI Test Repair, Improvement, and Review

22.1. AI Fix #

smarttest ai fix --failed

SmartTest should analyze failures and distinguish between:

The assistant must not automatically modify assertions simply to make a failing test pass.

22.2. AI Improve #

smarttest ai improve --module auth

Suggested improvements may include:

22.3. AI Review #

smarttest ai review --base main

Review:

Output should be suitable for:

22.4. AI Mutation Assistance #

The AI may recommend mutation-testing targets or interpret mutation results.

Mutation execution should rely on a compatible mutation-testing engine rather than model-generated assumptions.

23. SmartTest Autopilot

23.1. Objective #

Provide a unified workflow for project testing intelligence.

Command:

smarttest autopilot

23.2. Workflow #

Project Audit
     |
Detect Changes
     |
Update Dependency Graph
     |
Identify Affected Tests
     |
Check Coverage Gaps
     |
Generate Improvement Plan
     |
Optional AI Test Generation
     |
Validate Proposed Tests
     |
Execute Approved Tests
     |
Generate Final Report

23.3. Default Mode #

Autopilot must operate in planning and review mode by default.

It must not silently:

23.4. Commands #

smarttest autopilot

smarttest autopilot --plan

smarttest autopilot --changed

smarttest autopilot --module auth

smarttest autopilot --non-interactive

More autonomous behavior should require explicit policies describing permitted actions and limits.

24. SmartTest Studio — Interactive GUI

24.1. Vision #

SmartTest Studio should deliver an interactive testing experience comparable in usability to tools such as Cypress, but covering a broader range of testing activities.

The Studio must support unit, integration, and E2E workflows through their respective adapters.

24.2. Launch #

smarttest open

Or:

smarttest studio

The CLI starts a local server and opens the Studio in the default browser.

24.3. Initial Architecture #

Use a local web application rather than requiring Electron from the beginning.

React Studio
     |
Local HTTP API + WebSocket
     |
SmartTest Core
     |
Test Framework Adapters
     |
Project Source / Tests

A native desktop wrapper may be introduced later.

24.4. Primary Navigation #

The Studio should contain:

  1. Overview.
  2. Test Explorer.
  3. Impact Map.
  4. Test Builder.
  5. Live Runner.
  6. Coverage.
  7. Reports.
  8. AI Assistant.
  9. Rules.
  10. Settings.

24.5. Overview #

Display:

24.6. Test Explorer #

Tree structure:

Workspace
  Package
    Module
      Class
        Test Suite
          Test Case

Features:

24.7. Impact Map #

Interactive dependency graph displaying:

Interactions:

24.8. Test Builder #

Allow users to:

The Test Builder should work without AI for structural generation.

24.9. Live Runner #

Provide real-time execution views:

For supported browser-testing adapters, additional capabilities may include:

Browser time-travel functionality must only be offered when the underlying framework or recording mechanism actually supports it.

24.10. Coverage Viewer #

Display annotated source code:

24.11. Rules Editor #

Provide a visual interface for configuring rules by:

Rules must remain editable as code or structured configuration.

24.12. AI Assistant Panel #

Support:

The GUI must display which provider and model are being used and whether remote source access is enabled.

24.13. Studio UX Requirements #

24.14. Local Studio Security #

The local server must:

25. Reporting Engine

25.1. Objective #

Produce attractive, useful, and technically accurate reports.

25.2. Export Formats #

25.3. Report Sections #

Executive Summary #

Change Analysis #

Test Selection #

Coverage #

Performance #

AI Findings #

When AI is enabled:

25.4. Report Integrity #

Reports must never imply:

26. CLI Developer Experience

26.1. Main UX Principle #

The CLI must be intuitive for beginners and fully scriptable for advanced users.

Three interaction patterns:

Interactive: Guided menus and intelligent defaults.

Direct: Explicit commands and options.

Automation: Stable non-interactive behavior and machine-readable output.

26.2. Main Commands #

smarttest
smarttest init
smarttest doctor
smarttest sync

smarttest scan
smarttest impact
smarttest explain
smarttest graph

smarttest run
smarttest run --affected
smarttest run --all

smarttest watch

smarttest generate
smarttest coverage
smarttest report

smarttest rules
smarttest snapshot
smarttest vcs

smarttest ai
smarttest autopilot

smarttest studio

26.3. Interactive Root Command #

Running:

smarttest

Should display an interactive menu.

Example:

SMARTTEST

Workspace: my-project
Status: Ready

> Run affected tests
  Open SmartTest Studio
  Generate test architecture
  AI Test Assistant
  Coverage and reports
  Project diagnostics
  Settings

↑↓ Navigate   Enter Select   / Search

26.4. Common Flags #

Where relevant:

--dry-run
--json
--quiet
--verbose
--non-interactive
--output
--config
--workspace
--profile
--help

26.5. CLI Output Requirements #

26.6. Exit Codes #

Define stable categories for:

The exact numeric mapping should be documented and versioned.

27. Plugin SDK and Multi-Language Support

27.1. Objective #

Allow SmartTest to expand without rebuilding its core.

27.2. Plugin Categories #

27.3. Test Runner Adapter #

interface TestAdapter {
  id: string;

  discover(): Promise<TestCase[]>;

  execute(selection: TestSelection, options: ExecutionOptions): Promise<TestRunResult>;

  collectCoverage?(): Promise<CoverageArtifact>;

  getCapabilities(): TestAdapterCapabilities;
}

27.4. Language Adapter #

interface LanguageAdapter {
  language: string;

  analyze(files: string[]): Promise<SymbolGraph>;

  findTestTargets(symbol: SourceSymbol): Promise<TestTarget[]>;
}

27.5. Adapter Capabilities #

Adapters must declare:

Unsupported capabilities must not be silently emulated inaccurately.

27.6. Language Expansion #

JavaScript / TypeScript #

Initial implementation.

Python #

pytest adapter and Python source analysis.

Java #

JUnit integration and Java source analysis.

Go #

go test integration and Go source analysis.

Additional Languages #

C#, PHP, Rust, Kotlin, and others based on demand.

27.7. Cross-Language Analysis #

Future versions should support dependencies across languages and service boundaries.

Examples:

Cross-language relationships must be based on detectable contracts, configuration, or explicitly declared mappings.

28. SmartTest Cloud — Commercial Platform

28.1. Objective #

Provide paid collaboration and organization-wide intelligence while keeping the local core valuable and accessible.

28.2. Cloud Features #

Project Management #

Test Analytics #

Pull Request Intelligence #

Shared Execution Infrastructure #

AI Collaboration #

28.3. Organization Data Model #

Organization
├── Members
├── Roles
├── Policies
├── Subscriptions
└── Workspaces
    └── Projects
        └── Repositories
            └── Branches
                └── Commits
                    └── TestRuns
                        ├── TestExecutions
                        ├── CoverageSnapshots
                        ├── ImpactDecisions
                        └── Reports

28.4. Example API #

POST /v1/runs

GET /v1/runs/:id

GET /v1/projects/:id/metrics

GET /v1/projects/:id/coverage

GET /v1/projects/:id/impact

GET /v1/projects/:id/flaky-tests

POST /v1/impact/analyze

POST /v1/reports

GET /v1/organizations/:id/usage

28.5. Enterprise Capabilities #

28.6. Data Minimization #

Cloud operation should prefer:

Uploading full source code should not be required for standard reporting features.

29. Business Model and Monetization

29.1. Strategy #

Use an Open Core + SaaS model.

The open-source engine creates adoption and developer trust.

The commercial service monetizes collaboration, organization-wide analytics, and advanced infrastructure.

29.2. Proposed Pricing #

PlanProposed PriceTarget
CommunityFreeIndividual developers
Team$12/developer/monthSmall teams
Business$29/developer/monthEngineering organizations
EnterpriseCustomLarge companies

Pricing is an initial commercial hypothesis and must be validated with customers.

29.3. Community Edition #

Include:

29.4. Team Edition #

Include:

29.5. Business Edition #

Include:

29.6. Enterprise Edition #

Include:

29.7. Commercial Value #

SmartTest should sell measurable improvements:

29.8. Go-to-Market #

Primary channels:

29.9. Adoption Strategy #

  1. Publish a genuinely useful free CLI.
  2. Demonstrate reliable savings on representative repositories.
  3. Make installation exceptionally simple.
  4. Offer impressive local reports and Studio.
  5. Encourage CI adoption.
  6. Introduce commercial team features.
  7. Expand to additional language ecosystems.

30. Security and Privacy

30.1. General Requirements #

SmartTest operates on developer repositories and may execute arbitrary project tests.

It must therefore assume repository content, plugins, test results, and generated code can be untrusted.

30.2. Local Security #

30.3. AI Security #

30.4. Studio Security #

30.5. Cloud Security #

30.6. Supply Chain Security #

31. Performance Requirements

31.1. Philosophy #

Performance is a core product feature.

SmartTest must measure its own overhead and avoid expensive analysis when the expected benefit is smaller than the cost.

31.2. Optimization Techniques #

31.3. Initial Performance Targets #

Targets must be evaluated under explicitly defined benchmark conditions.

OperationInitial Target
Warm CLI startupUnder 300 ms
Simple diff analysis with warm indexUnder 500 ms
Warm graph selectionUnder 200 ms
Standard report generationUnder 2 seconds
Small-project overheadBelow 10% where feasible
End-to-end savings on suitable suitesTarget 30–80%

These are aspirational engineering targets, not guaranteed results.

31.4. Performance Observability #

Measure:

31.5. Adaptive Performance Policy #

If selective execution is slower than a full run for a specific workload, SmartTest should recommend or automatically use an appropriate fallback within the configured policy.

32. Reliability and Correctness

32.1. Reliability Goals #

32.2. Critical Correctness Rules #

SmartTest must never:

32.3. Testing Strategy #

SmartTest itself requires:

32.4. Shadow Mode #

Provide a validation mode that executes both:

Compare the outcomes to detect incorrect exclusions.

Shadow Mode should be a key feature during early adoption and on customer pilot repositories.

33. Metrics and KPIs

33.1. Technical KPIs #

33.2. Correctness KPIs #

33.3. Test Quality KPIs #

33.4. Developer Experience KPIs #

33.5. Commercial KPIs #

34. Engineering Backlog

For v1.0.0 these spec items are decomposed into user stories in ../planning/foundation/epics/.

Epic A — Core Project Foundation #

Acceptance Gate: Core packages build and test independently.

Epic B — Smart Init #

Acceptance Gate: Supported repositories can be initialized safely with minimal manual configuration.

Epic C — Adaptive Configuration #

Acceptance Gate: Existing test architecture and valid history survive supported project changes.

Epic D — Version Control and Snapshots #

Acceptance Gate: All adapters produce consistent normalized changes within their declared capabilities.

Epic E — Source Intelligence #

Acceptance Gate: Known source fixtures produce expected symbols and relationships.

Epic F — Dependency Graph #

Acceptance Gate: Dependency queries are reproducible and benchmarked.

Epic G — Impact Engine #

Acceptance Gate: No known reproducible failing test is missed in the defined validation fixtures.

Epic H — Test Architecture Generator #

Acceptance Gate: Generation is repeatable and does not overwrite user content by default.

Epic I — Rules Engine #

Acceptance Gate: Rule evaluation is deterministic and explainable.

Epic J — Test Execution and Cache #

Acceptance Gate: Native runner results and SmartTest results remain consistent.

Epic K — Tracing and Coverage #

Acceptance Gate: Coverage reports accurately describe collection scope and granularity.

Epic L — AI Provider Manager #

Acceptance Gate: Custom compatible endpoints can be configured without hardcoded provider assumptions.

Epic M — AI Test Engineering #

Acceptance Gate: Proposed tests are validated and cannot silently replace existing behavior.

Epic N — SmartTest Studio #

Acceptance Gate: Core testing workflows can be completed from the Studio without a Cloud account.

Epic O — Reporting #

Acceptance Gate: Reports are accurate, portable, and clear about skipped, cached, and executed tests.

Epic P — CI/CD #

Acceptance Gate: CI integration remains deterministic and secure.

Epic Q — Cloud SaaS #

Acceptance Gate: Multi-tenant isolation, billing accuracy, and operational cost controls are verified.

Epic R — Performance and Reliability #

Acceptance Gate: Performance claims are reproducible under documented conditions.

Epic S — Ecosystem Expansion #

Acceptance Gate: New languages can be added through documented plugin contracts without rewriting the core engine.

35. Release Roadmap

Release 0 — Foundation #

Deliverables:

Release 1 — Intelligent npm MVP #

Deliverables:

Release Goal: A reliable, useful npm package that reduces unnecessary tests and organizes test architecture.

Release 2 — Advanced Intelligence #

Deliverables:

Release Goal: Stronger selection accuracy, better performance, and continuous project adaptation.

Release 3 — AI Test Engineering #

Deliverables:

Release Goal: Optional AI assistance for test creation and maintenance.

Release 4 — SmartTest Studio #

Deliverables:

Release Goal: A unified interactive developer experience across testing workflows.

Release 5 — Commercial Cloud #

Deliverables:

Release Goal: Recurring revenue through collaborative testing intelligence.

Release 6 — Multi-Language Platform #

Deliverables:

Release Goal: A language-independent testing intelligence platform.

Release sequencing may be adjusted based on technical dependencies, benchmark results, and customer validation.

36. Definition of Done

A feature is considered complete only when:

37. Key Technical Risks

Risk 1 — Missed Regressions #

An incomplete dependency model may exclude tests that could detect failures.

Mitigation: Hybrid analysis, mandatory rules, conservative fallbacks, Shadow Mode, and periodic full-suite execution.

Risk 2 — Analysis Overhead #

The analysis engine may cost more than the test time it saves.

Mitigation: Incremental analysis, caching, benchmarks, and adaptive execution policies.

Risk 3 — Framework Compatibility #

Some frameworks may not expose sufficiently precise tracing or selection APIs.

Mitigation: Capability-aware adapters and explicit granularity fallback.

Risk 4 — Poor AI-Generated Tests #

Generated tests may pass while failing to validate meaningful behavior.

Mitigation: Compilation, execution, assertion analysis, coverage checks, and optional mutation testing.

Risk 5 — VCS Complexity #

Different VCS providers have different revision and workspace semantics.

Mitigation: Explicit provider capabilities, normalized changes, and careful baseline reconciliation.

Risk 6 — Cloud Cost #

Storage, remote execution, and AI services may reduce margins.

Mitigation: Data minimization, usage limits, retention policies, and cost-aware architecture.

Risk 7 — Market Competition #

Existing test frameworks and CI platforms already provide affected-test selection and caching.

Mitigation: Differentiate through semantic intelligence, source-aware test generation, universal configuration, explainability, adaptive setup, and unified tooling.

Risk 8 — Developer Trust #

Teams may be reluctant to skip tests using a new tool.

Mitigation: Transparent reports, reproducible benchmarks, Shadow Mode, and safe adoption workflows.

38. Product Success Criteria

38.1. Technical Success #

SmartTest should demonstrate:

38.2. Developer Success #

Developers should be able to:

38.3. Commercial Success #

The platform should demonstrate:

39. Final Product Positioning

SmartTest is not simply a faster test runner.

It is an intelligent testing layer connecting source code, version history, dependencies, test execution, coverage, quality policies, and optional AI assistance.

Its main product pillars are:

1. Smart Init #

Understand and configure a project automatically.

2. Universal Change Intelligence #

Analyze modifications across Git, SVN, other VCS providers, and native snapshots.

3. Semantic Impact Analysis #

Determine which parts of the software may be affected by code changes.

4. Intelligent Test Selection #

Execute relevant tests while respecting correctness and safety requirements.

5. Automatic Test Architecture #

Generate and maintain consistent test organization based on source structure and developer rules.

6. AI Test Engineering #

Generate, audit, repair, and improve tests using configurable AI providers.

7. SmartTest Studio #

Provide a modern visual interface for test development, execution, debugging, and analysis.

8. Coverage and Quality Intelligence #

Identify gaps, weak tests, unstable suites, and unprotected behavior.

9. Open Ecosystem #

Support additional languages, frameworks, test runners, and version-control systems through plugins.

10. Commercial Cloud #

Deliver collaboration, historical intelligence, CI optimization, governance, and enterprise capabilities.

40. Final Product Objective

The long-term ambition is to make SmartTest a universal testing intelligence platform that can be introduced into almost any software project, automatically understand its structure, adapt to its environment, and continuously improve the way tests are organized, selected, executed, and maintained.

The user experience should ultimately be as simple as:

npm install -D @tkmremi/smarttest

npx smarttest init

npx smarttest run --affected

npx smarttest studio

With optional AI:

npx smarttest ai setup

npx smarttest ai generate-tests --changed

npx smarttest ai audit --coverage

npx smarttest autopilot

Final vision: SmartTest should make software testing faster, more intelligent, more maintainable, and easier to understand without forcing developers to abandon their existing tools.

Product mission: Test less when it is safe. Test better everywhere. Know exactly why.

Architecture recommendation: Start with the fully automatic setup, semantic dependency graph, safe test selector, configurable test generator, and Jest/Vitest integration. These form the technical foundation that every other feature—including AI, the Studio, and the commercial Cloud—will depend on.

The SmartTest name and npm package availability still need verification before publication; the specification uses SmartTest as the working product name.

Edit this page on GitHub