assert_receive/3 has already been pointed out to you - have a look at it and it’s friends.
- “Busy wait” is the anti-pattern - it doesn’t matter if the wait is 100 or 1 ms.
- In an efficient system events worth observing need to be broadcast - not “watched”. Interested parties should be able to register (and unregister) their “interest” so that they can be notified when the event occurs. That notification (event message) can then be used with
assert_receive/3.
The fact that you need to structure a test in a “busy wait” manner may suggest that you have a design issue.
What is that ETS table used for? Typically they exist to support some sort of request served by the process. If the same process sends the async insert followed by a synchronous request then the request should be served after the insert has been processed - so the result of the request should be consistent with the insert being successful.
