Guide 01

Discovery Engine

Discovery is the first step in the TestOps pipeline. It connects to your codebase via SSH, scans every file, and uses AI to build a complete inventory of your application's features, endpoints, models, and integrations.

01

What is Discovery

Discovery uses a two-pass architecture to understand your codebase at both a structural and semantic level.

Pass 1 — Structural Scanning

TestOps connects to your server over SSH and walks the project directory tree. It identifies files by extension and path convention, detecting API route files, database models, service modules, configuration files, and existing test files. This pass is fast and deterministic — it builds a complete file map without reading every line of code.

Pass 2 — Semantic Analysis

Using Claude Code running directly on the server, TestOps reads the files identified in Pass 1 and extracts meaning. It understands business rules, authentication patterns, data validation logic, inter-service dependencies, and data flows between components. This is what allows TestOps to generate tests that go beyond surface-level coverage — it knows why code exists, not just that it exists.

The result is a structured feature inventory stored as a snapshot. Every subsequent discovery run is compared against the previous snapshot to track changes over time.

02

How to Run Discovery

There are two ways to trigger a discovery run:

Manual Discovery

  1. 1.Navigate to Projects in the sidebar and select your project.
  2. 2.Click the Run Discovery button in the project header. TestOps will connect to the configured environment via SSH.
  3. 3.Wait for the run to complete. Progress is shown in real time. A typical discovery takes 1–5 minutes depending on codebase size.

Scheduled Discovery

Discovery can also be triggered as part of a scheduled run. When you configure a schedule (see the Scheduling guide), you can choose to run discovery before test execution. This keeps your feature inventory up to date automatically.

Prerequisite: Your project must have a configured environment with valid SSH credentials (host, user, key) and a correct project path. If SSH access fails, discovery will report a connection error before scanning begins.

03

What Gets Discovered

Discovery extracts a comprehensive map of your application. Here is what each category includes:

Endpoints

API routes (REST and GraphQL), page routes, middleware, and webhook handlers. Each endpoint records its HTTP method, path, request/response shape, and any authentication requirements.

Models

Database schemas, ORM models, and entity definitions. Discovery captures field names, types, relationships (foreign keys, join tables), validations, and default values.

Services

Business logic modules, utility classes, and helper functions. The semantic pass identifies what each service does, which models it touches, and which endpoints call it.

Integrations

Third-party services like SendGrid, Stripe, AWS S3, Twilio, and others. Discovery detects SDK imports, API key references, and configuration patterns to build a map of external dependencies.

Auth Patterns

Authentication and authorization flows including JWT handling, session management, role-based access control (RBAC), API key validation, and OAuth integrations. These patterns directly inform what auth-related tests need to be generated.

Environment Variables

Referenced environment variables across the codebase, drawn from .env files, config modules, and inline references. This helps identify configuration-dependent behavior that needs test coverage.

Existing Tests

Any test files already in the codebase, including their framework (Jest, Pytest, xUnit, etc.), what they cover, and how they are organized. This data is critical for gap analysis — TestOps needs to know what is already tested before it can tell you what is missing.

04

The Feature Inventory

Once discovery completes, the results are displayed as a feature inventory on your project page. This inventory is the single source of truth for everything TestOps knows about your application.

Each feature in the inventory includes:

  • Type— Endpoint, Model, Service, Integration, or Auth pattern.
  • File location— The exact file path and line range where the feature is defined.
  • Related components— Other features this one depends on or is depended upon by.
  • Semantic summary— An AI-generated plain-language description of what the feature does.

The feature inventory is the foundation for everything that follows. Gap analysis reads it to determine what is untested. Test generation reads it to understand what tests to write. Without a complete inventory, downstream steps cannot produce accurate results.

05

Snapshot Diffing

Every discovery run produces a snapshot — a point-in-time record of your application's feature inventory. When you run discovery again, TestOps automatically compares the new snapshot with the previous one.

The diff highlights three categories of change:

+ AddedNew endpoints, models, services, or integrations that did not exist in the previous snapshot. These are candidates for new test generation.
~ ModifiedFeatures that existed before but have changed — new fields on a model, updated validation logic in a service, or a changed response shape on an endpoint. Existing tests for these features may need to be regenerated.
− RemovedFeatures that no longer exist in the codebase. Tests targeting removed features will fail and should be cleaned up.
Snapshot Diff — v12 vs v11
─────────────────────────────────
+ POST /api/invoices/bulk-send     (new endpoint)
+ InvoiceTemplate model            (new model)
~ PATCH /api/users/:id             (added "avatar" field)
~ PaymentService                   (updated Stripe webhook handler)
- GET /api/legacy/reports          (endpoint removed)

Snapshot diffing makes it practical to keep your test suite in sync with a rapidly changing codebase. Instead of re-analyzing everything, you focus on what actually changed.

06

Supported Frameworks

Discovery adapts its scanning strategy based on the framework configured for your project. Each framework has its own conventions for file structure, routing, and model definitions, and TestOps knows how to interpret them.

Next.js

App Router and Pages Router. API routes, server actions, middleware, and React Server Components.

.NET / ASP.NET Core

Controllers, Entity Framework models, Razor Pages, Minimal APIs, and dependency injection registrations.

Python / Django

Views, URL patterns, Django ORM models, serializers, management commands, and Celery tasks.

Python / Flask

Blueprints, route decorators, SQLAlchemy models, and Flask-RESTful resources.

Go

HTTP handlers, Gorilla/Chi/Gin routers, GORM models, and gRPC service definitions.

More

Additional frameworks are added regularly. If your stack is not listed, Discovery still runs a general-purpose scan using the semantic analysis pass.

07

Tips for Better Discovery

  • Run after major code changes. Merging a large feature branch, adding a new integration, or restructuring your API are all good triggers for a fresh discovery run.
  • Keep project settings accurate. The framework, language, and git branch configured on your project tell Discovery where to look and what conventions to expect. Incorrect settings can lead to incomplete scans.
  • Check the SSH connection first. If discovery fails immediately, verify that the environment SSH credentials are valid and the project path exists on the server.
  • Review the diff, not just the inventory. Snapshot diffing is the fastest way to see what Discovery found that is new or changed. Use it to prioritize which features need tests next.
  • Schedule discovery for continuous coverage. Pair discovery with a scheduled run so your feature inventory stays current without manual effort. See the Scheduling guide for details.