openharmony-ut_skill

Overview

This skill automates OpenHarmony unit test and fuzz test workflows including test generation, compilation, deployment to devices, and execution. It collects project and environment configuration, validates device connectivity, and runs an end-to-end pipeline from building tests to executing them on a target OpenHarmony device. Use it to reliably run or generate UT/FuzzTest artifacts and gather results.

How this skill works

On first use the skill prompts for core configuration: project root, output path, build command template, and Windows IP for hdc. It validates connectivity by pinging the Windows host, checking port 8710, listing devices via hdc, and performing a shell echo to confirm hdc shell access. Depending on user intent, it either locates existing build artifacts and deploys them, or generates test code, builds the target, deploys to /data/test on the device, and executes the binary while collecting output.

When to use it

• You need to run existing OpenHarmony UT or fuzz tests on a device.
• You want an automated flow to compile, deploy, and execute tests.
• You are generating new unit/fuzz tests that must match BUILD.gn targets.
• You need repeatable connectivity and device validation before running tests.
• You want a safe flow that prefers using prebuilt artifacts when available.

Best practices

• Provide correct OH_ROOT and OH_OUTPUT paths and keep BUILD_CMD template up to date.
• Always run the connectivity validation steps (ping, port, list, shell) before deployment.
• Name generated tests to match BUILD.gn targets and place them in the module tests directory.
• Follow OpenHarmony HWTEST_F style; avoid GoogleTest main and avoid magic numbers.
• Prefer the 'only run' flow when user intent is to execute existing cases to save build time.

Example use cases

• Run an existing fuzz test binary found under ${OH_OUTPUT} by deploying to /data/test and executing it.
• Generate a new HWTEST_F unit test, build with the specified BUILD_CMD, deploy to device, and run until passing.
• Validate a new device connection by running the ping, nc, hdc list, and hdc shell checks before automated runs.
• Automate nightly test runs that find latest compiled targets and execute them on connected devices.
• Diagnose deployment failures by following the automated checks and then re-deploying only the failing target.