มาเพิ่มเติมจากบล็อกที่แล้วที่ผมได้เขียน "สรุปแนวคิด THE TWELVE FACTORS ในภาพเดียวจบ" เพื่อให้เห็นภาพได้ชัดเจนขึ้นว่า ถ้าต้องการทำ The Twelve

ถ้าจำครั้งที่ผมเขียนถึงการทำงานที่ Ookbee Mall และพยายามทำ AWS Cloud ให้มัน Auto-Scaling ได้เนียนๆ ผมรู้สึกเสียดายทันทีที่ไม่รู้จักวิธีการของ The Twelve Factors ในตอนนั้น, ซึ่งถ้ารู้ ก็จะเป็นไกด์อย่างดีที่จะพาผมไปพบ Solution ในการทำเว็บให้รองรับ Cloud และรองรับการขยายของ Cloud ได้ โดยไม่ต้องงมเข็มในมหาสมุทร ผมมีโอกาสได้ฟังอาจารย์อู๋เล่าเรื่อง The Twelve Factors อยู่หลายครั้ง แต่เพิ่งมีโอกาสได้หาข้อมูลเพิ่มและคุยเพื่อประติดประต่อเรื่องนี้แบบจริงจัง เพื่อให้เห็นความเชื่อมโยงกันเป็นภาพเดียวกัน ผสมกับความรู้อื่นๆและประสบการณ์ตัวเอง เลยลองแชร์ให้ได้อ่านกัน

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

จากที่ได้ทำงานร่วมกับลูกค้า และพบเองในกลุ่ม 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