現在流行叫 QA，而不是測試。這是因為大家意識到：保證軟件質量，僅僅靠編碼完成后的測試是不夠的，從需求分析、設計階段開始就要嚴格把關。QA 的職責從之前的“編碼完成后測試”延伸到軟件開發的全過程。
參與了軟件開發全過程的 QA，不僅對測試工作更有把握，還能提出產品方面的建議、制定有效的項目計划、找出開發設計存在的問題。例如：
- 功能是不是過度設計了？用戶只要 xx 就夠了。
- 在什么時間點合代碼？
- 這樣的表結構，功能滿配的情況下，數據量是多少？這樣規模的數據，用這樣的算法操作，是否影響系統性能？
現在流行敏捷開發，為了保證質量和速度，測試的工作需要向自動化發展。因此 QA 又多了一項任務：編寫端到端自動化測試腳本。
這種端到端自動化測試腳本，編寫、調試體驗很差。打開一個瀏覽器，模擬用戶在網頁操作，速度很慢，盯着看讓人心急。但編寫、調試階段你還不得不盯着看。其實前端開發更了解元素定位，更清楚用什么定位方式更可靠，但因為編寫效率低，影響開發進度，這個工作一般都是 QA 來做。
jsdom 實現了瀏覽器 api，運行在 nodejs 環境中，可以模擬瀏覽器。基於 React 的 web 項目 UT 時，ReactDOM 把組件渲染到 jsdom 模擬的瀏覽器中。
這個方案只用來做 UT 可惜了。如果你把 jsdom 就看作真實瀏覽器，把請求變成真實請求，這不就是“端到端測試”嗎？和 selenium 的區別僅僅是：一個用 jsdom 瀏覽器，一個用真實瀏覽器。就連基於 @testing-library/react 的測試腳本，寫的也是模擬用戶操作，和 selenium 腳本差不多。如下方代碼示例，模擬初始化加載和用戶點擊刷新：
it("loading & refreshing", async () => {
render(<App />);
expect(
await screen.findByText(/apolis/i)
).toBeInTheDocument();
user.click(
screen.getByRole("button", {
name: /refresh/i,
})
);
expect(
await screen.findByText(/kzhang/i)
).toBeInTheDocument();
});
我理想的樣子是：QA 和前端開發共同實現產品的端到端自動化測試。QA 設計測試用例、搭建測試環境、提供用於測試環境初始化的腳本；前端按照 QA 設計的測試用例編寫自動化測試腳本，自動化測試腳本中會調用 QA 的環境初始化腳本。
在實際工作中，“端到端測試”也許是終極目標，要實現這一目標，把 UT 做起來是第一步。
一些想法：
- 使用 msw 做 UT 和編碼的
Mock Server，共用handlers。開發新功能時，UT 和編碼一起進行，練習看着 test result 開發，通過這種方式，讓團隊熟悉@testing-library。 - 團隊積累 UT 經驗的同時，需總結、提取、封裝適合項目 UT 的工具庫。
- 提高 UT Case 的質量，設計更容易發現錯誤的 UT Case。這一方面需要學習一些測試理論，一方面需要多總結項目中的衰退 Bug。
讓 UT 從無到有到快到好。
