Testing & Quality Assurance

This section describes how testing is set up in the BaSyx AAS Web UI, how to run tests locally, and what is expected from contributors when adding or changing code.

The Web UI is a frontend application, so the project currently focuses on high-value unit tests (especially for utilities). Broader testing (components, stores, E2E) may be expanded over time.

Testing Philosophy

What is tested today

• Utilities (utils): tests are considered mandatory

• Composables: tests are encouraged when logic is non-trivial

Many composables contain AAS-related logic. Over time, parts of this logic may move into the BaSyx TypeScript SDK, which follows a more strict, SDK-style testing approach.

What is not set up (yet)

• End-to-end tests (E2E)

• Visual regression tests

• System tests against real BaSyx infrastructures

• A dedicated test strategy for stores and UI components

Note

The current test focus reflects a pragmatic tradeoff: this repository is a UI application (not an SDK), and the most critical correctness risks are concentrated in reusable utility logic.

Tooling

The project uses:

• Vitest as the unit test framework

• @vue/test-utils for Vue-related test utilities (as needed)

• @vitest/ui for interactive test runs

• @vitest/coverage-istanbul for coverage reports

The Vitest configuration is defined in vitest.config.mts and reuses the Vite configuration.

Key settings:

• environment: 'jsdom'

• globals: true

• Coverage provider: Istanbul

• Reporters: text, json, html

Coverage output directory:

• ./coverage

Test Location and Naming

Tests are located under:

src/tests/
  utils/
  composables/

Conventions:

• Tests are named after the file they test

• File naming uses the <file-name>.tests.ts suffix

Example:

src/tests/utils/IDUtils.tests.ts

Running Tests

From the aas-web-ui/ directory:

Run all tests

pnpm test

Run tests once (non-interactive)

pnpm test:run

This is the CI-safe variant — equivalent to vitest run. It executes all tests once and exits without entering watch mode.

Run tests in watch mode

pnpm test:watch

Run tests with UI

pnpm test:ui

Run coverage

pnpm test:coverage

This generates coverage reports in:

• coverage/ (HTML, JSON, and text)

CI and Build Integration

Tests are executed as part of the production build checks:

• prebuild runs

  • pnpm lint:check

  • pnpm test:run

  • vue-tsc --noEmit

No minimum coverage threshold is enforced in CI at the moment.

Note

Coverage is currently collected for local insight rather than as a strict quality gate.

Writing Tests

Utilities (Required)

Utility functions should be tested with deterministic, focused unit tests.

A typical pattern in the repository is:

• Prepare input data sets

• Execute the function under test

• Assert predictable outputs and invariants

Example patterns include property-based style iterations (e.g., generating multiple IDs and validating a regex), as used in existing test files.

Composables (Recommended)

Composable tests are recommended when:

• The composable contains meaningful data transformation logic

• The composable implements non-trivial fallback behavior

• The composable performs validation or mapping between AAS types

When a composable depends on Pinia, initialize Pinia explicitly:

import { createPinia, setActivePinia } from 'pinia';

const pinia = createPinia();
setActivePinia(pinia);

Mocking and External Calls

Unit tests must not depend on:

• Real backend services

• External infrastructures

• Live authentication flows

At the moment, backend access is not a primary testing focus in this repository. As backend communication is increasingly handled by the BaSyx TypeScript SDK, testing of API behavior will primarily happen at the SDK level.

Common Pitfalls

Alias Imports

The project uses @/ alias imports. If a test fails due to module resolution issues, ensure:

• The test is executed via the standard scripts (pnpm test, pnpm test:watch, etc.)

• The Vite/Vitest configuration is used (do not run Vitest with custom flags that bypass config)

Summary

• Unit tests are run via Vitest (jsdom)

• Tests live in src/tests/

• Utilities must be tested

• Composable tests are encouraged for non-trivial logic

• No E2E or visual regression setup exists yet

• Coverage reports are generated locally but not enforced in CI