Unit tests คือ executable document

Unit tests คือ executable document
Photo by Giammarco Boscaro on Unsplash

เคยไหมที่เจอเหตุการณ์ให้ต้องไปอ่านโค้ดคนอื่น แล้วพออ่านเสร็จก็เห็นว่าโค้ดมันผิด เลยไปแก้มันให้ถูก แต่พอคิดอีกที ไม่แตะมันดีกว่า แล้วก็ undo จนมันกลับไปเป็นเหมือนเดิม

ทำไมนะ?

ผมเคยลองถามตัวเองดูว่าอะไรเป็นสาเหตุที่ทำให้ผมยอมทิ้งทั้งโอกาสและแรงที่ลงไปแล้ว ที่จะปรับปรุงโค้ดให้ดีขึ้นเพื่อตัวเองและเพื่อนร่วมทีมในอนาคต แล้วกลับไปอยู่กับโค้ดเดิม ๆ กันนะ

คำตอบที่ปรากฏออกมาคือ ผมกลัว กลัวว่าสิ่งที่แก้ไปจะไปสร้างปัญหาใหม่ที่ผมไม่คาดไม่ถึง และที่ผมกลัว เพราะ ผมไม่รู้ว่าที่โค้ดเป็นแบบที่มันเป็นอยู่ มันตั้งใจจะแก้ปัญหาอะไรบ้าง ผมมีข้อมูลไม่เพียงพอที่จะปรับปรุงมัน เพราะผมเห็นแค่ solution ใน source code แต่ไม่เห็น problem ที่โค้ดนี้พยายามจะแก้ (requirement)

แล้ว requirement อยู่ไหน?

ปรกติ requirement อยู่ใน requirement document ซึ่งบ่อนครั้งถูกจัดเก็บในรูปของ file word หรือ excel

แล้วปัญหาของการจัดเก็บ document ในลักษณะนี้คือ มันมักจะไม่ update เท่ากับโค้ด เอกสารเหล่านี้ถูกสร้างขึ้นมาบนสมมติฐานว่า user ต้องการแบบนี้ แต่พอทำไปแล้ว มี feedback จาก user ว่าอยากให้ปรับอย่างไร บ่อยครั้งมันไม่ถูก update ให้ตรงตามความเข้าใจในปัญหาที่เพิ่มพูนขึ้นจากการปฏิสัมพันธ์กับ user ส่งผลให้เอกสารมันไม่ถูกต้อง 100%

เอกสารที่แม่นยำ 99% ไม่มีประโยชน์

เพราะเราไม่รู้ว่า 1% ที่มันไม่จริงนั้นอยู่ตรงไหน ถ้าสามารถขอพรได้ เราอยากให้ตัวหนังสือที่จริงเป็นสีเขียว และเมื่อไหร่ที่มันไม่จริงขึ้นมา (outdated) ตัวหนังสือก็เปลี่ยนเป็นสีแดงโดยอัติโนมัติ แต่ชีวิตจริงมันไม่เป็นแบบนั้น

Unit test

unit test จึงถูกคิดขึ้นมาเพื่อแก้ปัญหานี้ โดยแต่ละ test จะเก็บ 1 ตัวอย่างที่ user อาจจะใช้งานระบบ พร้อมกับพฤติกรรมที่ user คาดหวังจากระบบ

เมื่อเราเขียนจนครบทุกกรณีที่ระบบจะถูกใช้งาน รวมถึงพฤติกรรมที่เราคาดหวังทั้งหมดไว้ เอกสารชุดนี้ก็เลยรวบรวมปัญหาที่ระบบจะต้องแก้เก็บไว้หรือที่เราเรียกว่า requirement นั่นเอง

และการเก็บ requirement ในรูปแบบที่สามารถ execute ได้ หมายถึงเอาไป run เพื่อเช็คความแม่นยำกับระบบจริง ๆ ได้ มีประโยชน์กว่ารูปแบบ file word หรือ excel เพราะเมื่อไหร่ที่มีกรณีไหนไม่เป็นจริงขึ้นมา test case นั้นก็จะระบายสีแดงขึ้นมาโดยอัตโนมัติ ส่วน test case ที่ยังเป็นจริงก็จะยังเขียวอยู่

