{% embed https://x.com/Ari_Reinventada/status/1837055371589955632 %}

內容是:

有誰有寫過的文章或任何東西來告訴他們使用了什麼策略,讓同事們接觸到測試這門美妙的藝術?在他們說「我不同意測試」的情況下。

這部分:

"我不同意測試。"

哦,親愛的,這並不是一種 主動 的立場。考慮到我們今天擁有的生成工具,我恐怕...

<h2 style="color: darkred;">這是一個技能問題</h2>

我曾經也有過這樣的經歷。

  • 你知道理論:測試對程式碼庫是有好處的。
  • 它們作為開發者的文檔。
  • 它們提供覆蓋率。
  • 它們讓人安心。

但真正的問題在於,這並不是一個「立場」問題。只是因為 你不知道如何撰寫測試


你曾經試過官方文檔,內容大概是這樣的:

function foo() { return 42; }

expect(foo()).toBe(42)

你已經知道如何測試一個簡單的「輸入-輸出」函數。

但在現實世界中,事情要複雜得多...

  • 你想測試一個 React 元件,但它依賴於 4 個上下文、頁面位置和一個路由?
  • 你想測試一個 Node.js 物件,但它依賴於 8 個外部庫,內部狀態很混亂,並且需要一些來自德拉庫拉城的晦澀預取?
  • 你想測試一個 Python 類,但它和 RabbitMQ 相關,讓系統準備好簡直是一場噩夢?

第一步是承認:這是一個技能問題。

這沒關係

測試是一項技能,與一般編碼不同。

從小開始,拆解依賴性,並且隔離你可以控制的部分

控制是關鍵:

當你能測試你的「元件」的時候,就是你完全控制你的程式碼的時刻。

*「元件」作為一個抽象術語,你的類、你的模組、你的系統...

你知道我什麼時候終於理解了—理解(像是 真正 理解)React 上下文嗎?當我能夠測試它們的時候!

{% embed https://dev.to/manuartero/testing-a-react-context-provider-5cfg %}

另一篇相關的文章:

{% embed https://dev.to/manuartero/testing-a-custom-hook-like-a-pro-1b19 %}


模擬庫存在是有原因的。掌握可用的工具,無論是 Jest、Playwright、Pytest...

記住,這是一項技能。就像任何技能一樣,它都是可以學習的。


原文出處:https://dev.to/manuartero/if-you-dont-write-unit-test-its-a-skill-issue-22db


共有 0 則留言