Нужно в тело модуля вынести - тогда будет работать

Я думаю, что потому что некоторые тесты могут измениться (вследствие изменения логики тестируемого функционала) и тогда могут упасть тесты не связанные с изменённым функционалом

Так когда application запустится, вызовется Mix.env(), а такого модуля нет и код упадёт с ошибкой
Так что всё-таки лучше вызывать Mix.env() в компайле. Но лучше всего вообще не вызывать Mix.env()

Хотя я наверно не так поняла что тут значит изоляция. Подумала что параллелить нельзя

если if будет в теле модуля, то Mix.env будет вызываться во время компиляции

Ааа, в теле модуля. Неправильно понял, подумал о теле функции

Юнит тест это тестирование какого-то юнита - отдельной единицы программы (да, она может быть большая), но это не тестирование связок

всё что идёт с базой в остальном мире называется интеграционными тестами

Ну, довольно часто база нужна и для юнит тестов, например засетапить себе какие-нибудь сущности

я понял что в elixir все так делают (везде почти так делают), но почему вы уцепились в слово "юнит". У вас не юниты, а интеграционные значит

Это ваша привычка. В рельсах и всех производных, юнит тесты с бд работают

не вижу ничего хорошего в том что бы искривлять понятия

Никогда не слышал что бы в рельсах “Интеграционным тестированием” называли тесты связанные с базой.
Давайте не привязывать мнение человека к технологии.

Нет, это всё-таки юнит тесты
Каждый тест, по-хорошему, состоит из четырёх частей - сетап, вызов, проверка, очистка.

Так вот интеграционный тест это тест, тестирующий интеграцию. В случае с базой значит, что тестируется функционал базы, то есть вызов базы происходит во 2ой и части теста (которая вызов), причём вызов этот происходит напрямую в базу (прямо через адаптер, а не через функцию, создающую какую-то сущность)

В юнит тесте вызов базы происходит обычно в 1 и 4 части (сетапе и очистке), чтобы просто создать среду, в которой можно хоть что-то делать (например, создать юзера, от которого будет выполняться какое-то действие). Это интеграционным тестом не является, потому что никакая интеграция не тестируется

И основной, отличающий юнит от интеграционного теста, признак состоит в том, что если база сломается, то инграционный тест не пройдёт из-за неправильных данных в ассерте, а юнит тест упадёт и будет просто невалидным из-за сломанного сетапа

сетап, вызов, проверка, очистка это как раз признак интеграции с окружением
юнит тест имеет два шага: вызов и проверка

У любого теста есть окружение, всегда. Понятно, что в идеальном розовом мире, где все функции чистые, можно и без сетапа, но любое межпроцессное  взаимодействие означает наличие окружения.

Например, параметры конфигурации приложения присутствуют всегда, в любом тесте

давайте я пример приведу

тест этой функции это будет юнит тест

def set_name(user, new_name)
    %{user | name: new_name}
end

тест этой будет интеграционным

def set_name(user_id, new_name)
    user = Repo.get(User, user_id)
    # some code to update
end

def set_name(user, new_name)
    %{user | name: new_name}
end

def set_name(user_id, new_name)
    user = Repo.get(User, user_id)
    # some code to update
end

Да, это правда

это правда, нужны чистые функции. Однако мой домен весь чистый, так что я могу себе позволить)

def set_name(user, new_name)
    %{user | name: new_name}
end

def set_name(user_id, new_name)
    user = Repo.get(User, user_id)
    # some code to update
end

Но вот, например, тестирование функции

def count_dogs_of(user) do
  if User.allowed_to_count_dogs(user) do
    {:ok, length(user.dogs)}
  else
    {:error, :not_allowed}
  end
end

Будет юнит тестом, потому что User.allowed_to_count_dogs может как смотреть в базу, так и не смотреть в базу, это вообще не важно, мы не тестируем функционал этой функции, а мы тестируем умение считать собак