As usual, the right answer depends on the actual circumstances, expected lifetime of the codebase, who is likely to work on it in the future, whether the correct execution of the background task is important enough that it warrants testing.

Here are a couple of other approaches I can think of to disable the code. The first is a very minor change to your approach that may make it more readable to someone in the future.

1. Use a config option to enable or disable the function call. For example, in config\dev.exs, have a line along the lines of config :my_app, enable_background_thing: true and in config\test.exs have config :my_app, enable_background_thing: false. Then your if Mix.env != :test, do: function_call() approach would be replaced with if Application.get_env(:my_app, : enable_background_thing), do: function_call()

The intent is clearer than your current approach I think.

2. Use some kind of dependency injection to inject a background processing module which is set up in the config for each environment. e.g.

defmodule TestBackgroundDoer do
  def do_the_thing() do
    IO.inspect("We just pretended the thing was done")
  end
end

defmodule ActualBackgroundDoer do
  def do_the_thing() do
    whatever()
    and_the_other_thing()
  end
end

defmodule BackgroundDoer do
  @doc """
  This is what's called every time object inserted/updated
  """
  def do_the_thing() do
    doer_implementation = App.get_env(:my_app, : doer_implementation)
    doer_implementation.do_the_thing()
  end
end

#dev.exs & prod.exs
config :my_app, doer_implementation: ActualBackgroundDoer

#test.exs
config :my_app, doer_implementation: TestBackgroundDoer

This is probably overkill, but if your background task is is actually multiple for different situations, it is probably better to have a more structured way to mock it out like this so you can check that the right
function is called in the right situation in your tests.

To get your tests to run without disabling the background task, have you worked through the options discussed here: Ecto.Adapters.SQL.Sandbox — Ecto SQL v3.10.1?