WKND: Unit Testing

What you can actually unit test

Sling Models are ordinary Java, so they are testable — but they depend on a repository, a resource resolver and request context. AEM Mocks (io.wcm.testing.aem-mock) provides all of that in-memory. No running AEM, no deployment, tests measured in milliseconds.

This is the one chapter of the WKND tutorial with no Adobe video — it is written and code-only. The notes here carry the weight.

AemContext

The JUnit 5 extension AemContextExtension gives you an AemContext: a mock Sling environment with a real (in-memory) JCR, a resource resolver, a request and response, and an OSGi service registry you can populate.

@ExtendWith(AemContextExtension.class)
class BylineImplTest {

    private final AemContext ctx = new AemContext();

    @BeforeEach
    void setUp() {
        ctx.addModelsForClasses(BylineImpl.class);
        ctx.load().json("/com/adobe/aem/guides/wknd/core/models/BylineImplTest.json",
                        "/content");
    }

    @Test
    void getName_returnsAuthoredName() {
        ctx.currentResource("/content/byline");
        Byline byline = ctx.request().adaptTo(Byline.class);

        assertNotNull(byline);
        assertEquals("Jane Doe", byline.getName());
    }

    @Test
    void isEmpty_whenNoOccupations_returnsTrue() {
        ctx.currentResource("/content/empty-byline");
        Byline byline = ctx.request().adaptTo(Byline.class);

        assertTrue(byline.isEmpty());
    }
}

Test content as JSON

ctx.load().json(...) reads a JSON file from the test resources and creates those nodes in the mock repository. The format mirrors what you would get from /content/path.infinity.json on a real instance — so the quickest way to build a fixture is to author the content once, export it, and trim it down.

{
  "byline": {
    "jcr:primaryType": "nt:unstructured",
    "sling:resourceType": "wknd/components/byline",
    "name": "Jane Doe",
    "occupations": {
      "item0": { "occupation": "Writer" },
      "item1": { "occupation": "Photographer" }
    }
  },
  "empty-byline": {
    "jcr:primaryType": "nt:unstructured",
    "sling:resourceType": "wknd/components/byline"
  }
}

Mocking services

Where a model depends on an OSGi service, register a Mockito mock into the context:

ExternalService svc = mock(ExternalService.class);
when(svc.lookup("abc")).thenReturn("result");
ctx.registerService(ExternalService.class, svc);

This is also the moment poor design shows up. A model that is hard to test — because it reaches for a dozen services or does I/O in a getter — is usually telling you it is doing too much.

The Cloud Manager quality gate

Cloud Manager runs SonarQube analysis and test coverage on every production pipeline. The rules that matter in practice:

• Line coverage has a threshold (commonly 50%) below which the gate fails.
• Findings are tiered: Critical failures stop the pipeline; Important ones can be overridden by an authorised user with a justification; Info is advisory.
• Security findings and use of deprecated or forbidden APIs are flagged here.

Unit vs integration tests

• Unit tests (core/src/test) — AEM Mocks, no running instance, milliseconds. The bulk of your testing.
• Integration tests (it.tests) — run against a real AEM instance over HTTP. Slower, for things mocks cannot prove: replication, real servlet behaviour, actual rendering.
• UI tests (ui.tests) — Cypress or Selenium against a browser. Slowest, reserved for critical author journeys.

The pyramid applies: many unit tests, some integration tests, few UI tests. Cloud Manager can run all three, and functional test failures will stop a production deployment.