Fork me on GitHub

Overview

BRUT boots an in-memory brXM delivery tier stack for tests. It builds a repository, loads HCM configuration and content, initializes the HST model, then executes the same pipelines used in production (component rendering, JAX-RS, Page Model API).

Module Overview

Module Purpose
brut-common In-memory repository, YAML import, JUnit 5 extensions, auto-detection utilities
brut-resources HST container startup, HCM module loading, request pipelines, PageModel API
brut-components Component test utilities, HST request/response mocks

brut-common

  • In-memory repository and YAML import utilities
  • Repository configuration from repository.xml on classpath
  • Test authentication via in-memory login module

Key Classes

Class Purpose
BrutTestConfigurationException Unified error handling with factory methods
TestConfigurationLogger Consistent configuration logging
TestInstanceInjector JUnit 5 field injection
AbstractBrutRepository Shared CND/namespace handling

brut-resources

  • Loads HCM modules (config + content) via Config Service APIs
  • Initializes the HST container and request pipelines

Bootstrap Components

Class Purpose
ConfigServiceBootstrapStrategy Orchestrates HCM-based bootstrap
RuntimeTypeStubber Stubs missing namespaces/node types
JcrNodeSynchronizer Syncs JCR nodes between trees
ConfigServiceReflectionBridge Reflection access to ConfigService

Request Utilities

Class Purpose
MockHstRequest Extended mock with HTTP session support
RequestBuilder Fluent API for request setup
PageModelResponse Navigation utility for Page Model API responses

brut-components

Component-test utilities and mocks for HST components:

  • @BrxmComponentTest annotation
  • DynamicComponentTest test harness
  • Request/response mocking
  • Component parameter injection

Bootstrap Flow

  1. Register CND node types from configured patterns
  2. Load HCM modules from descriptors or explicit module paths
  3. Build the configuration model and apply namespaces/node types
  4. Import content definitions into the repository
  5. Build the HST model from the repository

Request Flow (Page Model API)


Test -> DynamicPageModelTest -> HST Container -> HST Model/Cache
  |           |                    |                |
  |           |                    |                +--> Resolve sitemap item
  |           |                    |                +--> Resolve channel (preview/live)
  |           |                    |                +--> Resolve component tree
  |           |                    |                         |
  |           |                    |                         +--> Resolve container refs
  |           |                    |                              (hst:workspace/hst:containers)
  |           |                    |                         +--> Build container items
  |           |                    |
  |           |                    +--> Build Page Model JSON
  |           |
  +--> Response JSON (root + page map with $ref links)
        

Request Flow (Component/JAX-RS)


Test -> DynamicComponentTest/DynamicJaxrsTest -> HST Container -> HST Model/Cache
  |                |                               |                |
  |                |                               |                +--> Resolve mount + sitemap item
  |                |                               |                +--> Resolve component tree
  |                |                               |                +--> Build request context
  |                |                               |
  |                |                               +--> Execute pipeline (component/jaxrs)
  |                |
  +--> Response (rendered output or JAX-RS payload)
        

HST Configuration Resolution

Composite Configuration

HST loads a composite configuration: base config overlaid by workspace nodes. This is how workspace containers, sitemenus, and channel info become visible to the model.

Container References

  • hst:containercomponentreference resolves against hst:workspace/hst:containers
  • Container items are hst:containeritemcomponent children
  • If the referenced workspace path is missing, the reference is ignored

Sitemenus and Channel Info

  • Sitemenus can live under both hst:sitemenus and hst:workspace/hst:sitemenus
  • Channel info is resolved from the mount
  • Preview mounts use the preview configuration and its workspace overlays

Caching and Refresh

HST model caches are built during initialization. If configuration/content is imported after the model is built, caches must be invalidated or the model rebuilt for changes to take effect.

Customization Points

What How
Repository behavior/auth Custom repository.xml on classpath
Module loading Explicit module descriptors in tests
CND/YAML patterns Spring configuration or annotation parameters