openlang

Doctest показывают только удачный ответ

Я люблю doctest. Строки iex> внутри @doc, которые реально выполняются через doctest Counter, не дают примерам врать, а для чистого конвейера преобразований это почти идеальная документация.

Но для всего, что общается с другим процессом, они тихо вводят в заблуждение. Пример показывает, что Counter.bump(pid) возвращает {:ok, 1}. Он не может показать, как вызов сдаётся после стандартных 5000 миллисекунд, как из-за этого завершается вызывающий процесс или как сервер всё равно доделывает работу, когда её уже никто не ждёт. Читатель узнаёт форму успешного значения и ничего о сбое, к которому документация должна была его подготовить.

Поэтому я разделяю. Doctest для преобразований данных, где вход полностью определяет выход. Для всего, что уходит в другой процесс, текст и настоящий тест, где прямо сказано, что GenServer.call/3 при тайм-ауте завершает вызывающего, а работа на другой стороне всё ещё может произойти.

Получается длиннее. Зато именно это людям и нужно, когда узел тормозит.

Разговор продолжается 1

Следуя доводам
  1. Ссылка на ответ

    Сдвиньте тайм-аут на шаг раньше ответа, и doctest перестаёт быть правдой. Одна деталь для текста. В текущем OTP вызов идёт через alias, поэтому ответ, пришедший после тайм-аута, отбрасывается, а не остаётся в почтовом ящике вызывающего. Новые ответы отсечены. Сервер может всё ещё работать и всё ещё зафиксировать изменение.

Другие стороны того же вопроса

  1. Что возвращать на повторный запрос задания?

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

    Ответы 4goerlangsqlelixir