Наборы изменений Ecto и GenServers с использованием TDD

Я тестирую GenServer с помощью модульного тестирования обратных вызовов handle_{call,cast,info}. Один из моих doctest выглядит следующим образом:

@doc """                                                                                             
  Call the GenServer to retrieve the initial workout                                                   

  ## Examples                                                                                          
  iex> :rand.seed(:exsplus, {101, 102, 103})                                                           
  iex> Pullapi.GenServerWorker.handle_call({:initial_workout, 5}, nil, %{})                         
  {:reply,                                                                                             
  {:ok,                                                                                                
  [%{"Action" => "Pullups", "SequenceNo" => 0, "Units" => "1"},                                        
  %{"Action" => "Rest", "SequenceNo" => 1, "Units" => "60"},                                           
  %{"Action" => "Pullups", "SequenceNo" => 2, "Units" => "3"},                                         
  %{"Action" => "Rest", "SequenceNo" => 3, "Units" => "60"},                                           
  %{"Action" => "Pullups", "SequenceNo" => 4, "Units" => "3"},                                         
  %{"Action" => "Rest", "SequenceNo" => 5, "Units" => "70"}]}, %{}}                                    
  """

Я хочу вставить ответ в БД по указанной схеме, которая была реализована при миграции. Однако у меня нет четкого представления о том, как написать модульный тест для этого - поскольку запись в БД, по сути, является побочным эффектом, приведенный выше doctest останется прежним.

Достаточно ли каким-то образом протестировать changeset независимо друг от друга, а затем поместить Repo.insert в GenServer при условии прохождения теста?


tdd elixir ecto gen-server changeset
person category    schedule 09.10.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Как вы упомянули, часть функциональности, которую вы пытаетесь охватить в DocTests, имеет побочные эффекты, и это не рекомендуется из-за документации.

Дополнительную информацию можно найти в " Когда не использовать раздел doctest":

Как правило, доктесты не рекомендуются, если ваши примеры кода содержат побочные эффекты...

person Paweł Dawczak    schedule 09.10.2017
comment
Можно ли решить эту проблему, включив захват некоторого результата вставки в вывод handle_call, т.е. вставка больше не становится побочным эффектом? - person category; 09.10.2017
comment
Я думаю, что это может быть интересным упражнением для вас, если вы хотите попробовать несколько подходов, но в целом я бы не считал это лучшим способом продвижения вперед в вашем случае. Основная цель Документов на самом деле заключается в документировании поведения, и если вы начинаете влиять на свой код, чтобы сделать его тестируемым в DocTests, вы можете раскрыть большую часть внутренних компонентов и то, как они реализованы. Это похоже на затенение документации, что делает ее менее доступной. Надеюсь, это имеет смысл! - person Paweł Dawczak; 09.10.2017
comment
Спасибо за это. Как это соотносится с подходом TDD, когда сначала пишется тест, а затем код, специально предназначенный для прохождения теста? Не приведет ли TDD к коду, предназначенному для тестирования? - person category; 09.10.2017
comment
@category извините за неконкретность, позвольте мне это исправить! TDD — отличная техника, и вы должны ей следовать. Я хотел подчеркнуть, что тип тестирования, который вы пытаетесь выполнить, действителен, и вы должны тестировать свои функции более детально, но DocTests — не лучшее место. для этого. Такого рода тестирование должно выполняться в ваших _test.exs файлах. При таком подходе вы должны получить проверенный код (в тестовых файлах) и чистую, легкую для понимания документацию. Имеет ли это смысл? - person Paweł Dawczak; 09.10.2017
comment
Спасибо, да - если в этом случае лучше всего подходит ExUnit тест, должен ли я также заменить мои предыдущие doctests тестами ExUnit для согласованности? - person category; 09.10.2017
comment
Немного сложно судить на основе примера одной функции, которой вы поделились здесь, но и да, и нет: да переместите тестовый код в тестовые файлы (вы хотите продолжать тестировать свой код) и нет, оставьте раздел «Примеры» в тестах документации (в конце концов, это документация, поэтому показать способ использования функции — хорошая идея), но просто не запускайте примеры из них в своем тестовом наборе (который фактически сводится к изменению или полному удалению doctest MyModule из ваших тестовых файлов) - person Paweł Dawczak; 10.10.2017
comment
Отлично, спасибо - это именно то, что мне нужно было знать. - person category; 10.10.2017