Skip to main content

n3Plugins Build and Validation Matrix

Validation should be proportional to the change.

A full build is not a substitute for focused validation, and focused validation is not always a substitute for integration coverage.

1. Command Syntax​

Windows​

.\gradlew.bat <task> --console plain

Linux / Cloud Workspaces​

./gradlew <task> --console plain

Use --no-daemon when isolation or CI-style reproducibility helps.

2. Validation Levels​

Level 0: Read-only investigation​

Use when no source changed.

Typical validation:

source inspection
reference tracing
Git diff/status confirmation
upstream verification when needed

Do not run ceremonial builds.

Level 1: Documentation/config-only change​

Validate:

syntax/format where applicable
paths/references
git diff

Run code builds only when configuration affects build behavior.

Level 2: Localized implementation change​

Validate:

targeted compile
focused tests
affected package/module behavior
final diff

Level 3: Shared SDK/infrastructure change​

Validate:

focused unit tests
affected consumer tests
compile/test aggregate
broader regression coverage

Examples:

Api.actions
sdk.walker
sdk.workflow
sdk.widgets
sdk.client
shared packet/runtime infrastructure

Level 4: Revision/packet-sensitive change​

Validate:

focused mapping/revision analysis
reference artifact compatibility
menu-action resolver and cache tests when native dispatch changes
unit tests
compile/build
live-client verification when available

Static success alone does not prove live packet correctness.

3. Common Commands​

Focused tests:

./gradlew test --tests '<test class or pattern>' --console plain

All tests:

./gradlew test --console plain

Build:

./gradlew build --console plain

Use repository-specific verification tasks when the changed subsystem defines them.

Inspect available tasks rather than inventing task names:

./gradlew tasks --console plain

4. Test Standards​

Follow repository versions and conventions.

Default expectations:

JUnit 4-compatible tests
Mockito 4.11-compatible techniques
deterministic state-based assertions

Do not introduce unsupported test APIs because newer examples online use them.

Avoid static mocking approaches unavailable to the repository's configured Mockito setup.

Prefer dependency seams and real abstractions.

5. What to Test​

Test observable specifications.

Good:

action rejects invalid state
workflow transitions after confirmed event
walker selects expected transport
widget resolver handles missing state
specialized and generic walker transports resolve the correct target kind and
wait for observed destination arrival; issued-action clipboard output remains
opt-in and failure-safe
InteractionResult communicates failure
logout resets transient state

Weak:

private helper returned what its implementation hard-codes

Do not create tests to inflate coverage.

6. Validation Reporting​

Report what ran.

Good:

Validation:
- ./gradlew test --tests '...'
- ./gradlew compileJava
- final diff inspected

Live client verification: pending

Bad:

Everything should work.

Never claim:

  • build success when only compilation ran,
  • live behavior when only tests ran,
  • packet correctness from static code inspection.