И в сетапе будет написано
user = UserTestHelpers.create_user_allowed_to_count_dogs()
или
user = UserTestHelpers.create_user_not_allowed_to_count_dogs()

И нам тоже не важно, смотрит ли этот код в базу или нет

Если и это будет "интеграционным тестом", то тогда для тебя любой тест функции, вызывающей другую функцию будет интеграционным, потому что, вдруг там за модулем скрывается сторонний сервис или база

Или в сетапе, например, будет создаваться мок
В любом случае, тут будет сетап

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

Это бред, потому что весь твой код зависит, например, от Elixir-а. Получается, что ты проводишь интеграционное тестирование своего кода и Elixir-а (ты же вызываешь функции его модулей)

По-моему, тест может быть в трёх состояниях: тест прошёл, тест не прошёл, тест не валиден.

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

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

как я выразился выше, существует два понятия юнит-тестов:
- Чикагская школа (классическая)
- Лондонская школа

В классическом понимании, изоляция происходит на уровне модуля (или класса в других ЯП), тогда как в Лондонском понимании изоляция происходит на уровне юнит тестов. Так же, есть различия в том, что именно тестируется.  В первом случаее, тестируется поведение модуля, в другом бизнес поведенте. Есть и другие различия, но для нашей дискуссии остановимся на этих.

Почему я пишу о зависимостях. Зависимости бывают различных видов ->
- Shared dependencies. Любая mutable система. К примеру, файл в дисковой системе куда пишет/читает приложение, поэтому тесты работающие с такой зависимостью не могут запущены паралельно.
- Out-of-process dependencies. Это может быть любая immutable система. К примеру, read only сервис. Тесты могут быть запущенны паралельно

В случае elixir и ecto, сообщество выбрало Лондонский подход:
- База становится out-of-process зависимостью, так как транзакции изолированы в каждом отдельном тесте
- Принято тестировать бизнесс поведения

Интересно, а где ещё можно прочитать про школы тестирования?

вот краткое описание

вот отрывок из хорошей книги о юнит тестировании

а Ecto умеет в NoSQL?

https://github.com/elixir-ecto/ecto#usage
Нет, не умеет

Не уверенет можно ли назвать ETS NoSQL решением

тогда мне интересно как будет выглядеть вот это фраза в контексте например чистого SQL или NoSQL
"- База становится out-of-process зависимостью, так как транзакции изолированы в каждом отдельном тесте"

Ну, вот есть адаптеры для ecto и кассандры/сциллы. У них свой язык (очень похожий на SQL) — CQL (вроде так называется)

Себя они идентифицируют как NoSQL

Я вроде бы все описал :) Если SQL или NoSQL транзакции нельзя изолировать для каждого теста, тогда такие зависимости становятся Shared и это уже не подпадает под категорию unit тестов

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

🤘