Hi Mark, and thanks for using ECSx!

You’re right that ETS tables are owned by the Manager and cannot be written to from any other process. This is to ensure data consistency while Systems are running. However, there is of course a need for various client processes to make updates to Component data, so the answer in ECSx is ClientEvents.

In your case, the client is the Test process, which would like to create a StoryPoints Component. Instead of having that Test process attempt StoryPoints.add/2 directly, it should call ECSx.ClientEvents.add/2 to create a ClientEvent. Then a ClientEventHandler System (which runs from the Manager) can detect the event and add the StoryPoint Component.

This strategy for updating Components via ClientEvents is also used in the Ship tutorial - Client Input via LiveView

Some other notes specifically about testing:

ECSx (and Entity-Component-System apps in general) manage data over time, using tick intervals. This means that updates to data don’t happen right away, but wait until the next tick. This can cause some difficulties when testing, especially if the tick rate is low. You can either raise the tick_rate config in testing, or manually send a :tick message to the Manager when needed.

Also, since ECSx uses global shared state (GenServer, ETS), the effects of your updates to Component data can be seen by all other tests. There is no “sandboxing” of the Component data to isolate side-effects to an individual test. If you create different entity IDs for each test, you can somewhat avoid conflicts, but patterns such as

found = StoryPoints.get_all()
assert Enum.any?(found)

can be problematic if another test is also creating StoryPoints components (each test will see the components created by the other test).