Assertion Component อย่างที่บอกไว้ใน blog ที่แล้วคือเราสามารถทดสอบได้โดยไม่ต้องเขียนโปรแกรม สร้างไฟล์ C# ขี้นมาใหม่เลยด้วยซ้ำ มักใช้กับ Integration Test (โดยติ๊กช่อง Suceed on Assertion เอาไว้) ซึ่งการ Test 1 Test จะมีองค์ประกอบต่างๆ ดังนี้

โดยมีตัวอย่างการใช้งาน (Scene Level 1) ดังนี้

1. FakeInput (When) เพื่อจำลองการใช้งานหรือเล่นเกมของผู้เล่น เช่น เปลี่ยนจาก Input จริงๆ ซึ่งเป็นการกดคีย์บอร์ดปุ่มลูกศรซ้ายค้าง มาเป็นการสั่งให้เซ็ตความเร็วยานอวกาศและเคลื่อนที่โดยอัตโนมัติด้วยทิศทางความเร็วอย่างไรโดยผ่าน Inspector โดยตรง ไม่ต้องรอ user สั่ง ซึ่งเราควรจะสร้าง Interface มาเป็นตัวกลางระหว่าง Class FakeInput และ Class RealInput ให้ทั้งสอง class นี้ implement function เดียวกันก็จะลดโอกาสการลืมแก้ไขไฟล์ใดไฟล์หนึ่งได้ (IUserInputProxy เป็นตัวอย่าง Interface และ Class FakeUserInput กับ RealInput ที่ implement IUserInputProxy ด้วยกันทั้งคู่)
2. เงื่อนไขการทดสอบที่คาดหวัง (Then) จากรูปด้านบนก็คือตำแหน่งของ x ต้องน้อยกว่าศูนย์ (Compare To Constant Value น้อยกว่า Constant คือ 0) หรือพูดอีกในที่ตัวยานอวกาศต้อง “ขยับออกจากที่เดิมเมื่อมีการใส่ Input เข้าไปเป็นเวลา 1 วินาทีไม่ว่าจะเป็น RealInput หรือ FakeInput ก็ตาม”
   
3. GameObject ต่างๆ ที่เกี่ยวข้องกับการ Test (Given) อันนี้ก็ตรงไปตรงมา คือ Object ตัวไหนมีผลกับตัวไหนบ้าง การทดสอบยิงจำเป็นต้องมีวัตถุอะไรบ้างในฉาก ใน Project ตัวอย่างนี้จะมีเพียงยาน Spaceship ที่เราใช้ควบคุมไปมาเท่านั้น

เมื่อวางองค์ประกอบครบ ถัดมาเรามาลองรันดูกันดีกว่า เปิดหน้าต่าง  Unity Test Tools -> Integration Test Runner ขึ้นมาจะได้ดังรูป

กด Run All เพื่อทดสอบ Test ก็จะพบว่า Test Fail เพราะเรายังไม่ได้แก้ไขให้ยานขยับเมื่อกดปุ่มซ้ายบนคีย์บอร์ดนั่นเอง ดังนั้นหน้าที่ของเราตอนนี้ก็ต้องแก้ไขให้ Test มันทำงานได้ถูกต้องด้วยการเปิดไฟล์ SpaceshipMotor.cs ขึ้นและแก้ไขตาม comment ในไฟล์นั้น (เขียนไว้ค่อนข้างดีอยู่แล้ว) หากแก้ได้ถูกต้องโดยขยับได้ทั้ง MoveHorizontally และ MoveVertically เมื่อ Run All Test อีกรอบจะพบว่า Test รันได้ถูกต้องหมดเรียบร้อย

นอกจากนี้หากเราไม่ต้องการใช้ Assertion Component เพราะไม่พบเงื่อนไขการทำงานสำเร็จที่เราต้องการ เราสามารถสร้างเงื่อนไข Integration Test ผ่านโดยไม่ต้องใช้ Assertion Component ก็ได้โดยจะต้อง Coding โดยใส่คำสั่ง “Integration.Pass()” เข้าไปเพื่อบอกว่ารัน Test ผ่านแล้ว เราสามารถใส่ในบริเวณจุดสิ้นสุดของ Code ที่ถ้าถูกรันแล้วจะถือว่า Test ผ่านได้เช่นกัน

