Integration Test ใน Unity Test Tools by heha
Jan0
จาก Blog ที่แล้ว เรื่อง Unity Test Tools วันนี้เรามาลงรายละเอียดกันเรื่อง Assertion Component และ Integration Test Tools ก่อนอื่นแนะนำให้ Download Project นี้ไป และ Download Unity Test Tools version ล่าสุดไปดูครับ (แกะ zip แล้วติดตั้ง Unity Test Tools ลงไป) ประกอบตัวอย่างในนี้
Assertion Component อย่างที่บอกไว้ใน blog ที่แล้วคือเราสามารถทดสอบได้โดยไม่ต้องเขียนโปรแกรม สร้างไฟล์ C# ขี้นมาใหม่เลยด้วยซ้ำ มักใช้กับ Integration Test (โดยติ๊กช่อง Suceed on Assertion เอาไว้) ซึ่งการ Test 1 Test จะมีองค์ประกอบต่างๆ ดังนี้
โดยมีตัวอย่างการใช้งาน (Scene Level 1) ดังนี้
- FakeInput (When) เพื่อจำลองการใช้งานหรือเล่นเกมของผู้เล่น เช่น เปลี่ยนจาก Input จริงๆ ซึ่งเป็นการกดคีย์บอร์ดปุ่มลูกศรซ้ายค้าง มาเป็นการสั่งให้เซ็ตความเร็วยานอวกาศและเคลื่อนที่โดยอัตโนมัติด้วยทิศทางความเร็วอย่างไรโดยผ่าน Inspector โดยตรง ไม่ต้องรอ user สั่ง ซึ่งเราควรจะสร้าง Interface มาเป็นตัวกลางระหว่าง Class FakeInput และ Class RealInput ให้ทั้งสอง class นี้ implement function เดียวกันก็จะลดโอกาสการลืมแก้ไขไฟล์ใดไฟล์หนึ่งได้ (IUserInputProxy เป็นตัวอย่าง Interface และ Class FakeUserInput กับ RealInput ที่ implement IUserInputProxy ด้วยกันทั้งคู่)
- เงื่อนไขการทดสอบที่คาดหวัง (Then) จากรูปด้านบนก็คือตำแหน่งของ x ต้องน้อยกว่าศูนย์ (Compare To Constant Value น้อยกว่า Constant คือ 0) หรือพูดอีกในที่ตัวยานอวกาศต้อง “ขยับออกจากที่เดิมเมื่อมีการใส่ Input เข้าไปเป็นเวลา 1 วินาทีไม่ว่าจะเป็น RealInput หรือ FakeInput ก็ตาม”
- 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 มากขึ้นนะครับ
Unity Test Tools มาเขียน Test ให้กับเกมของเรากันเถอะ! by heha
Dec2
ท้าวความก่อนเล็กน้อยสำหรับคนที่ไม่เคยเขียน Test มาก่อน ถามว่าทำไมเราต้องมี Test เหรอ?
- เคยไหม สมมติมีคนเล่นเกมเราพร้อมกัน 1 หมื่นคน เรา upload เกมขึ้น Store ปรากฏว่าคนเปิดเกมไม่ได้ Crashed เลย หรือมี Bug ที่ใช้ประโยชน์จากเกมของเราได้ และกว่าเราจะรู้ตัวว่ามี Bug กว่าจะแก้เสร็จและ upload ขึ้น Store กว่าคนเล่นจะกด Download เกมเวอร์ชั่นแก้ Bug ไป รวมๆ แล้วผ่านไปกี่ชม. แล้ว? อ้อ สำหรับคนที่ไม่รู้ App Store ของ iOS ใช้เวลา Approve 7 วันนะครับบบบ เรารอได้ไหม?
- แก้ Bug ระบบ A แต่ระบบ B เสือกพัง เห้ยยย เป็นไปได้ไงแว้ ไม่ได้ทดสอบระบบ B ก่อน up ขึ้น Store ซะด้วย
- นาย 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 มาได้ ทำให้เราสามารถทดสอบเกมของเราได้ โดยการทดสอบจะแบ่งออกเป็นสามประเภทหลักๆ
- 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 อย่างง่ายๆ มาให้ในตัวโดยไม่ต้องหาโหลดเพิ่มอีก เพื่อเพิ่มความสะดวกในการทดสอบอย่างสูงสุดครับ
- Assertion Component เป็นการทดสอบโดยไม่ต้องเขียน Code ทดสอบ คล้ายข้อ 1 แต่อาศัยการเปรียบเทียบและใส่ค่าผ่าน Inspector โดยตรงแทน อาจให้คนที่มีความรู้ Coding น้อยๆ ช่วยทำได้ ทำให้สะดวกมาก ไม่ต้องเป็น Programmer ทำเสมอไป โดยสามารถใส่แทรกไปกับระบบการทำงานปกติของเกมได้เลย เพราะเมื่อสั่ง Build แล้วตัว Unity จะตัด component ส่วนนี้ออกให้เองอัตโนมัติ สามารถตั้ง Event ได้ว่าจะทดสอบเมื่อไหร่ เช่นเมื่อ Object ตัวนี้ๆ โดน Destroy หรือเมื่อเกิดเหตุการณ์ใดๆ สามารถเปรียบเทียบค่าระหว่างวัตถุสองชิ้นก็ได้ จุดเด่นคือสามารถแทรกการทดสอบกับ Scene จริงและใช้ช่วยหา Bug ที่ค้นหาได้ยากได้ เวลาใช้กับ Option Error Pause
- 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 ยังไงบ้างแนะนำให้โหลดไปเล่นได้ครับ
Test Driven Development (TDD) by heha
Mar2
ผมไปฟังพี่ @roofimon ในวัน Bug Day มา เลยเอามาแชร์ต่อ เนื่องจากปัญหาการ Develop งานแบบเก่าอาจเกิดปัญหาดังต่อไปนี้
- ฝั่ง 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 ได้) โดยมีหลักการดังนี้
Who are we?
