นั่งดูตัวอย่าง code ตัวอย่างของ Android Architecture Component
พบสิ่งที่น่าสนใจมากมาย
หนึ่งในนั้นคือ การจัดการไฟล์ build.gradle (Gradle)
หรือไฟล์ configuration ของระบบงานนั่นเอง
มาดูกันว่ามีอะไรที่น่าสนใจบ้าง

เริ่มด้วย deps คืออะไร version ของ library/dependency มันหายไปไหน ?

ชื่อ library มันดูแปลก ๆ ไม่เหมือนที่เคยเห็นมา
มาดูตัวอย่างกัน

เมื่อไล่ดู configuration พบว่า
มีการเขียนเพิ่มเติมในไฟล์ gradle เพิ่มดังนี้

วิธีการช่วยทำให้อ่าน library ได้ง่ายขึ้นกว่าเดิมนะ
แต่ก็เพิ่มความซับซ้อนขึ้น
โดยปกติที่พบมาก ๆ จะทำการประกาศ library และใส่ comment ไปดังนี้ !!

ลองคิดเพิ่มเติม ถ้าเรากำหนด library แบบนี้จะง่ายกว่าไหม ?

จากนั้นลองไปค้นหาข้อมูลเพิ่มเติม
ก็เจอบทความที่อธิบายเพิ่มเติมเรื่อง Experimenting with Gradle dependencies
ซึ่งตรงกับที่ต้องการ
โดยใช้งานความสามารถของ Dependency Handler ใน Gradle
แน่นอนว่า ความซับซ้อนเพิ่มขึ้น
แต่สิ่งที่ได้กลับมาคือ ใช้งานง่ายขึ้นมาก ๆ ที่สำคัญ อ่านง่ายสุด ๆ !!

ตัวอย่างการใช้งานดูเพิ่มเติมที่ github::up1:sample

ว่าด้วยเรื่องของ Code Coverage Report

โดยปกติแล้วนั้น Android project จะทำการสร้าง Code Coverage Report
ให้เฉพาะ UI Testing เท่านั้น
ส่วนพวก Unit Testing จะไม่จัดทำและจัดเก็บให้
ดังนั้นถ้าต้องการใช้งาน
ต้องทำการเปิดให้เก็บค่า code coverage ก่อนนะ
รวมทั้งต้องทำการสร้าง Gradle task ใหม่ชื่อว่า fullCoverageReport ขึ้นมา
เพื่อทำการรวมค่า code coverage จาก UI และ Unit testing นั่นเอง

ปล. ทำไมไม่ทำแบบ build-in มาให้เลยนะ

สิ่งที่น่าสนใจอีกสำหรับการทดสอบคือ ถ้าต้องการ share code ระหว่าง test และ androidTest

ให้ทำการ custom นิดหน่อย ดังนี้

สุดท้ายถ้าใครศึกษา Android Architecture จาก GoogleSample

จะเจอเรื่องของการแยกการทดสอบด้วย flavor
ทำให้การทดสอบง่ายขึ้น
แต่ก็มีความซับซ้อนและ code เยอะขึ้นด้วยเช่นกัน
เป็นอีกหนึ่งแนวคิดที่น่าสนใจ
ตัวอย่างจาก TODO app

น่าจะพอมีประโยชน์สำหรับ Android developer บ้างนะ