หากสังเกตจะพบว่าเรามี Spaceship ใหม่ในแต่ละ Test แยกกันหมดเลย ตรงนี้เอาไว้เหมือนการ Reset ค่า Environment ต่างๆ ให้ทดสอบใหม่โดยเริ่มต้นที่ตำแหน่งนี้ๆ ทำให้เราสามารถแยก Test แต่ละ Test เป็นอิสระต่อกันโดยไม่ขึ้นกับลำดับก่อนหลังการ Test ได้ แต่หากมี Object ที่ต้องใช้ทุกๆ การ Test จริงๆ โดยไม่มีการเปลี่ยนแปลงอะไรเช่น Library กลางเราสามารถสร้าง Object นั้นไว้นอก Test Component ได้ครับ เพียงเท่านี้เราก็จะสามารถใช้ Object เดียวกันในทุกๆ Test ได้ (แต่ต้องระวังเรื่องการเปลี่ยนแปลงค่าที่ Object กลางตัวนี้แทนว่าจะไม่ทำให้เกิดปัญหาเวลา run test สลับลำดับกัน)

จากนี้ไปจะมี Scene ถัดๆ ไปเป็นแบบฝึกหัดให้ลองกัน สามารถลองไปแก้ไขเรื่อยๆ จนกว่าจะใช้การได้เป็นเกมสุดท้ายใน Scene “The Game” ได้เลย แลดูสนุกใช่ไหมครับ น่าจะช่วยให้เข้าใจการใช้งาน Assertion Component กับ Integration Test มากขึ้นนะครับ

1. เคยไหม สมมติมีคนเล่นเกมเราพร้อมกัน 1 หมื่นคน เรา upload เกมขึ้น Store ปรากฏว่าคนเปิดเกมไม่ได้ Crashed เลย หรือมี Bug ที่ใช้ประโยชน์จากเกมของเราได้ และกว่าเราจะรู้ตัวว่ามี Bug กว่าจะแก้เสร็จและ upload ขึ้น Store กว่าคนเล่นจะกด Download เกมเวอร์ชั่นแก้ Bug ไป รวมๆ แล้วผ่านไปกี่ชม. แล้ว? อ้อ สำหรับคนที่ไม่รู้ App Store ของ iOS ใช้เวลา Approve 7 วันนะครับบบบ เรารอได้ไหม?
2. แก้ Bug ระบบ A แต่ระบบ B เสือกพัง เห้ยยย เป็นไปได้ไงแว้ ไม่ได้ทดสอบระบบ B ก่อน up ขึ้น Store ซะด้วย
3. นาย A มาแก้ Code ของนาย B แล้วพัง อ้าวเห้ย จะแก้อันนี้ทำไมไม่บอกกันก่อนวะ ห้ามทำแบบนี้นะเว้ย ต้องทำแบบนี้ๆๆๆ เท่านั้น !@#@$#^%$#

โอเคเหตุการณ์ Basic ทั่วไปของวงการ Software Development ที่ไม่ได้เป็นเฉพาะวงการเกมก็คงจะเคยเจอเหตุการณ์แบบนี้บ่อยๆ จริงไหมครับ ปัญหานี้เราแก้ได้ด้วยการมีระบบ Automate Test ครับ หรือจะ Test Manual เอาก็ได้นะ แต่จะเสียเวลาและแรงงานโดยยังมีโอกาสเกิด Human Error อีกตะหาก

เข้าเรื่อง อาจจะมีคนสงสัยว่า Unity สามารถเขียน Test เกมของเราได้หรือไม่ คำตอบคือได้ครับ! แถมยังทดสอบการทดสอบพวกหน่วงเวลาจะเกิด Action ตามที่ต้องการได้หรือไม่ซึ่งมักเป็นองค์ประกอบหลักของเกมแทบทุกเกมได้เป็นอย่างดี

