I’m not a fan of the first solution. As I understand it, in the test code he exposes the internal API of the Processor object, but this API is not exposed to users of the code. I find exposing calls just for testing to be a smell. Instead, I would view this as orthogonal concerns. There is the processor code, which runs in some context. And there is the context in which it runs it (the thread). I listen to music. Sometimes I listen to it in a car sometimes in a bar. Now and then on a plane or on a train. Maybe something joins the thread + processing code in an elegant way, but it’s all public APIs.
The second method is great and I’ve used it often. Sleeps are the biggest smell in a test suite. Another method I’ve used in several Erlang libraries I’ve worked on is having a sync call that blocks until all the previous work is finished. The test looks like:
do_stuff()
sync()
validate_stuff_done()
The sync call often becomes useful in production code if you want any kind of “drain current work and stop accepting new work” behaviour (debatable if that is a good idea).
I’m not a fan of the first solution. As I understand it, in the test code he exposes the internal API of the
Processorobject, but this API is not exposed to users of the code. I find exposing calls just for testing to be a smell. Instead, I would view this as orthogonal concerns. There is the processor code, which runs in some context. And there is the context in which it runs it (the thread). I listen to music. Sometimes I listen to it in a car sometimes in a bar. Now and then on a plane or on a train. Maybe something joins the thread + processing code in an elegant way, but it’s all public APIs.The second method is great and I’ve used it often. Sleeps are the biggest smell in a test suite. Another method I’ve used in several Erlang libraries I’ve worked on is having a
synccall that blocks until all the previous work is finished. The test looks like:The
synccall often becomes useful in production code if you want any kind of “drain current work and stop accepting new work” behaviour (debatable if that is a good idea).