2017-10-09 116 views
0

我正在通過unit testing the handle_{call,cast,info} callbacks測試GenServer。我的一個文檔測試 S的如下:使用TDD的Ecto變更集和GenServers

@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"}]}, %{}}          
    """ 

我想插入的答覆DB已在遷移實現了一個指定的架構下。然而,我不知道如何爲此編寫一個單元測試 - 因爲數據庫寫入本質上是一個副作用,所以上述doctest將保持不變。

是否足夠以某種方式文檔測試changeset獨立,然後將Repo.insert成給出測試通過GenServer

回答

1

正如你所提到的,你試圖在DocTests中覆蓋的功能有副作用,這是由於文檔不足所致。

你可以找到更多的"When not to use doctest" section

一般來說,不推薦文檔測試,當你的代碼示例包含副作用...

+0

這個問題能解決由包括捕捉一些結果插入''handle_call'輸出中 - 即插入不再成爲副作用? – category

+1

如果你想嘗試幾種方法,我認爲這可能是一個有趣的練習,但總的來說,我不認爲這是你的情況下最好的方式。 Docs的主要目的實際上是記錄行爲,如果您開始影響您編寫代碼以使其在DocTests_中可測試的方式,那麼您可能會暴露於內部的大部分內容以及實現方式。這感覺就像使文檔變得難以訪問。希望是有道理的! –

+0

謝謝你。這與先寫測試的TDD方法相比如何,然後編寫代碼來明確通過測試? TDD不會導致設計爲可測試的代碼? – category