นำ TestGen-LLM ของ Meta มาใช้งานแบบโอเพนซอร์สเป็นครั้งแรก

xguru · 2024-05-23T11:02:01+09:00

ในบทความวิจัยที่ Meta เผยแพร่เมื่อเดือนกุมภาพันธ์ชื่อ "Automated Unit Test Improvement using Large Language Models at Meta" ได้มีการแนะนำเครื่องมือชื่อ TestGen-LLM เครื่องมือนี้มีเป้าหมายเพื่อเพิ่ม test coverage แบบอัตโนมัติเต็มรูปแบบ พร้อมรับประกันว่าผลลัพธ์จะดีกว่า codebase เดิม เนื่องจาก Meta ไม่ได้เปิดเผยโค้ดของ TestGen-LLM จึงตัดสินใจพัฒนาขึ้นเองโดยตรงในฐานะส่วนหนึ่งของโอเพนซอร์ส Cover Agent ที่นี่จะแชร์ทั้งกระบวนการพัฒนา สิ่งที่ค้นพบ และปัญหาที่ต้องเผชิญเมื่อใช้ TestGen-LLM กับ codebase จริง เกณฑ์ของการสร้างเทสต์อัตโนมัติ การสร้างเทสต์อัตโนมัติด้วย generative AI ไม่ใช่เรื่องใหม่ LLM ส่วนใหญ่เก่งในการสร้างโค้ด และสามารถสร้างเทสต์ได้เช่นกัน ปัญหาที่พบบ่อยที่สุดเมื่อผู้พัฒนาใช้ LLM สร้างเทสต์ คือเทสต์ที่สร้างขึ้นมาส่วนใหญ่มักรันไม่ได้หรือไม่ได้เพิ่มคุณค่าอะไร เพื่อแก้ปัญหานี้ ผู้เขียน TestGen-LLM จึงเสนอเกณฑ์สำหรับ regression unit test ดังนี้: เทสต์คอมไพล์และรันได้อย่างถูกต้องหรือไม่? เทสต์ช่วยเพิ่ม code coverage หรือไม่? หากตอบคำถามพื้นฐานสองข้อนี้ไม่ได้ ก็ไม่มีเหตุผลที่จะยอมรับหรือวิเคราะห์เทสต์ที่ LLM สร้างให้ หากผ่านคำถามเหล่านี้แล้ว จึงค่อยเข้าสู่การรีวิวแบบแมนนวล เทสต์เขียนได้ดีแค่ไหน? มันเพิ่มคุณค่าได้มากน้อยเพียงใดจริง ๆ? ตรงตามข้อกำหนดเพิ่มเติมหรือไม่? แนวทางของ TestGen-LLM และผลลัพธ์ที่รายงาน TestGen-LLM (รวมถึง Cover-Agent) ทำงานแบบ headless เต็มรูปแบบ ขั้นแรกจะสร้างเทสต์จำนวนมาก จากนั้นกรองเทสต์ที่ build/execute ไม่ได้ ทิ้งเทสต์ที่ไม่ผ่าน และคัดออกหากไม่ช่วยเพิ่ม code coverage ในกรณีที่ควบคุมเงื่อนไขได้มาก อัตราส่วนของเทสต์ที่ผ่านทุกขั้นตอนเมื่อเทียบกับเทสต์ที่สร้างอยู่ที่ 1:4 และในสถานการณ์จริง ผู้เขียนจาก Meta รายงานอัตราส่วน 1:20 หลังจากกระบวนการอัตโนมัติ Meta จะให้ผู้รีวิวที่เป็นมนุษย์เป็นผู้รับหรือปฏิเสธเทสต์ ผู้เขียนบทความวิจัยระบุว่า ในกรณีที่ดีที่สุดมีอัตราการยอมรับ 73% และโดยเฉลี่ยมีอัตรารับที่ 1:2 ตามที่อธิบายในบทความวิจัย เครื่องมือ TestGen-LLM จะสร้างเทสต์เพียงหนึ่งรายการต่อการรันแต่ละครั้ง เพื่อเพิ่มเข้าไปใน test suite เดิมที่นักพัฒนาผู้เชี่ยวชาญเคยเขียนไว้แล้ว และไม่ได้หมายความว่าจะต้องสร้างเทสต์ให้กับ test suite ที่กำหนดได้เสมอไป การพัฒนา Cover-Agent Cover-Agent v0.1 ถูกพัฒนาดังนี้: รับข้อมูลจากผู้ใช้ (ไฟล์ซอร์สที่ต้องการทดสอบ, test suite เดิมที่ต้องการปรับปรุง, รายงาน coverage, คำสั่งสำหรับ build และรัน test suite, เป้าหมาย code coverage และจำนวนรอบการทำซ้ำสูงสุด, บริบทเพิ่มเติมและตัวเลือก prompt) สร้างเทสต์เพิ่มเติมในสไตล์เดียวกัน ตรวจสอบเทสต์เหล่านั้นด้วย runtime environment (build ได้และผ่านหรือไม่) ตรวจดูเมตริกอย่างการเพิ่ม code coverage เพื่อตรวจสอบว่าเทสต์เพิ่มคุณค่าหรือไม่ อัปเดต test suite และรายงาน coverage เดิม ทำซ้ำจนกว่าโค้ดจะถึงเกณฑ์ (ถึง threshold ของ code coverage หรือถึงจำนวนรอบสูงสุด) ปัญหาที่พบระหว่างการพัฒนาและทบทวน TestGen-LLM ในตัวอย่างที่นำเสนอในบทความวิจัย ใช้ Kotlin สำหรับเขียนเทสต์ ซึ่งเป็นภาษาที่ช่องว่างไม่ได้มีความสำคัญมาก แต่ในภาษาอย่าง Python ทั้ง tab และ space มีความสำคัญ ไม่เพียงเท่านั้นแต่ยังจำเป็นต่อ parser ด้วย โมเดลที่ซับซ้อนน้อยกว่า เช่น GPT 3.5 แม้จะมีการให้ prompt อย่างชัดเจน ก็ยังไม่สามารถคืนโค้ดที่ย่อหน้าได้ถูกต้องอย่างสม่ำเสมอ ตัวอย่างของปัญหานี้คือ test class ที่เขียนด้วย Python ซึ่งแต่ละ test function ต้องมีการเยื้องที่ถูกต้อง เรื่องนี้ต้องนำมาพิจารณาตลอดทั้งวงจรการพัฒนา และทำให้ต้องเพิ่มความซับซ้อนมากขึ้นรอบ ๆ preprocessing library ยังมีอีกหลายจุดที่ต้องปรับปรุงเพื่อให้ Cover-Agent มีความทนทานในสถานการณ์ลักษณะนี้ มีการเพิ่มความสามารถให้ผู้ใช้ส่งข้อมูลหรือคำสั่งเพิ่มเติมให้ LLM ได้ใน flow ของ Cover-Agent (--additional-instructions) สิ่งนี้ช่วยให้นักพัฒนาปรับแต่ง Cover-Agent ด้วยข้อมูลเพิ่มเติมที่เฉพาะกับโปรเจกต์ได้ ตัวอย่างเช่น สามารถใช้คำสั่งนี้เพื่อชี้นำให้ Cover-Agent สร้างชุดเทสต์ที่มี edge case สำคัญและมีความหมาย พร้อมกับเห็นด้วยกับแนวโน้มทั่วไปที่ Retrieval-Augmented Generation(RAG) แพร่หลายมากขึ้นในแอปพลิเคชันที่ขับเคลื่อนด้วย AI ก็พบว่าการมีบริบทมากขึ้นสำหรับการสร้าง unit test ช่วยให้ได้เทสต์คุณภาพสูงขึ้นและมีอัตราการผ่านสูงขึ้น เพื่อปรับปรุงกระบวนการสร้างเทสต์ จึงมีตัวเลือก --included-files สำหรับผู้ใช้ที่ต้องการเพิ่มไลบรารีเพิ่มเติมหรือเอกสารออกแบบแบบข้อความเข้าไปเป็นบริบทให้ LLM ด้วยตนเอง โค้ดที่ซับซ้อนและต้องอาศัยการทำซ้ำหลายรอบยังเป็นความท้าทายอีกอย่างสำหรับ LLM เมื่อมีการสร้างเทสต์ที่ล้มเหลว (หรือไม่ได้เพิ่มคุณค่า) ก็เริ่มพบรูปแบบที่เทสต์ที่ไม่ถูกยอมรับเดิมถูกเสนอซ้ำในรอบถัด ๆ ไป เพื่อแก้ปัญหานี้ จึงเพิ่มส่วน "failed tests" ใน prompt เพื่อส่ง feedback นั้นให้ LLM และป้องกันไม่ให้มันสร้างเทสต์ซ้ำที่เคยตัดสินแล้วว่าใช้ไม่ได้ (เช่น พังหรือเพิ่ม coverage ไม่พอ) อีก อีกปัญหาหนึ่งที่เกิดขึ้นตลอดกระบวนการคือ เมื่อขยาย test suite เดิม จะไม่สามารถเพิ่มการ import ไลบรารีได้ บางครั้งนักพัฒนาอาจมองแคบเกินไปด้วยการใช้แนวทางเดียวกับ testing framework ในกระบวนการสร้างเทสต์ นอกจาก mocking framework ที่มีหลากหลายแล้ว ยังมีไลบรารีอื่นอีกที่อาจช่วยให้บรรลุ test coverage ได้ เนื่องจากบทความวิจัย TestGen-LLM (รวมถึง Cover-Agent) มีจุดมุ่งหมายเพื่อขยาย test suite เดิม การปรับโครงสร้าง test class ทั้งชุดใหม่ทั้งหมดจึงอยู่นอกขอบเขต นี่คือข้อจำกัดของการขยายเทสต์เมื่อเทียบกับการสร้างเทสต์ใหม่ และมีแผนจะจัดการในรอบถัดไป สิ่งสำคัญคือต้องแยกความต่างว่า ในแนวทางของ TestGen-LLM จำเป็นต้องมีการรีวิวแบบแมนนวลโดยนักพัฒนาสำหรับแต่ละเทสต์ก่อนที่จะมีการเสนอเทสต์ถัดไป ขณะที่ใน Cover-Agent จะสร้าง ตรวจสอบ และเสนอเทสต์ให้ได้มากที่สุดโดยไม่มีการแทรกแซงแบบแมนนวลตลอดกระบวนการ จนกว่าจะบรรลุข้อกำหนดด้าน coverage (หรือหยุดเมื่อถึงรอบสูงสุด) เป็นแนวทางการสร้างเทสต์อัตโนมัติแบบไม่รบกวน โดยใช้ AI ทำงานเบื้องหลัง เพื่อให้นักพัฒนาสามารถรีวิว test suite ทั้งชุดได้ครั้งเดียวหลังจากกระบวนการเสร็จสิ้น บทสรุปและแผนในอนาคต หลายคน (รวมถึงตัวฉันเอง) คาดหวังกับบทความวิจัยและเครื่องมือ TestGen-LLM มาก แต่โพสต์นี้พูดถึงข้อจำกัดของมัน เรายังอยู่ในยุคของ AI assistant มากกว่าจะเป็นเพื่อนร่วมทีม AI ที่รัน workflow แบบอัตโนมัติเต็มรูปแบบได้ด้วยตัวเอง ในขณะเดียวกัน flow ที่ออกแบบมาอย่างดีสามารถช่วยให้นักพัฒนาสร้างผู้สมัครเป็นเทสต์ได้โดยอัตโนมัติ และเพิ่ม code coverage ได้ในเวลาที่สั้นลงมาก ซึ่งเป็นสิ่งที่วางแผนจะพัฒนาและแบ่งปันใน Cover-Agent มีแผนจะพัฒนาวิธีการล้ำสมัยที่เกี่ยวข้องกับโดเมนการสร้างเทสต์อย่างต่อเนื่อง และรวมเข้าไปในโอเพนซอร์สรีโพซิทอรีของ Cover-Agent หวังว่าทุกคนที่สนใจ generative AI สำหรับงาน testing จะเข้ามาร่วมมือกัน ช่วยขยายความสามารถของ Cover Agent และหวังว่าจะสร้างแรงบันดาลใจให้นักวิจัยใช้เครื่องมือโอเพนซอร์สนี้สำรวจเทคนิคการสร้างเทสต์ใหม่ ๆ ได้เพิ่ม roadmap การพัฒนาไว้ในรีโพซิทอรีโอเพนซอร์ส Cover-Agent บน GitHub แล้ว และอยากเห็นการมีส่วนร่วมในรีโพซิทอรีตาม roadmap หรือแม้แต่ไอเดียของคุณเอง วิสัยทัศน์ของ Cover-Agent คือในอนาคตจะทำงานอัตโนมัติสำหรับทุก pre/post-pull request และเสนอการปรับปรุง regression test ที่ได้รับการตรวจสอบแล้วว่ารันได้จริงและช่วยเพิ่ม code coverage โดยอัตโนมัติ ลองจินตนาการว่า Cover-Agent สามารถสแกน codebase โดยอัตโนมัติและเปิด PR พร้อม test suite ให้ได้ มาลองใช้ AI จัดการงานที่เราไม่ชอบให้มีประสิทธิภาพมากขึ้นกันเถอะ!

