Apex tests

The Testing group under Dev runs your project's Apex tests against an org and keeps the results with your workspace. Test classes are discovered from your source — every class on your current branch marked @isTest — so the list reflects the branch you are working on, not what happens to be deployed.

Running tests

Dev > Testing > Run Apex Tests lists the test classes in your project with their package and domain. Once a class has been run, its row carries the latest result for your target org: pass or fail, when it ran, and the run's coverage.

Select classes and click Run Tests. The dialog confirms where and how the run executes:

• Target Organization — your target org is preselected; pick any other connected org. The dialog checks the connection live and enables Run Tests only when it passes.
• Coverage Validation — when enabled, the run fails if coverage lands below the Threshold (default 75%).

Beyond selected classes, the dialog can scope a run to a test suite, a domain, or a package — a package run executes all tests in that package. Runs execute in the background, one at a time per org, and the outcome arrives as a notification; the report opens from the result.

Each executed class's row expands with actions to view the run's report and to re-run that class.

Test suites

Dev > Testing > Test Suites groups tests you run together — a smoke set for a package, everything in a domain, or a hand-picked list of classes. Suites are stored in your repository, so they are versioned and shared with the team like any other configuration.

Create Suite walks three steps — name, selection criteria, review. The criteria select tests from packages, domains, and specific test classes, and can add optional tags. The review step shows the resulting configuration as YAML before it is written.

Run on a suite card opens the same run dialog with the suite preselected. Edit reopens the wizard to change the criteria — deleting a suite is done from the edit dialog.

Deploying packages with a suite

Deploy with packages in the create and edit dialogs binds a suite to packages. When a bound package deploys Apex, it runs exactly the tests of its suites, instead of the tests the package would run by default, unless one of the settings listed below takes precedence. A package bound to several suites runs the tests of all of them. Suite cards list their bound packages under Deploys with.

Use a binding when the tests that cover a package live outside it — for example, a service package tested by a separate test package. Salesforce then requires every Apex class and trigger the package deploys to reach 75% coverage from the suite's tests alone. Validation of a pull request applies the same rule, so a suite that does not cover the package fails the pull request rather than the release.

• Only source and diff packages can be bound, so the picker offers only those. See Optimized installation for the tests a package runs when it is not bound.
• The list of tests is fixed when the package is built. A change to a suite applies from the package's next build.
• isOptimizedDeployment: false on the package, skipTesting (except on a release to a production org), or a test level set explicitly for a deployment takes precedence over a binding.
• A suite cannot have both tags and bound packages. Tags are stored in codev desktop, not in the repository, so a build cannot resolve them. The tags picker is disabled while packages are bound, and the other way round.
• If sfdx-project.json cannot be read, the picker is disabled until it can. Existing bindings are kept when you save.

Local test results

Dev > Testing > Local Test Results is the history of the runs you have executed from this workspace: one row per run with its status, classes, run type, org, and time.

The list is scoped to your current branch and your current target org — switching either changes which runs you see. Clicking a run opens its report: the summary, each test method's outcome and runtime, and code coverage per class.