ทาง Unity ได้ออก library ของตัวเองให้ Download กันได้ฟรี ชื่อว่า Unity Test Tools ถ้าใครใช้ Unity 5.3 เป็นต้นไปจะฝังมากับตัว Unity อยู่แล้ว ไม่ต้องโหลดเพิ่มครับ (เฉพาะส่วนของ NUnit) แต่ถ้าใครยังจำเป็นต้องใช้ version เก่าอยู่ก็โหลดตาม link มาได้ ทำให้เราสามารถทดสอบเกมของเราได้ โดยการทดสอบจะแบ่งออกเป็นสามประเภทหลักๆ

1. NUnit หรือเทียบได้กับ Unit Test ธรรมดาทั่วๆ ไปของภาษาอื่นๆ เป็นการใช้ Assert ใน Code เพื่อทดสอบการทำงานเป็นราย class หรือ method โดยควรออกแบบให้ไม่ต้องเชื่อมต่อกับระบบด้านนอกเช่น database หรือ web server เพื่อทดสอบเฉพาะ logic การทำงานของ method นั้นจริงๆ และควร Test แค่อย่างเดียวต่อ 1 การทดสอบ (Unit แปลว่าหน่วย 1 หน่วยที่เล็กที่สุด ดังนั้นควรทดสอบแค่หน่วยเดียว อย่าทดสอบหลายๆ หน่วยในการทดสอบ 1 ครั้ง) สำหรับ NUnit นี้เราจะต้องทดสอบภายใน Folder ชื่อ Editor เท่านั้นเป็นข้อบังคับของ Unity โดย Unity จะติด Library NSubstitute ซึ่งเป็น Library สำหรับสร้างพวก Dummy Object, Stub, Test Spy, Mock อย่างง่ายๆ มาให้ในตัวโดยไม่ต้องหาโหลดเพิ่มอีก เพื่อเพิ่มความสะดวกในการทดสอบอย่างสูงสุดครับ
   
   
2. Assertion Component เป็นการทดสอบโดยไม่ต้องเขียน Code ทดสอบ คล้ายข้อ 1 แต่อาศัยการเปรียบเทียบและใส่ค่าผ่าน Inspector โดยตรงแทน อาจให้คนที่มีความรู้ Coding น้อยๆ ช่วยทำได้ ทำให้สะดวกมาก ไม่ต้องเป็น Programmer ทำเสมอไป โดยสามารถใส่แทรกไปกับระบบการทำงานปกติของเกมได้เลย เพราะเมื่อสั่ง Build แล้วตัว Unity จะตัด component ส่วนนี้ออกให้เองอัตโนมัติ สามารถตั้ง Event ได้ว่าจะทดสอบเมื่อไหร่ เช่นเมื่อ Object ตัวนี้ๆ โดน Destroy หรือเมื่อเกิดเหตุการณ์ใดๆ สามารถเปรียบเทียบค่าระหว่างวัตถุสองชิ้นก็ได้ จุดเด่นคือสามารถแทรกการทดสอบกับ Scene จริงและใช้ช่วยหา Bug ที่ค้นหาได้ยากได้ เวลาใช้กับ Option Error Pause
3. Integration Test เป็นการทดสอบโดยกำหนดสภาพแวดล้อมและสถานการณ์อย่างหนึ่งขึ้นมาสำหรับการ Test โดยเฉพาะ คิดซะว่า New Scene ขึ้นมา setup ค่าทุกอย่างใหม่หมดทุกครั้งต่อการทดสอบ 1 อย่าง แล้ว reset ค่าทุกอย่างก่อนจะทดสอบลำดับถัดไป เป็นการทดสอบความสัมพันธ์ระหว่าง GameObject หลายๆ ชื้นที่มีปฏิสัมพันธ์ต่อกันว่าดำเนินไปอย่างถูกต้องหรือไม่โดยเฉพาะ เช่นถ้าบอลแตะ Collider ภายในเวลาที่กำหนดให้ผ่าน Test นั้นซะ ถ้าแตะไม่ทันให้ไม่ผ่าน หรือหน้านี้จะต้องโหลดสำเร็จภายในกี่วินาที ซึ่งเราสามารถเขียน Code เสริมเพื่อสั่งว่าการทดสอบผ่านแล้วได้อีกด้วย ไม่จำเป็นต้อง set ผ่าน Inspector เพียงอย่างเดียว

