กว่าจะเจอว่ามันพัง ก็เทสไปจนเกือบเสร็จแล้ว
แล้วก็ต้องวนกลับไปแก้ใหม่อีกรอบจนได้
.
แล้วมันก็เป็นแบบนี้ทุกที ไม่รู้ทำไมบั๊กมันงอกมาตอนท้ายทุกที
ทั้งๆ ที่มันน่าจะเจอเร็วกว่านี้ได้นะ
แล้วเราก็เริ่มคิดว่า หรือควรจะมี unit test เพิ่มตรงนี้หน่อยดีมั้ยนะ
แต่ก็ไม่รู้จะเดินไปคุยกับ dev ยังไง เพราะเคยเกริ่นๆ ไปแล้ว แต่ทีมบอกว่ามันทำไม่ได้
.
วันนี้สอนคลาส Automation วันแรกไปค่ะ
แล้วก็มีคำถามเรื่อง unit test เข้ามาพอดี
ซึ่งจริงๆ พี่กิ่งเจอคำถามนี้ซ้ำๆ มาหลายปี
เป็นหนึ่งในปัญหาสำคัญที่ต้องเข้าไปช่วยแก้ให้ในงานที่ทำในช่วงที่ผ่านมาเลยค่ะ
.
แต่รู้อะไรมั้ยคะ หลายๆ ครั้ง มันไม่ใช่ว่า “dev ไม่ยอมทำ” แบบที่เราคิดเสมอไป
เค้าไม่ได้กำลังปฏิเสธเรานะคะ แต่เค้ายังไม่เคยเห็นภาพว่าเทสมันควรเข้าไปเช็คอะไรบ้าง
หรือบางทีมันก็มีปัญหาเรื่อง architecture ที่ลึกไปกว่านั้น (ที่เราจะยังไม่แตะวันนี้นะคะ)
เพราะฉะนั้น การที่เราเดินดุ่มๆ ไปบอก dev ว่า ทำ unit test เพิ่มให้หน่อย
มันเหมือนเราไปเพิ่มงานให้เค้า โดยที่ไม่มีไกด์ไลน์อะไรให้เลย
.
ลองคิดถึงพวก field validation ทั้งหลายที่เรามักจะต้องเทสกันดูค่ะ
เว้นว่าง
กรอกค่าติดลบ
กรอกตัวอักษรในช่องที่เป็นตัวเลข
กรอกค่าที่มากเกิน maximum
กดซ้ำสองรอบ
หรือ validation อีกมากมายที่จะเกิดขึ้นได้
ถ้าเราเก็บมาเทสเอาตอนที่หน้า UI เสร็จหมดแล้ว
มันทั้งช้า ทั้งมี dependency กับอะไรอีกมากมายหลายอย่าง
และที่สำคัญคือ กว่าเราจะรู้ว่ามันพัง มันก็ช้าเกินไปแล้ว
.
Test pyramid ที่มี unit test/integration test/e2e test ที่เราคุยกันไป
ไม่ใช่กฎหมายบังคับให้เราต้องทำตามแบบนั้นเป๊ะๆ นะคะ
แต่มันเป็นไกด์ไลน์ที่ช่วยให้เรารู้ว่า เราควรจะไปทางไหน
ทีมอาจจะทำได้เลย หรืออาจจะใช้เวลาในการปรับเปลี่ยน
แต่อย่างน้อย เราก็รู้ว่ากำลังเดินไปถูกทางรึเปล่า
.
📌 ถ้าใครอยากลองเริ่มคุยเรื่อง unit test
วิธีที่ง่ายที่สุดที่เริ่มได้เลยคือ เอา scenario ที่เราออกแบบไว้ ไปคุยกับ dev ให้เร็วที่สุดเลยค่ะ
แล้วลองปรึกษากันดูว่า อันไหนที่จะเริ่มเช็คตั้งแต่ unit test ได้บ้าง
จริงๆ แค่นี้ก็ช่วยได้เยอะแล้วค่ะ
(เอา scenario ไปคุย ก็พอนะคะ ไม่ต้องเอา test case ละเอียด 300 ข้อไป
เพราะแบบนั้นทุกคนอาจจะอ๊องไปก่อนที่จะคุยกันรู้เรื่องก็ได้)
.
แทนที่จะถามว่า “ทำไมไม่ทำ unit test”
เปลี่ยนเป็น “เราจะดักตรงไหนได้บ้าง”
แค่นี้บทสนทนาก็เปลี่ยนไปเยอะแล้วค่ะ