สรุปจาก Practical unit testing(GDC 2014): DEEP anti-pattern

สวัสดีครับ บล็อกนี้เรามาต่อกันที่ anti-pattern ตัวที่ 3 ก็คือ DEEP anti-pattern

ปัญหาคือเวลามี test ที่ไม่ผ่านแล้ว ดูที่ result แล้วมันดูไม่ออกว่ามันพังอะไร

ส่วนใหญ่ที่มีปัญหานี้เกิดจากการที่ test นั้นมันมี  assertion หลายๆอัน ซึ่งละเมิดหลักการเขียน unit test ที่ควรจะมี explicit assertion เพียงอันเดียว

ซึ่งมันทำให้สื่อสารไม่ชัดเจนว่า test  นี้เราจะทดสอบอะไรกันแน่ แน่นอนว่า ผลกระทบก็คือ แก้ไขยาก ต้องใช้เวลาในการทำความเข้าใจ และทำให้ test นั้นเชื่อถือไม่ได้

ทางแก้ก็คือให้แยะ test case ออกมาให้ชัดเจนไปเลยครับ

ทีนี้ เมื่อมาดูผลของการรัน test ก็จะพบว่าอ่านรู้เรื่องมากขึ้น น่าจะนำมาซึ่งการแก้ไขที่ง่ายขึ้นนะ ดังนั้นเราควรจะลดจำนวน assertion ใน test  ให้เหลือน้อยที่สุดเท่าที่เป็นไปได้นะครับ 

สรุปจาก Practical unit testing(GDC 2014): WET anti-pattern

ต่อจากบล็อกที่แล้วนะครับ มาดู anti pattern ลำดับต่อมากัน

WET anti-pattern

มันคืออะไร ลองไปค้นในกู้กิ้ลดูก็เจอ wikipedia อันนี้ครับ

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

ก็ประมาณว่า WET เนี่ยมันจะย่อมาจาก Write Everything Twice หรือ We Enjoy Typing ก็ได้

แปลลวกๆก็คือ การที่เราชอบพิมอะไรเยอะๆ หลายๆครั้งนั่นเอง (ก็อปวางก็เข้าข่ายนะครับ อิอิ)

ในวีดีโอนั้นยกตัวอย่างว่า เวลาเราแก้ไขโค้ดจริงแล้ว test มันพัง(ซึ่งก็ถูกแล้วนะ) ที่นี้พอไปดูว่า test มันพังตรงไหนก็เจอเพียบเลย อย่างนี้ test มันก็มาขัดขวางการทำงานของเราน่ะสิ!

สาเหตุก็มากจากเจ้า WET นี่เองครับ ลองดูจากตัวอย่างที่เค้ายกมา จะเห็นว่า ใน test มันมีอะไรซ้ำๆกันเยอะเลย

ก็คือใน test  ของเราไม่ได้ยึดหลัก DRY(Don’t Repeat Yourself) เลยนะ!

ดังนั้นจึงควรแก้ไขโดยการ extract  มันออกมาเป็น helper function ซะ

ตรง Assertion ก็เช่นกันควรทำให้มันสื่อสารให้ชัดเจนว่าเราต้องการทดสอบอะไร เพื่อให้ test ของเรามันแก้ไขดูแลรักษาได้ง่าย แนะนำให้สร้าง Custom assert ขึ้นมาเลยครับ

แต่จุดที่ควรจะปล่อยเอาไว้คือ ในส่วนที่เป็น Act ต้องคงไว้ เพราะมันคือสาระสำคัญของ test ของเราครับ

สรุปอีกที่ WET anti-pattern  ก็คือการที่เราปล่อยให้มีโค้ดที่ซ้ำๆกันในเทส แล้วละเลยไม่ได้จัดการอะไรกับโค้ดซ้ำๆเหล่านั้นเลย ซึ่งเราอาจจะทำได้อย่างดีในโค้ดหลัก แต่ไม่ได้ทำในส่วนของ test นำมาซึ่งปัญหาในการแก้ไขในระยะยาว ดังนั้น ถ้าจะเขียน unit test แล้ว ก็ต้องดูแลมันไปพร้อมๆกันทั้งหมดนะครับ ไม่งั้นมันจะกลับมาหลอกหลอนคุณแน่นอน

บล็อกหน้ามาต่อกันที่ DEEP anti pattern ครับ 

สรุปจาก Pratical unit testing(GDC 2014): Opaque anti-pattern.

สวัสดีครับ พอดีเปิดไปเจอวีดีโอน่าสนใจเข้าอันนึงเกี่ยวแนวทางการเขียน unit test จากงาน Game dev conference เมื่อปี 2014 เลยเอามาสรุปเก็บไว้ครับ

ในวีดีโอนั้นจะพูดถึง Anti pattern ในการเขียน unit test 4 แบบด้วยกัน วันนี้เราจะมาเริ่มที่แบบแรกกันก่อน

Opaque anti-pattern

ลองไปเปิดดิกดู Opaque นั้นก็แปลว่า ทึบ, อับแสง, ไม่โปร่งใส่ แล้วมันเกี่ยวอะไรกับการเขียนเทส ลองมาดูกัน

1.Hard to see HOW.

คือโค้ดที่ดูยากว่ามันทำงานอย่างไร มันทำให้ยากต่อการทำความเข้าใจ ดูแลยาก แก้ไขยาก

2.Magic literals

การที่ในโค้ดมี ตัวเลขหรือค่าคงที่อยู่ ซึ่งมันทำความเข้าใจมันได้ยากว่าค่าพวกนั้นคืออะไร ทำไมมันต้องเป็นค่านั้น ดังนั้น เราควรที่จะตั้งชื่อตัวแปรให้ชัดเจนนะครับ

3.Informative consistent test name.

ก็คือชื่อ test ที่ไม่ได้สื่อว่า test นั้นจะทดสอบอะไร คาดหวังอะไร ซึ่งในวีดีโอนั้นได้แนะนำรูปแบบการตั้งชื่อ test ตามรูป

4.Arrange-Act-Assert.

test ที่ไม่ได้แบ่งให้เห็นชัดเจนระหว่างสามขั้นตอนนี้ ดังนั้นก็ควรจะแบ่งให้ชัดเจนนะครับ

จบแล้วครับ เดี๋ยวมาต่อตอนหน้า กับ WET anti pattern 

ลองกดดูวีดีโอด้วยนะครับ