หลังจากเขียนเรื่อง Unit Test ไปก็หลายบล็อก ไล่ตั้งแต่เรื่องพื้นฐานอย่าง การออกแบบระบบให้รองรับการทดสอบ (Testable) มาจนถึง วิธีการคิดและลงมือทำ Automated Test ด้วย Unit Test และ รูปแบบการทดสอบของ Unit Test ก็ยังเหลือเรื่องหนึ่งที่สำคัญมากและหลายคนอาจจะสงสัยตอนที่ทำ Unit Test นั่นก็คือ "จะทำอย่างไร เมื่อสิ่งที่เราทดสอบ อย่าง Class, Function มันต้องไปทำงานร่วมกับสิ่งอื่นๆ เช่น Class อื่นๆ, Function อื่นๆ, Database, API ตัวอื่นๆ ของเรา หรือ API ภายนอกระบบ" ..

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

จากที่ได้ทำงานร่วมกับลูกค้า และพบเองในกลุ่ม Coach ตอนทำงานกันเอง คือการพูดถึงเรื่อง Unit Test ที่เขียนอย่างไรถึงจะถูกต้อง? เช่น ขนาดของ Unit Test ต้องเล็กขนาดไหน?, ทดสอบ Method ที่เรียกหา Method อื่นๆ ตัวเดียวได้ไหม? เป็นต้น โพสต์นี้ผมจะอ้างอิงถึงลุง Martin Fowler เยอะหน่อย เพราะไปอ่านที่แกอธิบายไว้เรื่อง UnitTest และ Mocks Aren't Stubs ได้น่าสนใจมาก

หลังจากได้เขียนอธิบายเรื่อง "จะทำระบบให้รองรับ Automated Test ได้อย่างไร (Testable)" ไปคราวก่อน ได้รับผลตอบรับด้วยดี คราวนี้เลยมาเขียนเพิ่มเติมเพื่อเป็นตัวอย่างแก่ผู้ที่ต้องการนำไปพัฒนาระบบจริง โดยในบล็อกนี้ผู้อ่านจะได้เห็นภาพของสิ่งเหล่านี้ คือ

• กระบวนการคิดเพื่อเตรียมทำ Automated Test
• Unit Test
• Integration Test
• DI (Dependency Injection)
• Stub (Test Double)
• Code Coverage

ช่วงนี้ได้มาช่วยสอนอาจารย์ที่มหาวิทยาลัยเทคโนโลยีราชมงคลธัญบุรี 3 วัน เรื่อง Agile for Software Development กับชาวคณะ มี Prathan D. , aj.jammy และ Nitipat Lowichakornthikun ก็ได้ทบทวนเรื่องราว อัพเดทเทคนิคการสอน และอัพเดทข้อมูลจากทางพี่หนุ่มด้วย

อาจเพราะผมไม่ได้เข้ามาร่วมทีมสัมนาของบริษัทหลายครั้ง พบว่าเทคนิคการเล่าเรื่องของพี่หนุ่มเปลี่ยนไป ฟังเพลิน เหมือนประวัติศาสตร์ ที่มันมี Timeline และการเชื่อมโยงเหตุการณ์ กับหัวข้อต่างๆ เลยอยากจั่วหัวบล็อกว่า A Brief History of Agile ดูเข้าท่าดี (ล้อชื่อหนังสือ A Brief History of Time และรำลึกถึง Stephen Hawking ผู้เขียน)