รอติดตามตัวอย่างการใช้งานได้ในตอนต่อไปนะครับ

ปล. ข้อควรระวัง แม้จะมี Automate Test ก็อย่าละเลย Manual Test ไป คิดซะว่า Automate Test แค่ช่วยลดงานและ Human Error ของ Manual Test เท่านั้น มันยังคงมี Bug บางส่วนที่ Automate Test ไม่สามารถทำได้ หรือทำได้แต่ใช้แรงงานเยอะจนไม่คุ้มอยู่เหมือนกัน เช่นแก้ UI แล้ว UI เบี้ยวจากตำแหน่งที่ควรจะเป็น 10 pixel หรืออะไรทำนองนี้ ถ้าจะเขียนดักให้ครบเคสพวก UI เบี้ยวแถมมือถือยังมีหลากหลายขนาดหน้าจออีกก็อาจจะลำบากหน่อย ซึ่งขึ้นอยู่กับวิจารณาณของทีมว่าสมควรเขียนไหมอีกทีครับ

Link แนะนำ:

http://www.tallior.com/introduction-unity-test-tools/
อธิบายจุดประสงค์และประโยชน์อย่างละเอียดในการทดสอบทั้งสามแบบด้านบน

https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/test-tools
วิดีโอสาธิตการใช้งาน

http://blogs.unity3d.com/2014/07/28/unit-testing-at-the-speed-of-light-with-unity-test-tools/ (บทความ)
https://github.com/DmytroMindra/TestDoublesBlogpost (Code)
ตัวอย่างการใช้งาน Dummy Object, Stub, Test Spy, Mock และพื้นฐานการเขียน Test (สำหรับคนที่ไม่เคยเขียน Test มาก่อนเลยในชีวิตแนะนำให้อ่านก่อนเลยครับ)

https://bitbucket.org/Unity-Technologies/unitytesttools/wiki/Home
Manual การใช้งาน Tools ตัวนี้และ Source Code

https://github.com/DmytroMindra/GrowingGamesGuidedByTests
Code ตั้งต้นเป็นแบบฝึกหัดสนุกๆ สำหรับการเริ่มต้นหัดเขียน Test สำหรับเกม สำหรับใครที่นึกภาพไม่ออกว่าควรจัดโครงสร้าง Object สำหรับ Test ยังไงบ้างแนะนำให้โหลดไปเล่นได้ครับ

• ฝั่ง Programmer เขียน code มาแล้วส่งมาให้ Tester ปรากฏว่า Bug ตรึม Tester ก็โวยวายใส่ Programmer
• Tester รายงานว่ามี Bug อะไรบ้างกลับไปให้ Programmer แล้วปรากฏว่า Programmer แก้ bug ตัวใหม่เสร็จ Bug ตัวเก่ากลับปรากฏขึ้นมาซ้ำทั้งๆ ที่แก้ไปแล้ว
• เมื่อ Bug เกิดขึ้นหนึ่งครั้ง หาต้นตอของ Bug ยาก ไม่รู้เริ่มผิดตั้งแต่ตรงไหน ต้องมาพิมพ์ print ไล่ code ทีละส่วน
• “เครื่องผมไม่เห็น bug เลย ทำไมเครื่องคุณ bug ล่ะ Test ยังไงเนี่ย”
• “เมื่อวานยังไม่ Bug เลย ทำไมวันนี้มันพังตอน present ให้หัวหน้าดูได้(วะ)เนี่ย”
• เมื่อเกิดปัญหาเช่น performance หรือต้องมีการแก้ไข Code ส่วน Core หลักที่ใช้งานทุกๆ ที่ จะไม่สามารถมั่นใจได้เลยว่าแก้ไปแล้ว Code เก่าที่อื่นจะ Bug หรือไม่
• อื่นๆ อีกมากมาย

Test Driven Development (ต่อไปนี้ขอเรียก TDD) จะเข้ามาช่วยแก้ปัญหา หรือบรรเทาปัญหาเหล่านี้ลงได้ ซึ่งต้องมีการเขียน Unit Test (การทดสอบการทำงานของ Code ด้วย Code ทำให้สามารถสั่งรันแบบ automatic ได้) โดยมีหลักการดังนี้