(codium.ai)

8 คะแนน โดย xguru 2024-05-23 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

ในบทความวิจัยที่ Meta เผยแพร่เมื่อเดือนกุมภาพันธ์ชื่อ "Automated Unit Test Improvement using Large Language Models at Meta" ได้มีการแนะนำเครื่องมือชื่อ TestGen-LLM
เครื่องมือนี้มีเป้าหมายเพื่อเพิ่ม test coverage แบบอัตโนมัติเต็มรูปแบบ พร้อมรับประกันว่าผลลัพธ์จะดีกว่า codebase เดิม
เนื่องจาก Meta ไม่ได้เปิดเผยโค้ดของ TestGen-LLM จึงตัดสินใจพัฒนาขึ้นเองโดยตรงในฐานะส่วนหนึ่งของโอเพนซอร์ส Cover Agent
ที่นี่จะแชร์ทั้งกระบวนการพัฒนา สิ่งที่ค้นพบ และปัญหาที่ต้องเผชิญเมื่อใช้ TestGen-LLM กับ codebase จริง

เกณฑ์ของการสร้างเทสต์อัตโนมัติ

การสร้างเทสต์อัตโนมัติด้วย generative AI ไม่ใช่เรื่องใหม่
LLM ส่วนใหญ่เก่งในการสร้างโค้ด และสามารถสร้างเทสต์ได้เช่นกัน
ปัญหาที่พบบ่อยที่สุดเมื่อผู้พัฒนาใช้ LLM สร้างเทสต์ คือเทสต์ที่สร้างขึ้นมาส่วนใหญ่มักรันไม่ได้หรือไม่ได้เพิ่มคุณค่าอะไร
เพื่อแก้ปัญหานี้ ผู้เขียน TestGen-LLM จึงเสนอเกณฑ์สำหรับ regression unit test ดังนี้:
1. เทสต์คอมไพล์และรันได้อย่างถูกต้องหรือไม่?
2. เทสต์ช่วยเพิ่ม code coverage หรือไม่?
หากตอบคำถามพื้นฐานสองข้อนี้ไม่ได้ ก็ไม่มีเหตุผลที่จะยอมรับหรือวิเคราะห์เทสต์ที่ LLM สร้างให้
หากผ่านคำถามเหล่านี้แล้ว จึงค่อยเข้าสู่การรีวิวแบบแมนนวล
- เทสต์เขียนได้ดีแค่ไหน?
- มันเพิ่มคุณค่าได้มากน้อยเพียงใดจริง ๆ?
- ตรงตามข้อกำหนดเพิ่มเติมหรือไม่?

