Screen Shot 2558-07-21 at 6.08.22 PM
เรามักจะได้ยินประโยคเหล่านี้เกี่ยวกับ unit test บ่อยๆ เช่น

เราไม่มีเวลาที่จะเขียน unit test หรอกนะ
เราไม่มีงบสำหรับการเขียน unit test หรอกนะ

หรือบางครั้งอาจจะได้ยินว่า

เราไม่ได้ใช้ TDD (Test-Driven Development) ดังนั้นเราจึงไม่ต้องมี unit test
TDD มันแพงไปสำหรับเราในตอนนี้

ฟังแล้วมันดูสมเหตุสมผลนะ ว่าไหม ?

ลองมาทำความเข้าใจกับ unit test กันหน่อยสิ

Unit test มันไม่ใช่ product
ดังนั้นมันจึงไม่ใช่สิ่งที่ลูกค้า หรือ ผู้ใช้งาน product ต้องการ

แต่มันคือ เครื่องมือ เพื่อช่วยทำให้

  • เราสามารถทดสอบการทำงานของ product ได้รวดเร็ว
  • ลดเวลา และ ค่าใช้จ่ายในการ regression ระบบงาน
  • ช่วยเพิ่มเรื่องความมั่นใจต่อ product ทั้งทีมพัฒนา และ ผู้ใช้งาน
  • ช่วยเพิ่มคุณภาพของ product ที่เราจะส่งมอบ

แปลกนะ ที่คนส่วนใหญ่มักบอกว่า
เราไม่มีเวลาสำหรับนำเครื่องมือเหล่านี้ไปใช้งาน
เพื่อทำให้เราพัฒนางานได้ดี และ เร็วขึ้น

ไม่ว่าคุณจะใช้ TDD หรือไม่ก็ตาม
Unit test มันก็คือ unit test
ที่สามารถเขียนก่อน หรือ เขียนหลัง การสร้าง production code
แต่ผมแนะนำให้เขียน test ก่อนดีกว่านะ (Test First)

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

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

ดังนั้น เมื่อคุณไม่รู้ว่ากำลังทำอะไร
แล้วผลลัพธ์ที่ออกมามันจะยังมีคุณภาพอีกหรือ ?
หรือต้องภาวนาให้มันทำงานได้นะ ?

บางคนที่บอกว่า เราไม่มีเวลาเขียน unit test หรอกนะ

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

ทุกๆ เดือนคุณได้เงินเดือน แต่ในทุกๆ วันคุณกลับสร้าง code แบบลวกๆ
คุณคิดว่านั่นมันเหมาะสมไหม ?
คุณคิดว่านั่นมันคือวิชาชีพของคุณไหม ?
คุณคิดว่าคุณมีความเป็นมืออาชีพไหม ?

ดังนั้น ผมคิดว่าคุณต้องเริ่มสนใจ และ ใส่ใจ ในสิ่งที่คุณทำได้แล้วนะ
หนึ่งในนั้นคือ การเขียน unit test

ปกติ developer ทำการทดสอบระบบ หรือ code อย่างไร ?

วิธีการที่เราเห็นบ่อยๆ ใน web application คือ F5 หรือ Cmd + R ไงล่ะ
ทำเฉพาะหน้าที่เราทำ หรือ แก้ไข ด้วยนะ
ดังนั้น developer ทำการทดสอบนะ
แต่ทดสอบเฉพาะส่วนเท่านั้น !!!

คำถามคือ มันเพียงพอแล้วหรือ ?

ประโยคที่เรามักได้ยินบ่อยๆ คือ
เครื่องผมไม่เห็นเป็นอะไรเลย ไหนลอง clear cache สิ !!

หรือในโลกของ Enterprise ก็มีเรื่องขำไม่ออกเช่นกันนะ
แน่นอนว่า Enterprise developer เขาไม่มีเวลามากนักหรอก
ดังนั้น เรื่องของ unit test ลืมไปได้เลย

ยิ่งถ้าพัฒนาด้วยภาษา OOP แล้วด้วย เราจะมี class จำนวนมากมาย
แต่สิ่งที่น่าตกใจคือ ในแต่ละ class ดันมี method จำนวนมากเช่นกัน
ใน 1 class อาจจะมีจำนวน code ถึง 10,000 บรรทัดก็เป็นได้

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

มันเป็นคำตอบที่ … มากมาย
เชื่อว่า ถ้าเป็น developer ที่ดีคงไม่ทำกันใช่ไหมครับ ?

เหตุผลที่บอกว่า ไม่มีเวลา นั้นมันไม่น่าจะใช่เหตุผลจริงๆ
แต่ ความจริงก็คือ คุณมีปัญหาเรื่องของความรู้ และ วินัยมากกว่า !!
ทั้งความรู้พื้นฐานของ OOP เช่น

  • Encapsulation
  • Inheritance
  • Polymorphism
  • Overloading
  • Interface

การเขียน Unit test ก็เช่นเดียวกัน

ลองคิดดูสิ code ที่คุณเขียนขึ้นมา 10,000 บรรทัด
โดยที่ไม่ได้เขียน unit test ซึ่ง code เหล่านั้นมันอาจจะทำงานได้อย่างถูกต้อง
เน้นว่าอาจจะทำงานได้ !!
แต่คำว่า คุณภาพล่ะ คุณคิดว่ามันดีแล้วหรือ ?

มันไม่ใช่เพราะว่า คุณไม่มีเวลาเขียน unit test หรอกนะ
แต่มันคือ คุณไม่รู้ว่าจะทำ หรือ เขียน unit test อย่างไรมากกว่า …

ดังนั้นถ้าเรายังไม่รู้ว่าจะเขียน unit test อย่างไร
เรามาเริ่มเขียนกันดีกว่าครับ