1. บังคับเขียน Unit Test ก่อนลงมือ Code จริง โดยพูดง่ายๆ ว่า Test = Requirement โดย Programmer ต้องเป็นผู้ลงมือเอง คนเดียวกับคนที่เขียน Code นั่นแหละ
2. การจะเขียน Test ก่อนลงมือ Code ได้จำเป็นต้องรู้โครงสร้าง code มาก่อนแล้วคร่าวๆ โดยเฉพาะ Input และ Output ที่ต้องการ ส่งผลให้เกิดการวางแผนล่วงหน้าก่อนการเขียน Code
3. ถ้าเขียน Test ไม่ได้ หรือเขียน Test ยาก แสดงว่า Code ของคุณยังไม่สละสลวยพอต่อการ Test (คำกล่าวจากท่าน dean4j) หรือพูดง่ายๆ ว่า Code คุณห่วยนั่นเอง! ต้องแก้ที่ Code ไม่ใช่ที่ Test
4. การเขียน Test หลักๆ แล้วต้องมีมาก-น้อยแค่ไหนก็ขึ้นอยู่กับ Requirement ของลูกค้านั่นแหละ อย่าไปคิดแทนลูกค้า! เพราะเค้าอาจไม่ได้เห็นดีด้วยกับสิ่งที่เราเพิ่มเข้าไปเองทีหลัง
5. เมื่อเขียน Test เสร็จแล้วค่อยลงมือ Code ตามปกติ เมื่อเขียนเสร็จก็สั่งรัน Test ได้เลยว่าผิด-ถูกอย่างไร
6. เขียน Test เป็น Moduleๆ ก่อน และต้องเขียน Test ระหว่าง Module ที่มีการทำงานข้ามกันไปมาแยกกันด้วย เพราะเมื่อเกิดปัญหาจะได้รู้ว่า Bug ที่ Module ไหน หรือ Bug ตอนระหว่างจะคุยกันระหว่าง Module
7. จะมี CI เป็น server ที่ set environment ไว้สำหรับ test แล้วคอยดึง code ไป test ทุกๆ วันให้แบบอัตโนมัติ เพื่อทดสอบว่า Code ที่เขียนขึ้นใหม่ไม่กระทบของเก่า โดย Programmer ไม่จำเป็นต้องสั่งเองให้เหนื่อย

บางคนอาจสงสัยว่า ทำไมเขียน Test ทีหลังไม่ได้ ทำไมต้องเขียนก่อน หรือให้ Programmer คนอื่นเขียน test ตามที่หลังได้ไหม อันนี้จากประสบการณ์ส่วนตัวของผมเอง จะมีข้อเสียดังนี้

1. ถ้ามี Programmer คนอื่นมาเขียน Test ที่ตัวเองไม่ได้เป็นคน Code เอง ก็จะไม่อาจรู้ได้ว่า Code ส่วนไหนมีความสำคัญมากน้อยเพียงใด ที่สำคัญ Programmer ที่เป็นคน Code สามารถทิ้งขยะก้อนโตที่อ่านยากๆ ฝากเอาไว้อย่างไม่ใยดีได้อย่างง่ายดาย
2. ถ้าเป็น Code ตัวเอง แต่มาเขียน Test ทีหลัง ปัญหาที่เกิดก็ง่ายมากครับ “ก็มันเสร็จแล้วทำไมต้องเขียน Test อีก” พูดง่ายๆ ว่าขี้เกียจนั่นเองครับ 55 และถ้าต้องเขียน code ที่ไม่ได้ Design เผื่อสำหรับ Test แต่แรกนี่ก็เป็นความยากระดับมหาโหดเลยทีเดียว
3. บางครั้งการเขียน Code Programmer มักจะเผื่อโน่นนี่ที่ไม่ได้ใช้เอาไว้หลากหลายมาก เมื่อเขียน Test และต้องเขียนให้ได้ Coverage 100% ก็จะยิ่งขี้เกียจหนัก เช่นมี if สัก 10 ทีก็ไม่ไหวแล้ว ถ้าเขียน Test ก่อน ด้วยความขี้เกียจของ Programmer เองจะทำให้มี Test เฉพาะที่จำเป็นเอง และ Code ส่วนที่ไม่ค่อยจำเป็นจะไม่ถูกเขียนขึ้นตั้งแต่แรก ประมาณว่า “ถ้ามันไม่ได้ใช้แล้วเขียนเผื่อไว้ทำไมให้เหนื่อย”
4. หากเขียน Test ทีหลัง และ Code นั้นเป็น Code ที่ถูกสร้างขึ้นมานานแล้ว Programmer แม้จะเป็นคนเขียนเองก็ตาม จะเกิดอาการ “ลืม” ได้ง่ายมากๆ ครับ พอลืมก็ต้องมานั่งอ่านทำความเข้าใจ Code อีกรอบ เสียเวลามากๆ เลยทีเดียว

