Related tests

From a code relationship to a checkable behavior

Related tests help identify test source associated with the selected entity. A test can provide a concrete example of intended behavior, but the association itself says little about assertion quality or coverage.

Use the Impact inspector

1. Select the module or symbol being investigated.

2. Open the Impact tab and choose “Related tests”, or use the “Show related tests” action.

3. Open a returned test and read its setup, invocation and assertions.

4. Run the appropriate checks in the project’s own test environment and record what they establish.

// An illustrative test, not a recorded execution result.
import { test } from 'node:test';
import { strict as assert } from 'node:assert';
import { validateOrder } from '../src/validation';

test('rejects an order with no total', () => {
  assert.throws(() => validateOrder({ id: 'order-1', total: 0 }));
});

Recognized TypeScript and JavaScript test runners

Explorer recognizes four test-runner families through supported imports and source patterns within its TypeScript/JavaScript analysis:

• Playwright: @playwright/test or playwright/test.

• Vitest: vitest.

• Jest: @jest/globals.

• Node test runner: node:test.

Imported aliases and supported declarations retain their source identity. Unbound globals, arbitrary reexports, generated test titles and dynamic mocks are not universally resolved. These four families do not add four framework adapters and do not imply that tests were executed, assertions passed or runtime coverage was measured.

Understand language and analysis limits

Interpret an empty or partial result

An empty list means the current query did not return an association. It does not mean that no tests exist. Naming, test structure, unsupported semantics and view limits can affect discoverability. The current example below reports zero indexed associations and one possible test. These are different evidence categories; neither establishes test execution or coverage.

Read the evidence behind a candidate

In the shown commerce-platform example, a query for checkout returns one possible test through a Calls relationship. The engine distinguishes compiler test metadata or explicit test relationships from heuristic candidates reached through dependency paths and conventional test-file names.

This fixture is a static-source example. Its exported checks were not executed by the graph query, and the function name alone is not a passing result. Read the assertion, run the relevant runner in the actual project, and keep its observed result separate from the relationship.

// tests/checkout.test.ts — source inspected by the graph
import { checkout } from '../src/checkout-service';

export function checkoutCreatesPaidOrder() {
  const order = checkout('order-1042');
  if (order.status !== 'paid') throw new Error('Expected a paid order');
}
// Finding this function does not execute it.