เจอ VDO จากงาน London Gophers Meetup ซึ่งมีหัวข้อน่าสนใจดังนี้ Warning data race exit status 66 Go three months in Absolute Unit (Test) Decoding binary network protocol สามารถดู VDO ของหัวข้อต่างได้ที่ Youtube แต่หัวข้อที่จะทำการสรุปคือ Absolute Unit (Test) พูดโดยคุณ Dave Cheney มีหลายเรื่องที่น่าสนใจมาเริ่มกัน
สิ่งที่น่าสนใจอย่างหนึ่งของนักพัฒนา software คือ มักจะพัฒนาให้มันเสร็จตามเวลา ส่วนเรื่องของความถูกต้องและคุณภาพก็ให้ความสำคัญนะ แต่ไม่ค่อยเน้นมากเท่าไร !! บ่อยครั้งกลับพบว่า จำนวนข้อผิดพลาดจำนวนมากจากการพัฒนา จากสิ่งที่บอกว่าเสร็จแล้ว เป็นประเด็นที่น่าสนใจคือ สิ่งที่นักพัฒนาบอกว่า เสร็จมันคืออะไรกันแน่
เห็นใน facebook มีคำถามว่า เขียน Unit testing แบบไหนถึงดี ? เป็นคำถามที่ตอบยากมาก ๆ เพราะว่าคำว่า “ดี” นั้นแตกต่างกันเหลือเกิน แต่คิดว่ามันเป็นสิ่งที่ดีนะ จึงเริ่มด้วยคำถามก่อนว่า ทำไมการทดสอบ code ของเราจึงมีความสำคัญ
สำหรับนักพัฒนาที่เขียน test หรือชุดการทดสอบ นะ !! มาดูกันว่า ชุดการทดสอบมันส่งกลิ่นแปลก ๆ บ้างหรือไม่ ? ปกติ code ที่นักพัฒนาสร้างขึ้นมา มักจะมีสิ่งแปลก ๆ มักจะส่งกลิ่น หรือ ส่งสัญญาณของปัญหาออกมา ซึ่งเราเรียกว่า Code Smell ปัญหามันไม่ใช่ Code Smell เพียงอย่างเดียว แต่ …. มันมีอย่างอื่นอีกเช่น เรารู้หรือไม่ว่าสิ่งเหล่านั้นมันคือ Code Smell !! ถ้าพูดง่าย ๆ คือ เรามีจมูกที่ดีหรือไม่ เรามีสายตาที่ดีหรือไม่ เพื่อทำให้ได้กลิ่น ให้มองเห็น Code Smell หรือสิ่งที่ผิดปกติหรือไม่ ? นั่นคือสิ่งที่นักพัฒนาต้องสร้างและปรับปรุงความสามารถขึ้นมา
เมื่อหลายวันก่อนพูดคุยเกี่ยวกับ Unit testing เลยได้มีโอกาสแลกเปลี่ยนมุมมองต่อการเขียนและการนำมาใช้งานนิดหน่อย ซึ่งสิ่งหนึ่งที่น่าสนใจคือ ความเข้าใจผิด ยกตัวอย่างเช่น ถ้าเรามี Unit tests แล้ว bug ของระบบจะไม่มี ถ้าเรามี Unit tests แล้วคุณภาพของระบบต้องดีแน่ ๆ รวมทั้ง code ด้วย ถ้า Unit tests มันไม่มีประโยชน์อะไร ก็ไม่ต้องทำ เลยนำมาอธิบายไว้นิดหน่อย
เมื่อวานมีโอกาสแบ่งปันความรู้เรื่องการใช้งาน Version Control ด้วย Git ไป การ commit หรือบันทึกการเปลี่ยนแปลง การ push หรือการส่งการเปลี่ยนแปลงไปยัง remote repository การ pull หรือการดึงการเปลี่ยนแปลงจาก remote repository มายังเครื่องเรา ทั้งหมดนี้คือ การพูดคุยและการทำงานร่วมกันของทีมพัฒนา ยิ่งทำการ commit/push/pull บ่อย ๆ มากเพียงใด ปัญหาที่เกิดก็จะน้อยลงไป !! ลองคิดสิว่าระหว่าง commit บ่อย ๆ กับนาน ๆ ครั้ง แบบไหนจะดีกว่ากัน
สัปดาห์ที่ผ่านมามีโอกาสแบ่งปันประสบการณ์เรื่อง การเขียน Unit test โดยเป็นสิ่งที่นักพัฒนาทุกคนควรทำ ถ้าเขียน code ได้แล้วก็เขียน Unit test ได้เช่นกัน ที่สำคัญ code ของ Unit test นั้น ต้องได้รับการดูแลเยี่ยง production code นั่นคือ ต้องทำการดูแลและปรับปรุงให้ดีขึ้นอยู่เสมอ มิฉะนั้นมันจะมาทำร้ายเราแน่นอน
เช้านี้นั่งอ่านบทความเก่า ๆ ที่เก็บเอาไว้คือ 5 Common Misconceptions About TDD & Unit Tests อธิบายเกี่ยวกับความเข้าใจผิดเกี่ยวกับ TDD และ Unit Test จึงทำการแปลและสรุปเนื้อหาบางส่วนไว้นิดหน่อย
พอดีต้องพัฒนาระบบด้วย JavaScript ซึ่งต้องนำ Webpack มาใช้ด้วย สิ่งแรกที่ต้องการคือ การเขียน unit test เมื่อไปค้นหาก็เจอบทความเกี่ยวกับ Mocha + Webpack เยอะเลย ส่วน assertion ก็นำ chai มาช่วยนิดหน่อย มาเริ่มกันเลย
วันนี้มาแนะนำการพัฒนาระบบงานด้วยแนวคิด TDD (Test-Driven Development) จึงทำการสรุปข้อดีและข้อเสียของแนวคิดนี้ไว้นิดหน่อย เพื่อทำให้เข้าใจกันมากขึ้น