Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

มาปรับปรุงการเขียน Test กันหน่อย

$
0
0

การเขียน Test หรือชุดการทดสอบนั้นเป็นสิ่งที่ดี เริ่มเขียนว่ายากแล้ว การเขียนให้ดียากยิ่งกว่า ดังนั้นจึงสรุปวิธีปรับปรุงการเขียน Test ให้ดีขึ้น โดยนำมาจากบทความเรื่อง Write Better Tests in 5 Steps เริ่มกันเลย

Code ของ Test นั้นต้องดูแลให้เหมือนกับ Production code

นั่นหมายความว่า ถ้าเขียน Test แล้วต้องดูแลเป็นอย่างดี ให้เหมือนกับ code ของระบบงาน ใช้แนวปฏิบัติเหมือนกัน โดย feature ต่าง ๆ ที่ดีของระบบ ควรมีชุด Test code ที่อ่านและทำความเข้าใจได้ง่าย (Readability test) เพื่ออธิบายการทำงานของ code เพื่ออธิบาย business rule ว่าสร้างหรือทำงานอย่างไร เพื่อช่วยให้หาปัญหาได้ง่ายขึ้น รวมทั้งต้องไม่มี Test ที่ซ้ำซ้อนด้วย

วางโครงสร้างของ Test code ให้ดี

ในแต่ละ test case ควรมีโครงสร้างเดียวกัน หรือ ไปในทางเดียวกัน เพื่อช่วยทำให้ Test อ่านและทำความเข้าใจได้ง่ายขึ้น สิ่งชอบใช้คือ AAA (Arrange-Act-Assert)
  • Arrange เป็นการเตรียมสิ่งต่าง ๆ ก่อนการทดสอบ เช่นข้อมูลเริ่มต้นของการทดสอบ
  • Act เป็นการสร้าง action หรือเรียกใช้งานส่วนที่ต้องการทดสอบ
  • Assert ทำการตรวจสอบผลจากการทดสอบ ว่าเป็นไปตามที่คาดหวังหรือไม่
ยังมีโครงสร้างอื่น ๆ อีก เช่น Give-When-Then เป็นต้น

ดูแล Test ให้มีสุขภาพที่ดี ระวัง Test ที่ไม่เสถียร !!

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

เลือกระดับหรือชนิดการ Test ให้ถูกต้องและเหมาะสม

การ Test นั้นมีหลายระดับหลายชนิด แต่ละชนิดล้วนมีค่าใช้จ่ายด้วยกันทั้งสิ้น ทั้งการเขียน ทั้งเวลาในการทดสอบ ยกตัวอย่างเช่น ถ้าทำการทดสอบ UI Test เพียงอย่างเดียว เมื่อชุดการทดสอบเยอะขึ้น ต้องใช้เวลาในการทดสอบมากขึ้น ค่าใช้จ่ายเพื่อทำให้เร็วขึ้นก็สูงมาก ๆ ดังนั้นควรต้อง Test ในส่วนอื่น ๆ ด้วย เช่น Unit test และ Service test มากขึ้น แต่ถ้ายังไม่รู้ ก็จัดเต็มทุกส่วนเลย เพื่อทำให้รู้และเข้าใจว่า อะไรควรหรือไม่ควรทำ !!

ต้องเรียนรู้เทคนิคต่าง ๆ ในการ Test เพิ่มเติม

ยกตัวอย่างเช่นการ Mock หรือ Test Double เพื่อช่วยลดค่าใช้จ่ายหรือเวลาในการ Test ลงไป แต่ก็ต้องแลกมาด้วยการออกแบบระบบงานด้วย นั่นคือระบบจะต้องสามารถทดสอบได้ง่าย (Testable Architecture) ยกตัวอย่าง การจำลอง Database การจำลอง REST API server การใช้งาน Stub/Spy/Mock สำหรับการตัด dependency ต่าง ๆ ออกไปจาก code การจำลอง Environment สำหรับการทดสอบขึ้นมา เป้าหมายเพื่อ Fast feedback คือรูปผลการเปลี่ยนแปลงได้อย่างรวดเร็ว นั่นคือการลดค่าใช้จ่ายนั่นเอง
ลองแบ่งเวลามาเขียนและปรับปรุง Test กันเถอะ เพื่อสร้างระบบงานดีให้ผู้ใช้งานและลูกค้า รวมทั้งช่วยให้ทีมมีความเชื่อมั่นเมื่อทำการแก้ไขและดูแลระบบ รวมทั้งรู้ปัญหาได้อย่างรวดเร็ว
Reference Websites http://fabiopereira.me/blog/2012/03/18/introducing-depth-of-test-dot/ https://martinfowler.com/articles/nonDeterminism.html http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html https://www.thoughtworks.com/insights/blog/just-re-run-build-it-should-go-green http://xunitpatterns.com/Fragile%20Test.html

Viewing all articles
Browse latest Browse all 1997

Trending Articles