- Entity Store - The database that holds all entities and their components. Every entity lives inside the store.
- Ref - A lightweight reference (like an ID) to an entity in the store. You use refs to look up, modify, or destroy entities.
- Component - A data object attached to an entity. Components hold state but no logic. For example,
TransformComponentholds position/rotation,HealthComponentholds HP values. - Archetype - The set of component types an entity has. Entities with the same components share an archetype, which lets the engine look them up efficiently.
@EcsTest
Annotate a test method with@EcsTest to receive an EcsTestContext and automatically get the "ecs" tag. Tests marked with @EcsTest run on the world thread and have full access to the entity store.
EcsTestContext Methods
EcsAssert Methods
How EcsAssert Works Internally
Becausehrtk-api is a compile-only dependency (it never ships with the server), all ECS assertions use reflection under the hood. You pass the store, refs, and component types as Object in your code, but they must be the correct Hytale types at runtime.
This design lets your mod compile against
hrtk-api without needing the Hytale server JAR at compile time.Why Test ECS Operations?
ECS testing matters for modders because:- Component integrity - Verify that your custom components attach and detach correctly without corrupting the archetype.
- Query correctness - Confirm that your systems find the right entities. A missing component means your system silently skips entities it should process.
- Lifecycle safety - Catch bugs where entities are used after destruction, or components are read before they are attached.
- Regression detection - Server updates can change how the ECS handles edge cases. Tests catch these regressions early.
Next Steps
- World Testing - block operations and entity spawning
- Stats & Combat - health, damage, and alive/dead assertions
- Isolation: SNAPSHOT - protect live ECS state during tests