axon-ivy-test

name	axon-ivy-test
description	Entry point for creating and updating tests. Use this skill when user asks to write/update/delete tests.

Step 0: Check Project Setup

Check if src_test/ folder exists and pom.xml has test dependency.

Look for in pom.xml:

<dependency>
  <groupId>com.axonivy.ivy.api.test</groupId>
  <artifactId>ivy-test-api</artifactId>
  <scope>test</scope>
</dependency>

• Not found → Load setup.md to add testing infrastructure. Stop here.
• Found → Proceed to Step 1.

Step 1: Investigate Project Conventions

ALWAYS do this before writing any test. Load investigate.md and follow its steps.

Scan existing tests to discover:

• Naming convention (Test*.java vs *IT.java)
• Package structure under src_test/
• Which annotations are in use (@IvyTest, @IvyProcessTest, @RestResourceTest)
• Existing test infrastructure (RestResourceTest.java, ResourceResponder.java, LoggerAccess.java)
• Existing helpers (*TestClient.java, InMemory*.java, Dummy*.java, Mock*.java)

Record findings for use in subsequent steps.

Step 2: Detect Intent

Determine what the user wants to test by analyzing BOTH the user request AND the target code.

Intent A: Pure Logic / Utility / Parser

Target has no dependency on Ivy runtime, REST, or external APIs. Examples: data parsing, tree building, string formatting, event listeners with injected dependencies.

→ Load unit.md (Pure Unit Test section)

Intent B: Service Using Ivy APIs

Target reads Ivy.var(), accesses CMS, or uses Ivy session — but does NOT call REST or execute processes.

→ Load unit.md (Ivy Unit Test section)

Intent C: Workflow Process / BPM Flow

Target is a .p.json process OR user says "test this process". Does NOT call external APIs.

→ Load process.md

Intent D: Code Calling External REST API (Mocked)

Target calls external APIs (OpenAI, Azure, custom REST) but user wants fast, reliable, offline tests.

→ Load rest.md + mock.md + resource.md + fixture.md → Load combos.md for wiring guidance

Intent E: End-to-End with Real API

User explicitly says "integration test", "e2e", "real API", or target is an *IT.java class.

→ Load integration.md + fixture.md + log.md

Detection Guide

Signal in target code	Intent
No Ivy.* imports, pure Java	A
Ivy.var(), Ivy.cms(), Ivy.session()	B
Xxx.getInstance() static singleton calls (DAO, Service, …)	B (also load singleton-mock.md)
.p.json file or BpmProcess reference	C
@Path, @GET, @POST, REST client calls	D
User says "integration", "e2e", class ends with IT	E

When ambiguous, default to the simpler pattern (A over B, D over E).

Step 3: Load Support Patterns

After loading the primary pattern from Step 2, conditionally load these:

Need	Load
Isolate with fake implementation (interface-based dep)	test-doubles.md
Build complex domain test objects	test-doubles.md (builder section)
Set Ivy variables for test	fixture.md
Mock a Xxx.getInstance() static singleton (DAO, Service, …)	singleton-mock.md
Mock external REST API	mock.md
Load JSON fixture data	resource.md
Assert log messages	log.md
Complex AssertJ chains	assert.md
Combining multiple patterns together	combos.md

Step 4: Apply Project Conventions

Use findings from Step 1 to ensure:

• Class naming matches project convention
• Package placement matches existing test structure
• Reuse existing test infrastructure — do NOT recreate helpers that already exist
• Follow same builder/helper patterns found in sibling tests

Test File Naming & Location

Type	Name	Location
Unit / Process / REST test	Test<ClassName>.java	src_test/<package>/Test<ClassName>.java
Integration test	<ClassName>IT.java	src_test/<package>/<ClassName>IT.java
In-memory test double	InMemory<Interface>.java	src_test/<package>/InMemory<Interface>.java
Dummy provider	Dummy<Interface>.java	src_test/<package>/dummy/Dummy<Interface>.java
Mock handler	<Name>Chat.java	src_test/<package>/mock/<Name>Chat.java

Checklist

• Investigated existing test patterns in the project (Step 1)
• Identified correct test intent (Step 2)
• src_test/ folder exists
• pom.xml has ivy-test-api dependency
• Test class has correct annotation for its type
• Reused existing test infrastructure where available
• Test naming follows project convention
• Loaded all necessary support pattern references