def create(conn, %{"order" => order_params}) do
order_params = get_params(conn, order_params)
case Order.create(order_params) do
{:ok, order} ->
Publit.OrganizationChannel.broadcast_order(order)
render(conn, "show.json", order: order)
{:error, cs} ->
conn
|> put_status(:unprocessable_entity)
|> render("errors.json", cs: cs)
end
end
I want to be able to test that the Publit.OrganizationChannel.broadcast_order(order) method has been called in my controller tests, I have created tests for my channel but have not found a way to pull this out.
In my opinion, the reason that mockâing is wrong in the functional world is that a function does not âtrulyâ exist, rather in a purely functional world you can inline every single function in to every single place (in reality you could not, but assume this for now), thus checking that a function is called makes no sense.
In the functional world it is better to test contracts, since a function should always return the same data for the same input if properly made (and enforced in many functional languages, including Erlang/Elixir) you can just test for that, and in fact you can build up test cases dynamically via PropEr and such. Since the EVM has fully segmented âunitsâ called processes that makes it easy to test for messages being sent between them. And with this realization you may also notice that in the OOP world you can only mock âobjectsâ, and object in the OOP world is most similar to a process in the EVM world, and you can and indeed âshouldâ mock processes, but do not ever mock functions, modules, or anything else at all, only processes.
Given that:
Your functions should be pure (they may send or receive a message, but you can mock those), so testing them becomes trivial.
Your integration tests should be pure (they may also send or receive messages, but you can mock those too).
And more importantly, you can let the system mostly test itself once you tell it how to via things like PropEr or Quickcheck (does Quickcheck still have that abysmal license?).
Thus by asking âHow can I test a method has been calledâ shows that you are testing the entirely wrong thing. You should be testing that a specific function returns an appropriate output for the given input, or sends an appropriate message, or so forth.
Every module that wraps a process should have some method of being able to override its name or PID (there is always âsomeâ way, though refactoring it a bit can make it substantially easier).
You should design your application to have well defined boundaries between its different components.
In your case, once you define the boundaries, you just want to test that the broadcast function is invoked. You can do that using the trick of sending a message to self described in the post.
I have read that post and have applied that pattern in one for one scenario, but I think this scenario has a more difficult way to do the testing. Thanks.
You can test this much easier than you think. In your test you can simply subscribe the test process to the event that will be broadcasted and use assert_receiveâŠsorry on mobile.
