How can I test a function that has been called

boriscy

I have this code in my controller

  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.

10 comments

/phoenix #channels #testing

2 11651 10

2024-01-10 03:02:27 UTC

First 10 of 10 Posts

hubertlepicki

This is a function, not a method. There are no methods in Elixir.

Use mock library if you really want to do that: GitHub - jjh42/mock: Mocking library for Elixir language · GitHub

Post #1

boriscy

Thanks, I have used mock in the past, I think in this case using mock might be the best solution but I would like to remark Jose Valim words

I will fight against mocks, stubs and YAML in Elixir with all my… friendliness and energy to promote proper education on those topics.
Jose Valim

Post #2

OvermindDL1

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).

Post #3

hubertlepicki

Yeah, that is why I wrote “if you really want to do that”.

Post #4

mariosangiorgio

I’d suggest you to read this excellent post by José Valim Mocks and explicit contracts « Plataformatec Blog

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.

Post #5

boriscy

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.

Post #6

scrogson

Phoenix Core Team

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.

Post #7

dom

Providing some links:

Something like Publit.PubSub.subscribe(topic) then assert_receive later should be enough, no mock involved.

Post #8

manukall

I have written a blog post about the general case some days ago. It builds on José’s post that was mentioned above.
Maybe it’s helpful for someone: https://pryin.io/blog/mocks-and-side-effects/

Post #9