ทีนี้เรามาสรุปข้อดีว่าถ้ามี Unit Test ที่เขียนก่อนแล้วจะมีผลดีอย่างไรบ้าง

1. แม้ว่าจะต้องเสีย Overhead เรื่องเวลาไปก่อนกับการเขียน Test แต่เมื่อมีการกลับมาแก้ภายหลังแล้วจะสามารถแก้ได้อย่าง “มั่นใจว่าจะไม่ Bug” มากขึ้นมากเลยละครับ เพราะมีตัว Test ที่สั่ง run ปุ๊บก็รู้เลยว่ากระทบ Code เก่าหรือไม่ ทำให้ประหยัดเวลาในการ Test เรื่องเดิมๆ ของ Tester ไปได้มากด้วย ลดงาน Tester ได้เยอะครับ
2. สามารถระบุตำแหน่งที่เกิด Bug ขึ้นได้อย่างง่ายดายด้วย Test ที่เขียนไว้ การใช้เวลาในการหา Bug จะลดลงเป็นอย่างมาก
3. เมื่อเกิดการเปลี่ยน Environment การใช้งานขึ้น เช่นย้ายไปรันที่เครื่องอื่น แค่สั่งรัน Test ก็จะรู้ต้นตอของปัญหาได้ไม่ยากเลย ลดปัญหาเถียงกันไปเถียงกันมาว่าใครผิดระหว่าง Tester และ Programmer ลงได้มาก
4. ถ้ามีการแก้ไข code แม้เพียงเล็กน้อยในสถานการณ์กระชั้นชิดเช่นการ present ให้หัวหน้าดู แก้เสร็จก็รัน Test ได้เลย ก็จะลดความเสี่ยงหน้าแตกต่อหน้าหัวหน้าได้มาก
5. เมื่อมีการใช้งานไปสักระยะ และมีความจำเป็นต้องแก้ไข Code ส่วน Core หรือต้องมีการปรับปรุง performance ก็สามารถมั่นใจได้ว่าแก้ไขไปแล้ว performance ดีขึ้นโดยไม่ใช่ว่าทำให้ bug เพิ่มขึ้นตาม
6. Code ที่ออกมามีคุณภาพสูง อ่านง่าย เพราะไม่งั้นเขียน Test ไม่ได้ เมื่อมีการส่งต่อ Code ให้คนอื่นทำต่อก็จะเกิดปัญหาน้อยลง
7. เมื่อ Programmer คนอื่นต้องการศึกษาวิธีการใช้งาน module ใดๆ ว่าต้องส่งค่า Input อย่างไรเข้าไป และจะได้ Output อย่างไรออกมาก็สามารถดูจาก Test ที่เขียนไว้ได้เลย สามารถ Copy ตัวอย่าง Code จาก Test มาปรับแก้ได้ทันที ดีกว่าอ่าน Manual ตัวหนังสือเยอะๆ เสียอีก

สรุปว่าเมื่อ Programmer เขียน Test แล้ว Code ก็จะอ่านง่ายขึ้น Bug จะน้อยลง Tester จะงานน้อยลง Programmer แก้ Bug ได้เร็วขึ้น Tester ก็จะด่า Programmer น้อยลง ลดความขัดแย้งระหว่าง Programmer-Tester และ Programmer-Programmer(ที่ทำงานร่วมกัน) ลงได้มาก และองค์กรจะสงบสุข ยอดขายพุ่งกระฉูด และโลกก็จะสงบสุข สวัสดีครับ