Well, probably the erlang docs:
First hit on google for me 
NobbZ
Fl4m3Ph03n1x
So this is not part of the ETS API, right?
That explains why I coulnd’t find it, I was checking the ETS docs.
0
NobbZ
The module was :counter, not :ets.
Also :counter is part of the :erts application, while :ets is in :stdlib, which itself does depend on :erts IIRC. So :counter can not use :ets.
Also due to the constraints laid out in the module documentations prelude, I’d guess its using :atomic. Which again was mentioned already in this thread.
2
peerreynders
Correct me if I’m wrong but I think the approach will only work if MyApp.do_work(deps) executes purely inside the test process - if there are any other processes spawned there could be a potential race condition:
There is no guarantee that by the time we hit assert x == :counters.get(counter, 1)
- all of the the
xcalls have already completed - there won’t be any extraneous calls for a given time period.
@LostKobrakai’s assert_received/refuted_received approach works for sequential and concurrent code within the given timeouts. So I would view the message based approach as more resilient and less aware of the implementation.
This is the basics of testing (usually you test if a function was called once) and couldn’t be farther from an implementation detail.
Given the sparse details it’s kind of difficult to judge. You seem to be testing that a lookup was performed X times. Lookups can be cached, which could break the test.
So should I be a classicist or a mockist?:
I really like the fact that while writing the test you focus on the result of the behavior, not how it’s done.
From a classicist POV counting function invocations doesn’t seem to be focusing on the result (unless in some strange way it is).
1
hauleth
Yep, there is no such guarantee. But the same goes for all asynchronous tests, but assert_received and refute_received works on messages that already are there, so they have exactly the same problem, what you would need to use is assert_receive (yeah, this is confusing), but even then the problem will be there. In other words, in truly concurrent environment (like BEAM) being 100% sure that asynchronous requests will not be “magically” repeated is impossible, in NodeJS it is possible as there is no “true concurrency” as main loop is single threaded.
1
peerreynders
I had tunnel vision on assert_receive and refute_receive - even though I typed assert_received and refute_received.
0
zkessin
You can skip all the mocks etc and just call the function and then use the trace features built into Erlang to ensure that it was called the correct number of times and with the correct params. Really so much easier
1
peerreynders
Just an observation.
I personally never got into mocking. I only crossed paths with it about 5 years ago when using Mocha/Sinon/Chai. Given the nature of JavaScript (or Ruby for that matter) I can see how one could go down that road.
My exposure to microtesting goes back to the early days JUnit.
Mocking only became a thing some time later and when I looked into it in Java-land, a lot of it relied on reflection - my reaction:
- Eeewh! That’s cheating.
Well, not entirely. It’s justified if you are mocking 3rd party dependencies but even then there was always the choice to just decouple that behind a façade.
That’s cheating.
That reaction was driven by the notion that mocking your own code removes the incentive to constantly assess and re-evaluate your boundaries. With classical testing there is the constant pressure to adjust your boundaries to be able to test what you want to test.
To me personally the primary benefit of Test Driven Development (in the classical sense) was that constant challenging of those boundaries (and the portals passing through them) - not the test first religion.
Of course even that can go off the rails as evidenced by the whole test induced design damage discussion.
One thing that isn’t clear from this discussion is:
- why is it so important that the lookup is called 10 times that it needs to be tested at this level?
- what is responsible for performing that lookup in the real system?
For example, if the lookup goes to another process anyway, wouldn’t it make more sense to test it with a fake process which keeps track of the invocation details that are then sent to the testing process?
Somewhat related in the JavaScript space: Please don’t mock me
4