Run SkyWalking unit tests, integration tests, or the separate slow integration test using commands aligned with CI. Select a test group or module, and use the documented naming and tagging conventions to understand which tests run in each phase.
Run unit tests, integration tests, or slow integration tests matching CI. Use to validate changes before submitting a PR.
Run score Not tested
See how to installThis skill explains how to run SkyWalking unit tests, integration tests, and slow integration tests with commands aligned with CI. With no argument or unit, run unit tests; choose integration for integration tests that exclude slow tests, or slow for the slow test group. You can also name a module to run tests for that module. The guide covers test naming patterns, Maven phases, and the @Tag("slow") classification so you can tell which tests each command includes.
Use it to validate changes with the same test groups used by CI before submitting a PR. It is also useful when you want to check one module before running the full suite, or run Elasticsearch/OpenSearch integration tests that are excluded from the regular integration job.
The commands use Maven Wrapper. CI test groups have different JDK and operating system conditions. The guide advises investigating local failures instead of relying on CI retries.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Run tests matching CI configuration.
unit or no argument — unit tests./mvnw clean test -q -B -D"checkstyle.skip"
CI runs this on:
integration — integration tests (excludes slow)./mvnw -B clean integration-test -Dcheckstyle.skip -DskipUTs=true -DexcludedGroups=slow
CI runs this on JDK 11, 17, 21, 25 (ubuntu only).
slow — slow integration tests./mvnw -B clean integration-test -Dcheckstyle.skip -DskipUTs=true \
-Dit.test=org.apache.skywalking.library.elasticsearch.ElasticSearchIT \
-Dfailsafe.failIfNoSpecifiedTests=false
CI runs on JDK 11 (ubuntu only). Currently only ElasticSearch/OpenSearch IT is in the slow matrix.
# Unit tests for a specific module
./mvnw clean test -pl oap-server/analyzer/<module-name> -D"checkstyle.skip"
# Integration tests for a specific module
./mvnw -B clean integration-test -pl oap-server/analyzer/<module-name> -Dcheckstyle.skip -DskipUTs=true
org.junit.jupiter)| Type | Pattern | Maven phase |
|---|---|---|
| Unit tests | *Test.java | test |
| Integration tests | IT*.java or *IT.java | integration-test |
Tests tagged with @Tag("slow") are excluded from the normal integration-test job and run separately in the slow-integration-test job. Use this tag for tests that spin up external services (Elasticsearch, etc.) and take significant time.
All three CI jobs retry on failure (run the same command twice with ||). This handles flaky tests but masks intermittent issues — if a test fails locally, investigate rather than relying on retries.
CI workflow: .github/workflows/skywalking.yaml
| Job | JDK | OS | Timeout |
|---|---|---|---|
unit-test | 11 (3 OS) + 17, 21, 25 (ubuntu) | ubuntu, macOS, Windows | 30 min |
integration-test | 11, 17, 21, 25 | ubuntu | 60 min |
slow-integration-test | 11 | ubuntu | 60 min |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use this skill to investigate failed end-to-end tests in GitHub Actions. It downloads the run’s log artifacts, checks OAP and other component logs for errors, and summarizes the likely root cause, including failures in standalone test tools.
Validate SkyWalking OAP changes by building the backend or full project and running Javadoc and Checkstyle checks. Choose commands for a full CI-style build, a faster backend build, one check, or a single module before submitting a pull request.
Compile SkyWalking DSL scripts for MAL, OAL, LAL, or Hierarchy and save the generated .class files for inspection. Choose one DSL or generate classes for all four, then locate the output and use javap to examine bytecode.
Prepare a pull request branch by running the documented build, style, license-header, and Java import checks, then committing and pushing the changes. If the branch has no pull request yet, create one using the project template.
Check whether source files carry the required Apache 2.0 headers and whether the dependency license file matches current dependencies. Use the provided commands to fix headers or regenerate the license list, then review any changes before submitting a pull request.
Plan how to add a monitoring target or layer to SkyWalking OAP. The guide maps signals such as metrics, logs, and spans to extension points, and identifies related layer registration, UI templates, documentation, and local verification work.