Skip to Content
TemplatesSolution tests

Solution tests

A full-page composition for managing UiPath Solution Tests — test cases, batch runs, a KPI score trend, run-result baselines, and adopt / update / remove actions. The view is domain-neutral: it reads the generic UiPathST* Solution Test entity collections from your vs-core solution and is parameterized for the subject entity (loans, claims, invoices, …) through SolutionTestsConfig. Intended to render inside an ApolloShell.

Composition

In production, render the smart SolutionTests container inside a SolutionTestsProvider; it reads the UiPathST* collections from your vs-core solution through the collection-backed hooks. The preview above is instead a presentational demo — it renders the dumb SolutionTestsView (and the dumb expanded views) with in-memory mock data and no-op handlers, so it never touches the hooks or vs-core. From top to bottom the view stacks:

  • PageHeader — title and the “Run all” action.
  • KPI bar — cards plus a recharts score-trend chart across recent runs.
  • Tabs — Test cases (list, enable/disable, run, delete) and Test runs (batch runs backed by live queries, per-run results, force-stop).
  • Dialogs — run details, JSON viewer, and delete confirmation, plus the expected-vs-actual baseline adopt / update / remove flows.

Source: templates/SolutionTestsTemplate.tsx

Installation

npx shadcn@latest add @uipath/solution-tests

Requires @uipath/vs-core ^2.0.4. The container reads the Solution Test collections from the dedicated, name-keyed solution.api.collections.solutionTests namespace introduced in vs-core 2.x. Install vs-core per its README — it brings its own peers (@tanstack/db, @tanstack/query-db-collection, @tanstack/react-query, @uipath/uipath-typescript). The component itself pulls @tanstack/react-db (for useLiveQuery), @tanstack/react-table, @tanstack/react-router, recharts, sonner, and react-i18next.

The Solution Test entities (UiPathST*) are generic across verticals, so the only per-vertical customization most consumers need is their vertical’s subjectColumns. The smart SolutionTests container reads its data from your vs-core Solution Test collections — the name-keyed solution.api.collections.solutionTests set (UiPathSTTests, UiPathSTBatchRuns, UiPathSTRuns, UiPathSTJobs, UiPathSTRunResults) — via the collection-backed hooks, so your only data responsibility is to make sure those collections exist on your solution. Wrap <SolutionTests /> in a <SolutionTestsProvider> with your presentation config.

Reads are live the moment the collections exist. Writes (run, delete, force-stop, adopt/update/remove baseline, attachment reads) are supplied through the provider’s actions prop — omit it for a read-only view (invoking a write then throws). For the standard UiPath Solution Test framework, createSolutionTestActions builds the whole write surface from a handful of values you already have, so you don’t reimplement the trigger/auth plumbing:

"use client";
 
import {
  SolutionTests,
  SolutionTestsProvider,
  createSolutionTestActions,
  type SolutionTestsConfig,
} from "@/components/ui/solution-tests";
 
const config: SolutionTestsConfig = {
  subjectColumns, // the only per-vertical customization
  subjectNoun: { singular: "Loan", plural: "Loans" },
  showInputs: true,
};
 
// Writes POST to the Solution Test API triggers
// (`/{org}/{tenant}/orchestrator_/t/{folderKey}/{slug}`); toggle + attachments
// go through your entity data access. All values below are deployment config
// you already hold — no custom service required.
const actions = createSolutionTestActions({
  orgName: env.UIPATH_ORG_NAME,
  tenantName: env.UIPATH_TENANT_NAME,
  folderKey: env.UIPATH_SOLUTION_FOLDER_KEY,
  getToken: () => tokenService.getCurrentToken(),
  updateEntity: (entity, id, patch) => dataFabric.updateEntity(entity, id, patch),
  getAttachment: (entity, id, field) => dataFabric.getAttachment(entity, id, field),
});
 
export default function SolutionTestsPage() {
  // Reads come from the vs-core solution's `collections.solutionTests` in
  // context (provided higher up by your shell). No read wiring required.
  return (
    <SolutionTestsProvider config={config} actions={actions}>
      <SolutionTests />
    </SolutionTestsProvider>
  );
}

If your backend deviates from that contract, pass your own object implementing SolutionTestsActions instead of calling createSolutionTestActions.

The exported dumb SolutionTestsView takes all data + callbacks via props if you prefer to supply your own data plumbing or render the view against a mock (as the preview does).

Customizing

  • Subject columns — config.subjectColumns injects your vertical’s columns between Test Name and Version; config.getSubjectHref turns the test name into a link to the subject. This is normally the only required config.
  • Data source — the smart SolutionTests container reads the UiPathST* collections from solution.api.collections.solutionTests (vs-core 2.x) via the collection-backed hooks in hooks.ts; just ensure those collections exist on your solution. Reads are reactive (live queries); writes come from the provider’s actions (see Installation — createSolutionTestActions or your own SolutionTestsActions).
  • Subject noun — config.subjectNoun (a singular / plural pair) drives the subject-flavored KPI card (e.g. “Loans passing”), the runs “passed” column, and the run-results dialog title; omit it for generic “Tests” wording.
  • Labels & status — config.evaluatorLabels maps evaluator ids to display names; config.statusLabels overrides the numeric status enums (e.g. with localized labels).
  • Thresholds & polling — passThreshold (default 0.9) governs both the evaluator pass color and the KPI trend reference line; pollIntervalMs (default 5000) while runs are active; showInputs toggles the expected/actual input panels in run-result details.
  • i18n — framework strings use react-i18next; wrap your app in ApolloShell (which initializes i18n via LocaleProvider) or provide your own I18nextProvider.
Last updated on
SettingsIn-product