最近，我有機會深入研究 Early，一個專為自動單元測試產生而設計的 AI 代理程式。作為一個經常使用 TypeScript 和 ExpressoTS Framework 的人，我很想知道 Early 如何簡化我的工作流程。我決定測試他們在我正在開發的名為 @expressots/share 的新 NPM 庫上建立的 vscode 擴充功能。
Early 讓我印象深刻的第一件事是它能夠為我現有的程式碼庫自動產生單元測試。我可以專注於改進生成的測試並提高程式碼的健全性和可測試性，而不是從頭開始編寫測試。這種轉變大大加快了我的發展進程。我注意到的另一個有趣的方面是，我產生的 83% 的程式碼沒有進行任何調整，它開箱即用，並增加了我的程式碼覆蓋率。為我節省了很多時間。
在短短 8.5 小時內，我成功：
我能在一天之內完成這一切，真是太了不起了。單元測試的理想場景是在實際開發功能時進行測試。我是在我已經有了一個庫之後才這樣做的，因此需要進行一些調整以使程式碼可測試。
自動產生邊緣案例測試。例如，它為涉及空字串的場景產生單元測試，即使需要參數：
export function printSuccess(message: string, component: string): void {
stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}
最初，我不會在如此簡單的函數中建立空字串的測試。然而，Early 的方法促進了防禦性程式設計實踐，促使我處理我可能忽略的邊緣情況。
在最佳化產生的測試時，我遇到了類型不匹配的問題：
問題：jest.fn() 傳回any，但 process.exit 從未返回，導致 TypeScript 中類型不符。
解決方案：修改mock以符合process.exit簽名，確保類型正確性。
這項發現促使我調整程式碼以獲得更好的類型安全性，突出顯示 Early 如何幫助識別否則可能會被忽視的微妙問題。
儘管整體體驗積極，但我遇到了一些挑戰，如果解決這些挑戰，可以提高 Early 的可用性：
使用 Jest 29.7
expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");
// 修正版本
export function printSuccess(message: string, component: string): void {
stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}
觀察：為每個可能的輸入（包括空字串）產生測試有時可能有點過頭了。
建議：引入自訂測試產生等級的選項，允許開發人員根據需要選擇加入防禦性程式測試。
測試結果可見度：我必須在 Early 和 Jest 之間切換才能查看哪些測試通過或失敗。
檔案樹狀態：從其他應用程式切換回來時，Early 中的專案層次結構會崩潰，需要我重複重新開啟資料夾。
建議：改進 UI 以在 Early 中顯示測試結果，反映 Jest 的結構。維護文件樹的狀態也可以增強使用者體驗。
觀察：在模擬中使用任何類型都可能導致類型不匹配並可能掩蓋錯誤。
建議：改進模擬生成以使用準確的簽名，促進更好的類型安全並減少手動更正的需要。
總的來說，我在 Early 的經驗非常正面。該工具顯著加速了我的單元測試流程，使我能夠專注於改進測試，而不是從頭開始編寫測試。它還鼓勵我考慮邊緣情況並提高程式碼的穩健性。
需要改進的領域相對較小，主要圍繞著增強可用性和客製化。解決這些問題將使該工具在軟體開發中變得更加強大。
感謝早期團隊的出色工作！我很高興看到該工具如何發展，並很樂意繼續提供反饋以幫助進一步完善它。
以上是使用早期 AI 生成單元測試的詳細內容。更多資訊請關注PHP中文網其他相關文章！