สรุป

อยากชวนให้มอง unit test ให้เป็นเอกสาร อย่าสักแต่ว่าเขียนเพื่อทำให้ถึง code coverage ที่ตั้งใจไว้ ทุกครั้งที่เขียนให้จินตนาการว่ากำลังเขียนจดหมายถึงตัวเราเองและเพื่อนในทีมในอนาคต เวลาที่พฤติกรรมของระบบที่คาดหวังใน test case นี้มัน fail ขึ้นมา เราอยากให้ตัวเราในอนาคตรู้เรื่องอะไรบ้าง บางครั้งผมก็ reference ข้อมูลใน wiki หรือ knowledge management ขององค์กร บางครั้ง mention ชื่อ user ที่เป็นคนเล่าความยากลำบากที่เค้ากำลังเผชิญให้ผมฟัง

test case แต่ละอันเป็นเหมือนเชือก เราทำให้มันเป็นตาข่ายที่รับเราและทีมไว้ในวันที่เราพลาดไม่ให้ตกก็ได้ หรือทำให้มันเป็นแหที่มัดเราไว้ ไม่ให้เราแก้ซอฟต์แวร์ที่เป็นอยู่ก็ได้ ขึ้นอยู่กับว่าเราถนอมเรื่องราวหรือปัญหาที่เราพยายามจะแก้ในโค้ด (หรือ solution) ที่เราสร้างไว้ได้ดีแค่ไหน

unit test เปิดโอกาสให้เรามีเอกสารในฝันที่สามารถเปลี่ยนสีเขียวหรือแดงได้อย่าอัตโนมัติแล้ว มันคงน่าเสียดายถ้าเราสักแต่เขียนให้ได้ code coverage แต่ลืมที่จะถนอมปัญหาที่เราจะแก้ไว้ แล้วเขียนแค่ระบบต้องมีพฤติกรรมแบบนี้แหละโดยไม่เล่าเรื่องราวว่าเพราะอะไร

Read more

Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai
Vocal archetypes

Vocal archetypes

ผมกำลังเรียนวิธีใช้เสียงในคอร์ส Stage Academy ของ Vinh Giang ในคอร์ส ผมได้เรียนเกี่ยวกับแม่แบบของเสียง 4 รูปแบบดังนี้ Motivator ผู้จูงใจ เป้าหมายของผู้จูงใจคือการจุดประกายแรงบันดาลใจ องค์ประกอบของการใช้เสียงรูปแบบนี้คือ * เพิ่มความเร็วในการพูด * เปล่งเสี

By Chokchai
เขียน runtests script ให้เป็น executable document กันเถอะ

เขียน runtests script ให้เป็น executable document กันเถอะ

ตอนนี้แล้วผมกล่าวถึงความสำคัญของเอกสารที่สามารถ execute เพื่อตรวจสอบดูว่ามันยังจริงอยู่ไหมได้ในรูปแบบของ unit tests ซึ่งเอาไว้เก็บบริบทของปัญหาที่เรากำลังแก้ หรือเรียกง่าย ๆ ว่า requirement ตอนนี้เราจะมาพูดถึงเอกสารที่ใช้ในการ build software เช่น build script หรือแม้

By Chokchai

Pair programming 4 แบบ

เวลาผมสอนเรื่อง pair programming ปรกติผมจะเล่าคร่าว ๆ ว่า pair programming มี 2 แบบที่ผมใช้บ่อย ๆ คือ ping pong ที่ใช้เวลาคู่ pair ชำนาญพอ ๆ กัน กับ driver-navigator ที่ใช้เวลาความชำนาญต่างกัน ช่วงนี้มีโอกาสได้ pair กับสมาชิกในทีมบ่อย

By Chokchai