ว่าง ๆ มาแกะ build.gradle ใน code ตัวอย่างของ Google Sample

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

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

ชื่อ library มันดูแปลก ๆ ไม่เหมือนที่เคยเห็นมา มาดูตัวอย่างกัน [gist id="b798e30da2eab03490e1488318295d13" file="1.txt"] เมื่อไล่ดู configuration พบว่า มีการเขียนเพิ่มเติมในไฟล์ gradle เพิ่มดังนี้ [gist id="b798e30da2eab03490e1488318295d13" file="2.txt"] วิธีการช่วยทำให้อ่าน library ได้ง่ายขึ้นกว่าเดิมนะ แต่ก็เพิ่มความซับซ้อนขึ้น โดยปกติที่พบมาก ๆ จะทำการประกาศ library และใส่ comment ไปดังนี้ !! [gist id="b798e30da2eab03490e1488318295d13" file="3.txt"]

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

[gist id="b798e30da2eab03490e1488318295d13" file="4.txt"] จากนั้นลองไปค้นหาข้อมูลเพิ่มเติม ก็เจอบทความที่อธิบายเพิ่มเติมเรื่อง Experimenting with Gradle dependencies ซึ่งตรงกับที่ต้องการ โดยใช้งานความสามารถของ Dependency Handler ใน Gradle แน่นอนว่า ความซับซ้อนเพิ่มขึ้น แต่สิ่งที่ได้กลับมาคือ ใช้งานง่ายขึ้นมาก ๆ ที่สำคัญ อ่านง่ายสุด ๆ !! [gist id="b798e30da2eab03490e1488318295d13" file="dependencies.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 มาให้เลยนะ [gist id="b798e30da2eab03490e1488318295d13" file="build_coverage.gradle"]

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

ให้ทำการ custom นิดหน่อย ดังนี้ [gist id="b798e30da2eab03490e1488318295d13" file="5.txt"]

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

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