สังเกตการสอน Automated Testing for Android Application by Somkiat P.

ชั้นเรียนนี้จัดขึ้น วันที่ 21–22 มกราคม 2560 ณ Punspace Tha Phae Gate เชียงใหม่
เรียกได้ว่าเป็นครั้งแรกที่ได้นั่งสังเกต somkiat.cc อย่างจริงจัง เอ๊ะ! แล้วที่ผ่านๆมาไม่ได้จริงจังเหรอ เอาน่าๆ แต่รอบนี้สังเกตเยอะขึ้นก็แล้วกัน ^_^

สิ่งที่พี่ปุ๋ยเปิดประเด็น คือ ทำไมต้องทำ Test? แล้วบอกผู้เข้าร่วมชั้นเรียนว่าหลังจบชั้นเรียนนี้เราจะทำ App ที่เป็น Testable Application และ มี Code coverage testing 100% ซึ่งอาจจะเป็นครั้งแรกและครั้งสุดท้ายที่เขียนก็ได้ นั่นไงล่ะ? ทางพี่เขาล่ะ

สิ่งใหม่ที่ได้เพิ่ม

เปิดกะลาและเพิ่มมุมมองการทำ Automated testing สำหรับ Android 
การทดสอบสำหรับ Android มีสองแบบนะ คือ แบบใช้ Emulator และ ไม่ใช้ Emulator

“ลงมือทำซะถ้ายังไม่ได้ทำจะได้รู้ว่าอะไรควรทำหรือไม่ควรทำ”

การใช้ jacocoTestReport ในการ Run unit test with coverage มันแหล่มแมวมากเลย นี่แหละอยากได้ report ที่ coverage 100% มันเริ่มจากตรงนี้
“UI test, Unit test แยกส่วนกันแต่เอามารวมกันเพื่อมองภาพรวม”

พี่ปุ๋ยสอนเริ่มจากชั้นล่างสุด Unit Test ในส่วนของโค้ด 
แล้วพาทำ UI Test โดยทดสอบที่ Activity ของ Android app เพื่อทดสอบ Flow หลักๆเท่านั้น โดยให้เหตุผลว่าตรงนี้ใช้เวลานานในการ run แต่ละรอบ

เมื่อทำ Unit Test และทำ UI Test แล้วก็พาทำส่วน API Test ตรงนี้ก็น่าสนใจ เริ่มมีการนำ SOLID และ Test Doubles มาปรับใช้ เป็นที่มาของคำว่า “อันนี้เข้าสู่วิชาการแล้วนะครับ” :)

สิ่งที่สังเกตได้ชัดคือทุกครั้งที่ Test ผ่าน จะมีการปรับปรุง Production Code ให้สวยงามอยู่เสมอ

TDD เริ่มต้นที่ให้พังก่อน แล้วทำให้มันผ่าน เมื่อผ่านแล้วก็ทำให้สวยงาม

Test Doubles
Dummy, Stub, Spy, Mocking, Fake

การใช้ Dexcount เพื่อตรวจสอบ size ของ library และไฟล์ต่างๆ ที่อยู่ใน App อันนี้ก็เด็ด เพราะจะได้รู้ว่าเราลดอะไรตรงไหนได้บ้าง?

https://github.com/KeepSafe/dexcount-gradle-plugin/blob/master/web/example.png

Coverage ไม่ได้บอกคุณภาพของ Test แต่เอาไว้บอกว่าเราเขียน Test ได้ครอบคลุมโค้ดหรือไม่?​ และบอกว่าเรายังขาดอะไร?


สิ่งที่ได้เพิ่มเติมจากเดิมที่มีอยู่แล้ว

ส่วนใหญ่จะได้แนวทางในการอธิบายและตัวอย่างเพิ่มเติม

“Unit Test ต้องเขียนอย่างต่ำ 5 เท่าของ Production code”

Good unit testing คือ
Fast เร็ว
Isolate แยกออกจากกันได้ชัดเจน
Repeatable สามารถรันซ้ำได้เรื่อยๆ
Self-verifying ตรวจสอบตัวเองได้
Timely

Test state ได้คำอธิบายเพิ่มเติม
//Arrange: การเริ่มต้น, การเตรียม
//Action: เรียกฟังก์ชั่นอะไร?, ทดสอบอะไร?
//Assert: ตรวจสอบผมว่าตรงตามความคาดหวังหรือไม่?

SOLID ได้คำอธิบายเพิ่มเติม พี่ปุ๋ยอธิบายได้ดีมากครับตรงนี้
SRP: แยกการทำงานออกเป็นส่วนๆ แต่ละหน้าที่
OCP: อนุญาตให้เพิ่มแต่ไม่อนุญาตให้แก้ไข (ลดผลกระทบของเดิม)
L: ข้ามไปๆ พี่เขาบอก
I: ข้ามไปๆ เหมือนกัน ช่างมันเถอะ
DIP: Dependency inversion principle เมื่อโค้ดที่เราเขียนผูกกันอยู่อย่างเหนียวแน่นก็แยกมันออกจากกันโดยผูกแบบหลวมๆ อาจจะใช้เทคนิค Injection เข้าไป
*จุดนี้หมายเหตุตัวโตๆไว้เลยว่า principle เอาไว้เกาะเป็นแนวทางอย่าไปยึดติด อันนี้ผมพูดเองนะ ฮ่าๆๆ

MVC พี่ปุ๋ยอธิบายเพิ่มให้เข้าใจง่ายขึ้น ถามว่าทำไมต้องเข้าใจเรื่องเหล่านี้ พี่เขามีคำตอบ “เราไม่เข้าใจพื้นฐาน ก็เลยทำให้เราไม่กล้าที่จะแก้ไขโค้ด”

“Advance ของเราคือพื้นฐานที่แน่น”

Continuous Integration คือ
1. วินัย, นิสัย ของคน
2. ค่อยๆสร้าง ค่อยๆทำ ค่อยๆโต โดยมี Test คุม
3. Fast feedback ผลตอบรับที่รวดเร็ว


ผมรวบรวมจากมุมมองของผมไว้เท่านี้ก่อนครับ จริงๆในชั้นเรียนแต่ละหัวข้อมีรายละเอียดอีกหลายๆอย่างที่ต้องฝึกฝนและเรียนรู้เพิ่มเติมอีกเยอะครับ โชคดีครับทุกท่าน

​Software สร้างไม่ยากแต่ทำให้มันดีอ่ะยาก