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
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
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 Posts (oldest first)
- Show All Posts (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