hyperoceanic
I"m working on a Kanban simulator, and I’m having some problems getting started with testing. The error message I’m getting is
** (ArgumentError) errors were found at the given arguments:
* 1st argument: the table identifier refers to an ETS table with insufficient access rights
Here’s my Component:
defmodule Taiichi.Components.StoryPoints do
use ECSx.Component,
value: :integer
end
And here’s my test:
test "sets remaining points to story points if not assigned" do
task = Ecto.UUID.generate()
StoryPoints.add(task, 100)
found = StoryPoints.get_all()
assert Enum.any?(found)
end
It’s the StoryPoints.add(task, 100) that causes the error.
I had a look at the tests in the main Ecsx repo and in the example Ship repo but could not see any tests that did something similar with a Component in an application vs one that is stood up in the test itself.
I can insert the component if I do it in the Manager, back in the main application.
I think the issue is that the ETS table is owned by the application process not the test process but I could not find an example that showed how to get this to work.
Is there some guidance on using ETS-dependent code in tests?
Where Next?
Trending in Questions
Other Trending Topics
Latest in /ECSx
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
APB9785
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/2directly, 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
:tickmessage 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
can be problematic if another test is also creating StoryPoints components (each test will see the components created by the other test).
hyperoceanic
Hi Andy - thank you for the detailed reply. I’ll be working on this again over the weekend!
Mark