สคริปต์ Commit Message ของผมมี 8 Assertions ใน Selftest แต่ไม่มีอันไหนแตะโค้ดที่พังจริงเลย

ในโปรเจกต์นี้มีไฟล์ทั้งหมดสามไฟล์ที่เรียกใช้งานเครือข่ายภายนอกหรือรัน subprocess ซึ่งมีความเสี่ยงที่จะเกิดข้อผิดพลาดในหลากหลายรูปแบบ ได้แก่ publish_devto.py, server.py และ git_commit.py โดยสองไฟล์แรกมีบล็อก --selftest ที่ทำหน้าที่ stub การเรียกใช้งานที่มีความเสี่ยงและจำลองกิ่งก้านสาขาที่เกิดความผิดพลาดไว้เรียบร้อยแล้ว

ทว่า git_commit.py กลับไม่มีการเขียนทดสอบในลักษณะเดียวกัน ซึ่งผู้พัฒนาเพิ่งสังเกตเห็นหลังจากเริ่มรู้สึกสงสัยใน test coverage ของตัวเอง หลังจากได้ไปอ่านโพสต์ยอดนิยมเกี่ยวกับการนับจำนวน assertions ในชุดทดสอบแล้วพบสิ่งที่ไม่น่าพึงพอใจ

สคริปต์ git_commit.py ทำหน้าที่อ่าน staged diff แล้วเรียกคำสั่ง claude -p เพื่อแปลงออกมาเป็น commit message โดยมี exit paths แยกย่อยถึง 5 เส้นทาง ซึ่งทั้งหมดถูกสร้างขึ้นเพื่อคอยป้องกันข้อผิดพลาดจริงที่ผู้พัฒนาเคยเจอมาแล้วในโปรเจกต์นี้

หากลองเทียบกับบล็อก --selftest ของอีกสองไฟล์ที่เขียนขึ้นในสัปดาห์เดียวกัน จะเห็นว่าถูกตั้งมาตรฐานไว้ต่างกันอย่างสิ้นเชิง เช่นใน publish_devto.py มีการเขียน stub ครอบ urllib.request.urlopen เพื่อจำลองเคสพัง:

def _fake_url_error(req, timeout=30): raise urllib.error.URLError("timed out")

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ปัญหาหลักของ git_commit.py คือโครงสร้างโค้ดที่มีความยาวราว 20 บรรทัดและรันแบบ top-level script ทั้งหมด ตั้งแต่อ่าน diff, เรียก claude -p ไปจนถึงพิมพ์ผลลัพธ์ โดยมีเพียงเงื่อนไขดัก if "--selftest" in sys.argv: ... raise SystemExit(0) อยู่ด้านบนสุดเท่านั้น ทำให้ไม่มีฟังก์ชันให้เรียกใช้งานพร้อมกับสลับค่า subprocess.check_output ได้โดยตรง

แนวทางแก้ไขที่ตรงจุดจึงแบ่งออกเป็นสองขั้นตอน ได้แก่ การย้ายตรรกะการอ่าน diff และสร้างข้อความให้อยู่ในรูปแบบฟังก์ชันเช่นเดียวกับไฟล์พี่น้องทั้งสอง และนำวิธี stub-and-assert แบบเดียวกับที่ใช้ใน already_published(), _gh() และ _dev() มาประยุกต์ใช้ต่อไป ซึ่งเป็นแนวทางที่ปรากฏอยู่ในโปรเจกต์เดียวกันนี้อยู่แล้ว

ที่มา: Dev.to