{% 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
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式