測試配置/系統環境獲取者

我有一個叫做Auth.app_id的函數，它首先嚐試從應用程序的配置文件中讀取app_id，如果缺少將查找系統環境。測試配置/系統環境獲取者

測試此功能的最佳做法是什麼？事先在內部測試中使用Application.put_env和System.put_env是非常糟糕的做法，因爲我們使用全局變量進行操作，並且異步測試將不可能。

test "getting config variables" do 
    Application.put_env(:appname, :app_id, "123") 
    assert Auth.app_id === "123" 
end 

test "getting env variables" do 
    System.put_env("APPNAME_APP_ID", "111") 
    assert Auth.app_id === "111" 
end

這是getter函數內部的樣子：

def app_id do 
    Application.get_env(
    :appname, 
    :app_id, 
    System.get_env("APPNAME_APP_ID") 
) 
end

的問題是，我使用這些干將，像APP_ID作爲PARAM返回URL相當多的功能。

來源

2016-03-04 Skylight

我知道這是一個頭發分裂的細節，但那些不是真正的「吸氣劑」。不在OO意義上。事實上，你可以通過不隱藏其中的細節來推廣'app_id'函數，而是將值傳遞爲參數。 –

沒有辦法繞過這些變量是全球性的（沒有看嘲笑）。我的建議是不是同時運行測試（不是在use ExUnit中使用async: true），也不是測試app_id/0函數（因爲它無論如何都是非常微不足道的）。

來源

2016-03-04 10:49:31 whatyouhide

問題是這些getter正被很多函數使用，我試圖保持所有的測試都是異步的。 JoséValim有一個反對使用嘲諷的好處，但沒有他們，它似乎是一個死衚衕...... – Skylight

@Skylight我的建議仍然不測試函數，因爲它非常微不足道（沒有參數，非常小的身體，非常可預測的行爲）。嘲笑這樣的功能是IMO的開銷。如果這個函數被許多函數使用，其中的錯誤可能會彈出:) – whatyouhide

@Skylight我同意whatyouhide。測試這種小而平凡的功能是一種貨物崇拜工程。把你的時間花在更重要的問題上。 –

你可能要做的是編寫shell代碼來調用測試。編寫設置環境變量並執行測試的shell代碼。您的shell代碼可以使用sed或這些行中的內容來修改config.exs，使其具有值或不具有取決於您希望測試的值。

這些測試現在正在增加幾乎沒有價值。現在你正在有效地測試Application模塊。

另外不要忘記測試你的代碼，如果沒有地方（config.exs或環境變量）設置。

來源

2016-03-04 13:30:00

正如@whatyouhide說，你無法迴避的事實，這些變量是全局所以我會做的是找出問題得到：

使用async: false隔離在自己的測試文件app_id測試和按照你已經做的方式來測試它;
對結果真正取決於app_id的值的所有測試執行相同的操作;
對於所有使用app_id但實際值app_id不影響結果的測試，請在setup_all回調中設置合理的值，以便這些值僅針對整個測試文件設置一次。

這樣，大多數測試可以運行異步，只有那些結果直接取決於app_id值的運行是非異步運行。

來源

2017-05-11 10:37:30

測試配置/系統環境獲取者

回答

相關問題