Please take my post with a pinch of salt, as I’ve read 2 books on Elixir, but have no experience of it in production/OSS otherwise.
After painfully going through similar questions you’re raising, I’ve arrived at the following so far:
- Elixir processes are not OOP classes, so we can’t expect to test them the same way (e.g. create a structure of several objects, perform actions and observe side effects).
- Pure/functional Elixir code is easy to test.
- Mocking/stubbing actors is hard. Seen this both in Elixir and in Orleans on .NET.
Therefore, I’ve found it’s most practical to:
- Have as much logic as possible in the pure functional modules. Cover these with extensive unit tests.
- For process-level testing, start the application (like
mix testdoes by default), and send test messages/observe side effects as the application is running. Most likely it means having a DB running as part of your build job etc.
#2 assumes that the processes/services are very slim and delegate all decisions to the pure code. That’s not always easy as messages that get passed around are usually intertwined with the business logic.
I’m not sure I’ve made my peace with the above approach yet, but this is what the toolset has been pushing me forward. Larger projects on Github that I’ve looked at (Phoenix, Nostrum) all seem to be following similar philosophy.