แนวทางของ TestGen-LLM และผลลัพธ์ที่รายงาน

TestGen-LLM (รวมถึง Cover-Agent) ทำงานแบบ headless เต็มรูปแบบ
ขั้นแรกจะสร้างเทสต์จำนวนมาก จากนั้นกรองเทสต์ที่ build/execute ไม่ได้ ทิ้งเทสต์ที่ไม่ผ่าน และคัดออกหากไม่ช่วยเพิ่ม code coverage
ในกรณีที่ควบคุมเงื่อนไขได้มาก อัตราส่วนของเทสต์ที่ผ่านทุกขั้นตอนเมื่อเทียบกับเทสต์ที่สร้างอยู่ที่ 1:4 และในสถานการณ์จริง ผู้เขียนจาก Meta รายงานอัตราส่วน 1:20
หลังจากกระบวนการอัตโนมัติ Meta จะให้ผู้รีวิวที่เป็นมนุษย์เป็นผู้รับหรือปฏิเสธเทสต์
ผู้เขียนบทความวิจัยระบุว่า ในกรณีที่ดีที่สุดมีอัตราการยอมรับ 73% และโดยเฉลี่ยมีอัตรารับที่ 1:2
ตามที่อธิบายในบทความวิจัย เครื่องมือ TestGen-LLM จะสร้างเทสต์เพียงหนึ่งรายการต่อการรันแต่ละครั้ง เพื่อเพิ่มเข้าไปใน test suite เดิมที่นักพัฒนาผู้เชี่ยวชาญเคยเขียนไว้แล้ว
และไม่ได้หมายความว่าจะต้องสร้างเทสต์ให้กับ test suite ที่กำหนดได้เสมอไป

