React / Redux應用程序的單元測試

Question

我目前正在研究基於Redux / React的應用程序的測試方法。 我參加了關於測試的redux教程，但仍然有疑問：

1. 測試普通的動作創建者是否有意義，它只返回一個帶有type和payload字段的對象？ 對我來說，它在OO應用程序中聞起來像getter/setter測試。

2. 在測試異步操作的情況下，您是否應該檢查相應的成功操作並進行調度？ 再次，對於模擬的HTTP請求，它似乎只是測試模擬容器，而不是應用程序行為。

3. 測試應該集中在減速器上，因為它們負責狀態轉換，是連接組件行為的手段嗎？

4. 也許不是測試應用程序的redux內核，而是應該在組件級別上進行更多測試？ 組件的哪些方面應該在何時測試？ 那些測試是否脆弱？

我想聽聽一些在生產中使用Redux / React並積極練習測試的人的經驗。

Answer 1

我將依次對每個問題做出回應，只是根據我的經驗提供不同程度的細節。

tl dr ：專注於應用程序特定的行為和功能測試，讓庫擔心redux實現細節，並在用於組件之前測試小的reducer函數。

1. 如果你像我最初使用redux那樣使用像redux-actions這樣的抽象，那么不是真的。 如果您反復手動返回具有相同屬性的對象，只需設置一個簡單的測試用例，該測試用例循環覆蓋公開的操作創建者，使用值調用它們並檢查返回的對象類型。 對於少數人來說太過分了，但是當你有很多動作創作者時，它會成為一種廉價的理智檢查。 例如：

    for (var i = 0; i < actions.length; i++) { let action = actions[i](testData); expect(action).to.have.property('type'); expect(action).to.have.property('payload'); } 

2. 一個令人困惑的措辭問題，但無論如何，經驗教會我過度測試處理網絡的事情。 由於超時而覆蓋邊緣情況，並且會對減速器的響應形狀以及它們的調用順序提出一些預期。

3. 是的，它應該專注於減速器 。 這是最重要的問題，因為它與redux成功的原因之一有關。 一切都是簡單的功能，組合成功能強大且易於理解的功能（減速器）。

   所以如果我們有：

    const reducer = combineReducers({ a: reduceA, b: reduceB }) 

   然后在單獨的測試用例中測試每個reducer的（ reduceA和reduceB ）行為。 您仍然希望測試返回的結果及其形狀，但總是試圖在實現和測試中分解reducers。

4. 和以前一樣，在使用特定組件框架（這里假設為react.js）之前，您應該使用小函數並測試它們的實現。 如果您遵循文檔中給出的建議

   建議只有應用程序的頂級組件（例如路由處理程序）才能識別Redux。 它們下面的組件應該是表示性的，並通過道具接收所有數據。

   然后你需要測試的是頂層組件傳遞redux的dispatch ，然后測試簡單組件是否調用像onClick這樣的處理程序，或者從你的商店中取出正確的狀態，但這些只需要是簡單的間諜或斷言道具的形狀和價值，與真正的redux無關。

Answer 2

您可以嘗試使用redux-actions-assertions來測試操作和動作創建者。 它允許編寫單行可讀斷言，並避免存儲准備階段。