react-testing-library Mocking Fat Arrow 組件方法

Question

我正在嘗試創建一個單元測試來測試帶有粗箭頭 function 方法的 React 組件。 我試圖通過 react-testing-library + jest 在單元測試中模擬這些方法，但沒有成功

我無法執行 mocking，因為 jest.spyOn 會拋出一個錯誤，指出該方法不是 function

Answer 1

這打破了 react-testing-library 背后的封裝理念。 你不應該關心 mocking 內部方法； 相反，專注於用戶可以觀察到的 UI 變化，並對其進行測試。

查看文檔中的指導原則以獲取更多上下文。

Answer 2

你不能監視反應組件 function。我也試圖讓它工作。 我想確定，所以我寫了一些簡單的組件和測試，並嘗試了所有可能的配置，包括命名導出和默認導出以及一些import * as Component這樣就可以執行const spy = jest.spyOn(Component, 'default') 。 它。 沒有。 工作。 我很想在這一點上是錯誤的，但在我今天讀完之后，我不這么認為。 這似乎是 RTL 有意為之，並且正是出於@dangerismycat 所解釋的原因。

但是，您可以像這樣自動模擬一個組件：

jest.mock('./path-to-component')

或者如果你只想模擬一些命名的導出，你可以寫：

const mockExport = jest.fn()
jest.mock('./path-to-component', () => {
  const actual = jest.requireActual('./path-to-component')
  return {
    ...actual,
    namedExport: mockExport,
  }
})

您甚至可以使用默認導出來執行此操作，但有一些注意事項。

在 auto-mock 和 spy 方法之間，一個顯着的區別是自動模擬的組件不能像間諜一樣恢復到它原來的預模擬 state。 間諜也可以名副其實，只監視組件的正常運行以用於斷言。 它也可以與.mockImplementation或.mockReturnValue等鏈接在一起。使用一個工作間諜，您可以在同一個文件中完成所有這些事情； 只是不使用現代 React function 組件。

自動模擬確實有一些很酷的功能，如上面的片段所示，當然還有更多我尚未發現的功能。 將 auto-mocks 提升到 imports 之上尤其是一種有趣的做法。 毫無疑問，模擬是任何從事大型應用程序工作的人的必備工具。

雖然從用戶角度理解編寫測試的論點在技術上並不困難，並且由於這種困境，它從根本上改變了我思考編寫測試的方式，但這仍然是一個不必要的限制。 如果一個應用程序存在時間足夠長，它可以有數千個文件，而 redux 商店在這樣的應用程序中將完全膨脹。 也可能有殘留的酶和大量的 class 組件，在那種情況下，僅僅測試一個簡單的行為就需要這么多樣板。 模擬對於管理它是必不可少的。

此外，還有另一個有趣的趨勢出現，其中組件用一個容器包裝，該容器負責將其所有數據按摩到可顯示的日期和字符串等中。 這種關注點分離™ 非常好。 主要組件只負責跟蹤在特定條件下顯示（或隱藏）不同的元素。 不幸的是，它們之間的緊密耦合與 RTL 對測試反應方式的規定相沖突。

最后，這種方法還有一個方面讓人感覺受到了不必要的限制。 應用程序中的工作比用戶可以看到的要多，因此這種僅用戶的觀點似乎是短視的。

總之，我建議不要與自以為是的框架作斗爭。 就像賭場一樣，框架總是贏家。