การพัฒนา Cover-Agent

Cover-Agent v0.1 ถูกพัฒนาดังนี้:
1. รับข้อมูลจากผู้ใช้ (ไฟล์ซอร์สที่ต้องการทดสอบ, test suite เดิมที่ต้องการปรับปรุง, รายงาน coverage, คำสั่งสำหรับ build และรัน test suite, เป้าหมาย code coverage และจำนวนรอบการทำซ้ำสูงสุด, บริบทเพิ่มเติมและตัวเลือก prompt)
2. สร้างเทสต์เพิ่มเติมในสไตล์เดียวกัน
3. ตรวจสอบเทสต์เหล่านั้นด้วย runtime environment (build ได้และผ่านหรือไม่)
4. ตรวจดูเมตริกอย่างการเพิ่ม code coverage เพื่อตรวจสอบว่าเทสต์เพิ่มคุณค่าหรือไม่
5. อัปเดต test suite และรายงาน coverage เดิม
6. ทำซ้ำจนกว่าโค้ดจะถึงเกณฑ์ (ถึง threshold ของ code coverage หรือถึงจำนวนรอบสูงสุด)

ปัญหาที่พบระหว่างการพัฒนาและทบทวน TestGen-LLM

ในตัวอย่างที่นำเสนอในบทความวิจัย ใช้ Kotlin สำหรับเขียนเทสต์ ซึ่งเป็นภาษาที่ช่องว่างไม่ได้มีความสำคัญมาก
แต่ในภาษาอย่าง Python ทั้ง tab และ space มีความสำคัญ ไม่เพียงเท่านั้นแต่ยังจำเป็นต่อ parser ด้วย
โมเดลที่ซับซ้อนน้อยกว่า เช่น GPT 3.5 แม้จะมีการให้ prompt อย่างชัดเจน ก็ยังไม่สามารถคืนโค้ดที่ย่อหน้าได้ถูกต้องอย่างสม่ำเสมอ
ตัวอย่างของปัญหานี้คือ test class ที่เขียนด้วย Python ซึ่งแต่ละ test function ต้องมีการเยื้องที่ถูกต้อง
เรื่องนี้ต้องนำมาพิจารณาตลอดทั้งวงจรการพัฒนา และทำให้ต้องเพิ่มความซับซ้อนมากขึ้นรอบ ๆ preprocessing library
ยังมีอีกหลายจุดที่ต้องปรับปรุงเพื่อให้ Cover-Agent มีความทนทานในสถานการณ์ลักษณะนี้
มีการเพิ่มความสามารถให้ผู้ใช้ส่งข้อมูลหรือคำสั่งเพิ่มเติมให้ LLM ได้ใน flow ของ Cover-Agent (--additional-instructions)
สิ่งนี้ช่วยให้นักพัฒนาปรับแต่ง Cover-Agent ด้วยข้อมูลเพิ่มเติมที่เฉพาะกับโปรเจกต์ได้
ตัวอย่างเช่น สามารถใช้คำสั่งนี้เพื่อชี้นำให้ Cover-Agent สร้างชุดเทสต์ที่มี edge case สำคัญและมีความหมาย
พร้อมกับเห็นด้วยกับแนวโน้มทั่วไปที่ Retrieval-Augmented Generation(RAG) แพร่หลายมากขึ้นในแอปพลิเคชันที่ขับเคลื่อนด้วย AI ก็พบว่าการมีบริบทมากขึ้นสำหรับการสร้าง unit test ช่วยให้ได้เทสต์คุณภาพสูงขึ้นและมีอัตราการผ่านสูงขึ้น
เพื่อปรับปรุงกระบวนการสร้างเทสต์ จึงมีตัวเลือก --included-files สำหรับผู้ใช้ที่ต้องการเพิ่มไลบรารีเพิ่มเติมหรือเอกสารออกแบบแบบข้อความเข้าไปเป็นบริบทให้ LLM ด้วยตนเอง
โค้ดที่ซับซ้อนและต้องอาศัยการทำซ้ำหลายรอบยังเป็นความท้าทายอีกอย่างสำหรับ LLM
เมื่อมีการสร้างเทสต์ที่ล้มเหลว (หรือไม่ได้เพิ่มคุณค่า) ก็เริ่มพบรูปแบบที่เทสต์ที่ไม่ถูกยอมรับเดิมถูกเสนอซ้ำในรอบถัด ๆ ไป
เพื่อแก้ปัญหานี้ จึงเพิ่มส่วน "failed tests" ใน prompt เพื่อส่ง feedback นั้นให้ LLM และป้องกันไม่ให้มันสร้างเทสต์ซ้ำที่เคยตัดสินแล้วว่าใช้ไม่ได้ (เช่น พังหรือเพิ่ม coverage ไม่พอ) อีก
อีกปัญหาหนึ่งที่เกิดขึ้นตลอดกระบวนการคือ เมื่อขยาย test suite เดิม จะไม่สามารถเพิ่มการ import ไลบรารีได้
บางครั้งนักพัฒนาอาจมองแคบเกินไปด้วยการใช้แนวทางเดียวกับ testing framework ในกระบวนการสร้างเทสต์
นอกจาก mocking framework ที่มีหลากหลายแล้ว ยังมีไลบรารีอื่นอีกที่อาจช่วยให้บรรลุ test coverage ได้
เนื่องจากบทความวิจัย TestGen-LLM (รวมถึง Cover-Agent) มีจุดมุ่งหมายเพื่อขยาย test suite เดิม การปรับโครงสร้าง test class ทั้งชุดใหม่ทั้งหมดจึงอยู่นอกขอบเขต
นี่คือข้อจำกัดของการขยายเทสต์เมื่อเทียบกับการสร้างเทสต์ใหม่ และมีแผนจะจัดการในรอบถัดไป
สิ่งสำคัญคือต้องแยกความต่างว่า ในแนวทางของ TestGen-LLM จำเป็นต้องมีการรีวิวแบบแมนนวลโดยนักพัฒนาสำหรับแต่ละเทสต์ก่อนที่จะมีการเสนอเทสต์ถัดไป
ขณะที่ใน Cover-Agent จะสร้าง ตรวจสอบ และเสนอเทสต์ให้ได้มากที่สุดโดยไม่มีการแทรกแซงแบบแมนนวลตลอดกระบวนการ จนกว่าจะบรรลุข้อกำหนดด้าน coverage (หรือหยุดเมื่อถึงรอบสูงสุด)
เป็นแนวทางการสร้างเทสต์อัตโนมัติแบบไม่รบกวน โดยใช้ AI ทำงานเบื้องหลัง เพื่อให้นักพัฒนาสามารถรีวิว test suite ทั้งชุดได้ครั้งเดียวหลังจากกระบวนการเสร็จสิ้น

