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

การไม่เขียนเทสต์ (หรือเขียนเทสต์ไม่ดี)เป็นบาปอย่างหนึ่ง เป็นเวรกรรมจะตามทันทีมในระยะเวลาไม่เกิน 3 เดือน

เวลาทำงานกับชาวต่างชาติที่ไม่เข้าใจคอนเซ็บเรื่องบาปบุญ ผมชอบอธิบายให้เค้าฟังแบบนี้

Writing code without tests (or low-quality tests) is like having one-night stand everyday without protection. You will eventually regret it.

เน้นนิดนึงว่าไม่ใช่แค่เรื่องไม่เขียนเทสต์ แต่รวมถึงกรณีเขียนเทสต์ไม่มีคุณภาพด้วย

บางทีมอาจจะบอกว่าเขียนแล้ว มี Coverage ครบ 100% เลยด้วย บาปเบิบอะไรไม่มีหรอก

แต่ก่อนคนเขียนก็คิดงี้ครับ จนกระทั่งได้มาเจอกับสถานการณ์ “เทสต์ท่วมหัว เอาตัวไม่รอด”

บทความนี้จะเล่าสู่กันฟังเรื่องตัวอย่างการเขียนเทสต์ที่ไม่ดีครับ ผู้อ่านจะได้หลีกเลี่ยงกัน โดยบทความนี้จะเน้นไปในส่วนของ Unit/Component Test เป็นหลัก

แต่ก่อนจะเข้าเรื่องเขียนเทสต์ให้ดี ผมขอยกปัญหาจากการไม่เขียนเทสต์ก่อนครับ

เผอิญช่วงนี้กลับมาไทย ได้ไปร่วมงาน DjangoGirls Bangkok มา และฟีดในเฟสบุ้คที่โผล่มาหาบ่อยที่สุดก็เป็นเรื่องที่เกี่ยวข้องพอดี

“ต้องเชียร์โปรแกรมเมอร์หญิงที่จะไปเป็นไอดอลอย่างไร ให้ไม่เข้าข่ายเหยียดเพศครับ”

กรณีไอดอลเนี่ย ผมเองก็ไม่รู้เหมือนกัน แต่เรื่องนี้ทำให้นึกถึงเรื่อง Gender Bias ที่จริงจังกันมากในต่างประเทศ

หลังจากนั่งอ่านคอมเม้นต์ในโพสต์นั้น, ได้ไปงาน DjangoGirls, รวมถึงเห็นกระแสของน้อง Turtle (น้องโปรแกรมเมอร์อินเทิร์นที่สมัคร BNK48) ผมรู้สึกว่าควรจะเขียนเรื่อง Gender Bias นี้ให้ได้อ่านกัน

บางคนอาจจะเห็นด้วย บางคนอาจจะไม่เห็นด้วย แต่การได้รับรู้ว่าเรามีประเด็นในเรื่องนี้อยู่ น่าจะมีประโยชน์ต่อวงการโปรแกรมเมอร์บ้านเรา

ความน่ารักของ Web Developer สมัยนี้คือมีการแยก Frontend กับ Backend ออกอย่างชัดเจน ถ้าใครย้อนกลับไปสมัยสิบปีก่อน เราไม่มีตำแหน่ง Frontend Developer ด้วยซ้ำ มีแต่เรียกรวมๆว่า Web Developer

การแยกกันของโค้ดสองส่วน ทำให้การ Deployment ทำแยกกันด้วย คำถามที่เกิดขึ้นคือ เวลาจะ Deploy เราจะเอา Frontend ขึ้นก่อน หรือ Backend ขึ้นก่อนดี

แม้จะเป็นคำถามง่ายๆ แต่รายละเอียดข้างในนั้นค่อนข้างเยอะ ถ้าไม่คิดให้ถี่ถ้วน อาจจะเจออาการเว็บพังขณะ Deploy เป็นประจำ

บทความนี้จะมาวิเคราะห์เจาะลึกกันในเรื่องนี้

ช่วงนี้ทีมขึ้นโปรเจ็คใหม่ ผมต้องคุยกับ QA Engineer เกี่ยวกับเรื่อง Testing Strategy บ่อยๆ

โดยเนื้อหาที่คุยหลักๆคือ

1. จะเทสต์อะไรบ้าง
2. จะเทสต์ด้วยเทสต์ชนิดไหน (ex. Unit, Component, Integration)
3. เราจะใช้เทสต์แต่ละชนิดในกรณีไหนบ้าง

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

หัวข้อด้าน Distributed System เป็นอะไรที่สนุก แต่เข้าใจยากมาก

หนึ่งในเรื่องที่ผมอ่านหลายรอบกว่าจะเก็ต ก็คือเรื่องของ CAP Theorem ซึ่งเป็นแนวคิดในการ Trade-off คุณสมบัติของ Distributed System ที่เราออกแบบ

“CAP” เป็นตัวย่อจาก Consistency, Availability, Partition Tolerant โดย Theorem นี้ได้กล่าวไว้ว่า คุณไม่มีทางที่่จะออกแบบระบบโดยมีคุณสมบัติ 3 ข้อนี้ พร้อมกัน อย่างเก่งก็ได้แค่ 2 ใน 3

แต่ทำไมถึงเป็นอย่างนั้นล่ะ?

วันนี้เราจะมาทำความเข้าใจกับเจ้า Theorem นี้กัน ผ่านการเรื่องราวของบริษัท “สุธีการจำ” !!