บทสรุปและแผนในอนาคต

หลายคน (รวมถึงตัวฉันเอง) คาดหวังกับบทความวิจัยและเครื่องมือ TestGen-LLM มาก แต่โพสต์นี้พูดถึงข้อจำกัดของมัน
เรายังอยู่ในยุคของ AI assistant มากกว่าจะเป็นเพื่อนร่วมทีม AI ที่รัน workflow แบบอัตโนมัติเต็มรูปแบบได้ด้วยตัวเอง
ในขณะเดียวกัน flow ที่ออกแบบมาอย่างดีสามารถช่วยให้นักพัฒนาสร้างผู้สมัครเป็นเทสต์ได้โดยอัตโนมัติ และเพิ่ม code coverage ได้ในเวลาที่สั้นลงมาก ซึ่งเป็นสิ่งที่วางแผนจะพัฒนาและแบ่งปันใน Cover-Agent
มีแผนจะพัฒนาวิธีการล้ำสมัยที่เกี่ยวข้องกับโดเมนการสร้างเทสต์อย่างต่อเนื่อง และรวมเข้าไปในโอเพนซอร์สรีโพซิทอรีของ Cover-Agent
หวังว่าทุกคนที่สนใจ generative AI สำหรับงาน testing จะเข้ามาร่วมมือกัน ช่วยขยายความสามารถของ Cover Agent และหวังว่าจะสร้างแรงบันดาลใจให้นักวิจัยใช้เครื่องมือโอเพนซอร์สนี้สำรวจเทคนิคการสร้างเทสต์ใหม่ ๆ
ได้เพิ่ม roadmap การพัฒนาไว้ในรีโพซิทอรีโอเพนซอร์ส Cover-Agent บน GitHub แล้ว และอยากเห็นการมีส่วนร่วมในรีโพซิทอรีตาม roadmap หรือแม้แต่ไอเดียของคุณเอง
วิสัยทัศน์ของ Cover-Agent คือในอนาคตจะทำงานอัตโนมัติสำหรับทุก pre/post-pull request และเสนอการปรับปรุง regression test ที่ได้รับการตรวจสอบแล้วว่ารันได้จริงและช่วยเพิ่ม code coverage โดยอัตโนมัติ
ลองจินตนาการว่า Cover-Agent สามารถสแกน codebase โดยอัตโนมัติและเปิด PR พร้อม test suite ให้ได้
มาลองใช้ AI จัดการงานที่เราไม่ชอบให้มีประสิทธิภาพมากขึ้นกันเถอะ!