這個標題有語帶雙關的意味，是如何「寫好」程式？還是如何寫「好程式」？如果是問如何「寫好」程式，有很多人可能會下意識地說：很簡單啊，就是把程式碼打好，按下執行程式、沒有問題就「寫好」了啊！但是，「寫好」了就是「好程式」嗎？
2015/11/9
2015/10/23
修正 Android 上免 Root 備份 Line 不正常的問題
更新：如果要進行備份或還原的手機是 Android 6.0 可以參考這一篇文章。
幫人轉移 Android 上的 Line 到新手機真是一個讓人很不愉快的經驗，最主要的痛苦來源還是來自於聊天記錄的備份問題。如果是要備份自己的聊天記錄，基本上會很清楚和哪些人對話是重要的，只要挑選好重要程度高的聊天室，數量不致於太多。然後用 Line 內建的「備份聊天記錄」功能逐一備份，並且把檔案移到新手機就完事，想看以前的記錄再匯入就行了。
但是幫人備份就不太容易拿捏輕重，萬一一個不好，漏了，就會被人埋怨是不是專業程度不夠。更何況不是群組或一對一的聊天室，好像備了也沒有用，全部聊天記錄整包備份是最保險的做法。但，Line 不提供！很難想像一個這麼受歡迎的軟體，在這個手機更換頻繁的世代，備份功能竟然如此的陽春。更不可思議的是，聽說這家公司在台灣還沒有對話的窗口，權利受損是無從申訴的，大家居然還這麼熱情的支持，連行政首長都甘願成為活廣告。
完整備份有這麼難嗎？還是有什麼見不得人的考量？Line 不提供這樣的功能就算了，等一下會提到 Line 似乎還有意圖阻擋大家使用第三方備份的方案。真不懂！不過就是個備份，逐個聊天室備份都提供了，也有人做出完整備份的方案，為什麼不提供大家一個愉快的使用經驗？這麼不親民的軟體不知道有沒有人想要發起抵制的運動？我們本土也有很多自己的通訊軟體，應該要多多支持一下，而不是一直被韓國人壓著打！更何況這個軟體披著日皮，連韓國人自己都不支持。
如果覺得本土的通訊軟體都上不了檯面，聽說有一款戰鬥民族出資開發的通訊軟體，可靠、效率好、保密性高。還有八掛說這軟體的出資者有膽和戰鬥民族的政府作對還安然無事，這麼傳奇的軟體應該要推薦給嗡嗡嗡，不然我們首都的公事機密都給韓國人給看光光了！
理智斷線的胡說八道就先打住，回到正題。網路上找得到的備份資訊還不少，但因為備份要移轉的標的是新買的手機，需要 Root 的方法會讓人有保固無效上的疑慮，所以還是選擇了免 Root 的方法。免 Root 的方法中有一個是使用批次檔來執行，為了確保執行的過程中出現問題，還有機會可以調查一下執行了什麼內容、有沒有機會調整，所以選了這個。
由於是第一次做，為了怕失敗，還先手動逐一的把群組及一對一的聊天記錄給備份下來，一共幾十個。其間還因為舊手機的空間已經被耗得差不多了，聊天記錄又多是陳年加一堆勵志圖檔，所以只能備一個移一個，由此可想見這段過程的慘烈。不過，悲慘的事情才正要開頭。
執行了第一個「1.A手機備份資料.bat」步驟就失敗，沒有辦法從舊手機裡把 Line 備份出來，backup.ab 檔案大小只有 1K。網路上找到今年六月的教學文章明明說沒問題的，研究了一下批次檔的內容，備份是使用 adb 的 backup 來做的。難道是我使用的手機太舊，所以 adb 無法正確執行？
我試著用 adb 的指令去備分其他的 apk，居然可以備份！所以我的 adb 是正常的！？ 那為什麼 Line 不能備分？是 Line 的 apk 被下了什麼限制嗎？本來想放棄，打算直接把用內建備份功能產生的檔案複製到新手機後，再逐一還原回來好了。但想想，不對！新手機聊天室都沒有產生怎麼匯入？我是幫別人備份，這些又不是我的連絡人，要先逐一丟訊息給他們產生聊天室之後才能匯入。那我要跟他們說什麼？安安，還沒睡？還是要放著，並且教會手機的主人：「你有跟他對話之後，再點哪裡、哪裡，然後以前的記錄就回來了」。
天啊！這將會是一個多漫長的歷程，要等到還原齊了要多久？這期間可能要一直被騷擾、詢問那個還原要怎麼操作。不過在這之前大概就會先被抱怨怎麼這麼麻煩，你到底行不行啊！不是我不行，是 Line 的問題啊...如果有扺制運動，可以來一起支持一下嗎？只有大家都不用，才有可能擺脫這個惡夢。
沒辦法，只好認命地再回網路上扒看看有沒有能用的資訊，無意間看到有討論區說在 5.2.3 之前的版本還能用，現在舊手機用的是 5.6.0。好吧！抱著死馬當活馬醫的心態，先去專門提供舊版本 apk 的網站下載 5.2.3 版，再裝回舊手機試看看吧。
為了怕有閃失，所以在把 5.2.3 裝到舊手機之前，先把原本的 apk 給備份出來。要把 apk 從舊手機拉出來要先知道檔案的位置，所以先執行以下的指令：
假設路徑在：
/data/app/jp.naver.line.android-1.apk
接著執行以下的指令把檔案從手機拉到 PC 來：
最後使用以下的指令把下載到的 5.2.3 版本的 apk 安裝回舊手機：
jp.naver.line.android_5.2.3.apk 是下載到的 apk 檔名、參數 r 是要求覆蓋原本安裝的檔案並保留資料、參數 d 則是允許降版安裝，所以很重要，這個參數一定要下。
安裝完了之後，再執行一次備份，嘿嘿，果然可以備份了。這也就是為什麼一開頭說 Line 企圖阻擋第三方的備份方案，雖然我不知道這是有意還是無意的。因為我也試過要備份 Facebook 開發的某一支 apk，一樣也會有無法備份的問題。
後續就按著教學文章的程序，「2.B手機還原資料.bat」到新手機、「3.B手機免root清除重登.bat」。但在第三步之後，為了保險起見，沒有直接啟動 Line。我先使用和舊手機一樣的指令，先把舊手機原本安裝的版本再更新回新手機，然後才啟動 Line。
登入時就是照著教學文章裡的步驟，使用最先開始就設好的電子信箱連結登入、選擇 Facebook 認證、輸入換機密碼。等程式更新好，進入到聊天畫面，耶！所有的聊天記錄都在，連不是一對一的聊天室都有被保留下來。只不過有一些時間較久的圖檔、影片沒有辦法回復，其他的看起來跟舊手機沒什麼二樣。
在選擇認證時其實有個小狀況，我是依照教學文章中的建議使用 Facebook，不過之前有看到一則新聞有提到 Line 自己的副總都不贊成連結 Facebook，呼籲大家把 Facebook 移除。自己都不贊同的功能還提供？有用的不加，反倒加一些有問題的功能！所以後來增加了電話認證，想要移除 Facebook，結果程式竟然顯示出現錯誤，移不掉！這...叫人移掉結果程式又有問題，抵制的理由再加一。不知道當初如果選用電話認證是不是就不會有這樣的問題？聊天記錄是不是可以正常的回來？等下次有比較好欺負的受害者來請我備份時再來試試...
幫人轉移 Android 上的 Line 到新手機真是一個讓人很不愉快的經驗，最主要的痛苦來源還是來自於聊天記錄的備份問題。如果是要備份自己的聊天記錄，基本上會很清楚和哪些人對話是重要的，只要挑選好重要程度高的聊天室，數量不致於太多。然後用 Line 內建的「備份聊天記錄」功能逐一備份，並且把檔案移到新手機就完事，想看以前的記錄再匯入就行了。
但是幫人備份就不太容易拿捏輕重，萬一一個不好，漏了，就會被人埋怨是不是專業程度不夠。更何況不是群組或一對一的聊天室，好像備了也沒有用，全部聊天記錄整包備份是最保險的做法。但，Line 不提供！很難想像一個這麼受歡迎的軟體，在這個手機更換頻繁的世代，備份功能竟然如此的陽春。更不可思議的是，聽說這家公司在台灣還沒有對話的窗口，權利受損是無從申訴的，大家居然還這麼熱情的支持，連行政首長都甘願成為活廣告。
完整備份有這麼難嗎？還是有什麼見不得人的考量？Line 不提供這樣的功能就算了，等一下會提到 Line 似乎還有意圖阻擋大家使用第三方備份的方案。真不懂！不過就是個備份，逐個聊天室備份都提供了，也有人做出完整備份的方案，為什麼不提供大家一個愉快的使用經驗？這麼不親民的軟體不知道有沒有人想要發起抵制的運動？我們本土也有很多自己的通訊軟體，應該要多多支持一下，而不是一直被韓國人壓著打！更何況這個軟體披著日皮，連韓國人自己都不支持。
如果覺得本土的通訊軟體都上不了檯面，聽說有一款戰鬥民族出資開發的通訊軟體，可靠、效率好、保密性高。還有八掛說這軟體的出資者有膽和戰鬥民族的政府作對還安然無事，這麼傳奇的軟體應該要推薦給嗡嗡嗡，不然我們首都的公事機密都給韓國人給看光光了！
理智斷線的胡說八道就先打住，回到正題。網路上找得到的備份資訊還不少，但因為備份要移轉的標的是新買的手機，需要 Root 的方法會讓人有保固無效上的疑慮，所以還是選擇了免 Root 的方法。免 Root 的方法中有一個是使用批次檔來執行，為了確保執行的過程中出現問題，還有機會可以調查一下執行了什麼內容、有沒有機會調整，所以選了這個。
由於是第一次做，為了怕失敗，還先手動逐一的把群組及一對一的聊天記錄給備份下來，一共幾十個。其間還因為舊手機的空間已經被耗得差不多了，聊天記錄又多是陳年加一堆勵志圖檔，所以只能備一個移一個，由此可想見這段過程的慘烈。不過，悲慘的事情才正要開頭。
執行了第一個「1.A手機備份資料.bat」步驟就失敗，沒有辦法從舊手機裡把 Line 備份出來，backup.ab 檔案大小只有 1K。網路上找到今年六月的教學文章明明說沒問題的，研究了一下批次檔的內容，備份是使用 adb 的 backup 來做的。難道是我使用的手機太舊，所以 adb 無法正確執行？
我試著用 adb 的指令去備分其他的 apk，居然可以備份！所以我的 adb 是正常的！？ 那為什麼 Line 不能備分？是 Line 的 apk 被下了什麼限制嗎？本來想放棄，打算直接把用內建備份功能產生的檔案複製到新手機後，再逐一還原回來好了。但想想，不對！新手機聊天室都沒有產生怎麼匯入？我是幫別人備份，這些又不是我的連絡人，要先逐一丟訊息給他們產生聊天室之後才能匯入。那我要跟他們說什麼？安安，還沒睡？還是要放著，並且教會手機的主人：「你有跟他對話之後，再點哪裡、哪裡，然後以前的記錄就回來了」。
天啊！這將會是一個多漫長的歷程，要等到還原齊了要多久？這期間可能要一直被騷擾、詢問那個還原要怎麼操作。不過在這之前大概就會先被抱怨怎麼這麼麻煩，你到底行不行啊！不是我不行，是 Line 的問題啊...如果有扺制運動，可以來一起支持一下嗎？只有大家都不用，才有可能擺脫這個惡夢。
沒辦法，只好認命地再回網路上扒看看有沒有能用的資訊，無意間看到有討論區說在 5.2.3 之前的版本還能用，現在舊手機用的是 5.6.0。好吧！抱著死馬當活馬醫的心態，先去專門提供舊版本 apk 的網站下載 5.2.3 版，再裝回舊手機試看看吧。
為了怕有閃失，所以在把 5.2.3 裝到舊手機之前，先把原本的 apk 給備份出來。要把 apk 從舊手機拉出來要先知道檔案的位置，所以先執行以下的指令：
假設路徑在：
/data/app/jp.naver.line.android-1.apk
接著執行以下的指令把檔案從手機拉到 PC 來：
最後使用以下的指令把下載到的 5.2.3 版本的 apk 安裝回舊手機：
jp.naver.line.android_5.2.3.apk 是下載到的 apk 檔名、參數 r 是要求覆蓋原本安裝的檔案並保留資料、參數 d 則是允許降版安裝，所以很重要，這個參數一定要下。
安裝完了之後，再執行一次備份，嘿嘿，果然可以備份了。這也就是為什麼一開頭說 Line 企圖阻擋第三方的備份方案，雖然我不知道這是有意還是無意的。因為我也試過要備份 Facebook 開發的某一支 apk，一樣也會有無法備份的問題。
後續就按著教學文章的程序，「2.B手機還原資料.bat」到新手機、「3.B手機免root清除重登.bat」。但在第三步之後，為了保險起見，沒有直接啟動 Line。我先使用和舊手機一樣的指令，先把舊手機原本安裝的版本再更新回新手機，然後才啟動 Line。
登入時就是照著教學文章裡的步驟，使用最先開始就設好的電子信箱連結登入、選擇 Facebook 認證、輸入換機密碼。等程式更新好，進入到聊天畫面，耶！所有的聊天記錄都在，連不是一對一的聊天室都有被保留下來。只不過有一些時間較久的圖檔、影片沒有辦法回復，其他的看起來跟舊手機沒什麼二樣。
在選擇認證時其實有個小狀況，我是依照教學文章中的建議使用 Facebook，不過之前有看到一則新聞有提到 Line 自己的副總都不贊成連結 Facebook，呼籲大家把 Facebook 移除。自己都不贊同的功能還提供？有用的不加，反倒加一些有問題的功能！所以後來增加了電話認證，想要移除 Facebook，結果程式竟然顯示出現錯誤，移不掉！這...叫人移掉結果程式又有問題，抵制的理由再加一。不知道當初如果選用電話認證是不是就不會有這樣的問題？聊天記錄是不是可以正常的回來？等下次有比較好欺負的受害者來請我備份時再來試試...
2015/9/19
調整 Android Studio 編譯檢查規則
在 Android Studio 中進行程式碼的編輯時，會對程式碼進行即時的分析，並且在編輯窗格的右上方顯示分析的結果。檢查程序在進行中時，窗格右上方的角落會以一個眼睛的圖示來表達。如果程式碼通過所有檢查條件會顯示綠色的勾勾；程式碼有違反一項以上的警告規則顯示黃色的方塊；當程式碼有違反一項以上的錯誤規則顯示紅色的圓圈包著驚嘆號。
很多人在寫程式的時候都只關心編譯後能不能執行好進行測試，因為程式一旦有錯誤就會中斷編譯程序、阻擋工作的進行，要等到錯誤的程式碼被修正後才能繼績工作。而警告的訊息並不會阻擋工作的進行，就會變得無所謂、大多數的人都會選擇不予理會。
這並不是一個好的開發習慣，Android Studio 進行的程式碼分析就像健康檢查一樣，用來顯示程式碼的健康程度。當健康檢查的報告中有數值超出標準值，雖然沒有達到疾病的程度，但代表身體已經有一定的問題。如果繼續忽視不理，很有可能就會轉變成疾病，甚至危害生命。同樣的道理，當分析的結果出現警告的訊息代表程式的寫法有一定程度出錯的風險。所以一但有警告訊息出現，應該要和錯誤一樣認真地看待並謹慎地處理。
不過，有的時候特定的習慣性寫法或是團隊的 Coding Convetion 可能會和工具預設的檢查規則有衝突，但其實並不影響程式的執行結果。舉例來說，以下的程式碼是一般判斷布林值的慣用寫法：
但是這樣的寫法由於「!」的寬度不寬，和判斷布林值是 true 的程式碼差別沒有很大，很容易因為看漏而導致修改程式時誤判而發生改錯程式碼的情況。再者，我們的母語並不是英文，所以在命名變數時常常詞不達意，甚至在過去的工作經驗中遇到有人命名變數的語意與用途相反的情況，更大大地增加了這樣的情況出現的機率。
為了有效地提高防呆的機率，我都習慣性地使用以下的方式來撰寫判斷式：
雖然會多打好幾個字，但是卻可以換來表達意思明確的效果。閱讀程式碼的人容易判斷區塊中到底是要執行 true 還是 false 的邏輯，不會被變數的名稱誤導形成邏輯上的混亂。
但 Android Studio 預設的檢查規則在遇到以上的寫法卻會顯示以下的警告訊息：
當這樣的訊息與其他的警告混在一起就會造成在寫程式時的困擾，因為沒有辦法在第一時間就利用編輯窗格右上角的綠色勾勾，了解程式是否已經通過其他的檢查規則。當看到窗格的右上角呈現黃色的方塊，如果要確認還要將滑鼠游標移到有問題的位置，才能夠判斷是不是因為以上的程式碼寫法所產生的警告訊息，或是還有其它的問題待修正！
這樣的動作如果在寫程式時頻繁的重複，會讓工作的效率下降很多，而且也會因為久了出現怠惰的心態，進而忽略警告訊息造成程式出問題的風險增加。
所幸 Android Studio 的檢查規則是可以調整的，在 Settings 的對話視窗中選擇「Editor->Inspections」項目，就可開啟或關閉特定的檢查規則。以文章中的示範程式碼寫法為例，可以切換到「Java->Control flow issues->Pointless boolean expression」項目。如下圖所示取消勾選該項目，Android Studio 就不會再針對這項寫法進行檢查。
有更動過的選項會以藍色的字體顯示，同時所屬的逐級向上分類項目也會顯示藍色，以方便識別。
很多人在寫程式的時候都只關心編譯後能不能執行好進行測試，因為程式一旦有錯誤就會中斷編譯程序、阻擋工作的進行，要等到錯誤的程式碼被修正後才能繼績工作。而警告的訊息並不會阻擋工作的進行，就會變得無所謂、大多數的人都會選擇不予理會。
這並不是一個好的開發習慣，Android Studio 進行的程式碼分析就像健康檢查一樣，用來顯示程式碼的健康程度。當健康檢查的報告中有數值超出標準值，雖然沒有達到疾病的程度，但代表身體已經有一定的問題。如果繼續忽視不理，很有可能就會轉變成疾病，甚至危害生命。同樣的道理，當分析的結果出現警告的訊息代表程式的寫法有一定程度出錯的風險。所以一但有警告訊息出現，應該要和錯誤一樣認真地看待並謹慎地處理。
不過，有的時候特定的習慣性寫法或是團隊的 Coding Convetion 可能會和工具預設的檢查規則有衝突，但其實並不影響程式的執行結果。舉例來說，以下的程式碼是一般判斷布林值的慣用寫法：
但是這樣的寫法由於「!」的寬度不寬，和判斷布林值是 true 的程式碼差別沒有很大，很容易因為看漏而導致修改程式時誤判而發生改錯程式碼的情況。再者，我們的母語並不是英文，所以在命名變數時常常詞不達意，甚至在過去的工作經驗中遇到有人命名變數的語意與用途相反的情況，更大大地增加了這樣的情況出現的機率。
為了有效地提高防呆的機率，我都習慣性地使用以下的方式來撰寫判斷式：
雖然會多打好幾個字，但是卻可以換來表達意思明確的效果。閱讀程式碼的人容易判斷區塊中到底是要執行 true 還是 false 的邏輯，不會被變數的名稱誤導形成邏輯上的混亂。
但 Android Studio 預設的檢查規則在遇到以上的寫法卻會顯示以下的警告訊息：
flag == false can be simplified to !flag
Reports pointless or pointlessly complicated boolean expressions. Such expressions include anding with true, oring with false, equality comparison with a boolean literal, or negation of a boolean literal. Such expressions may be the result of automated refactorings not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.
Reports pointless or pointlessly complicated boolean expressions. Such expressions include anding with true, oring with false, equality comparison with a boolean literal, or negation of a boolean literal. Such expressions may be the result of automated refactorings not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.
當這樣的訊息與其他的警告混在一起就會造成在寫程式時的困擾，因為沒有辦法在第一時間就利用編輯窗格右上角的綠色勾勾，了解程式是否已經通過其他的檢查規則。當看到窗格的右上角呈現黃色的方塊，如果要確認還要將滑鼠游標移到有問題的位置，才能夠判斷是不是因為以上的程式碼寫法所產生的警告訊息，或是還有其它的問題待修正！
這樣的動作如果在寫程式時頻繁的重複，會讓工作的效率下降很多，而且也會因為久了出現怠惰的心態，進而忽略警告訊息造成程式出問題的風險增加。
所幸 Android Studio 的檢查規則是可以調整的，在 Settings 的對話視窗中選擇「Editor->Inspections」項目，就可開啟或關閉特定的檢查規則。以文章中的示範程式碼寫法為例，可以切換到「Java->Control flow issues->Pointless boolean expression」項目。如下圖所示取消勾選該項目，Android Studio 就不會再針對這項寫法進行檢查。
有更動過的選項會以藍色的字體顯示，同時所屬的逐級向上分類項目也會顯示藍色，以方便識別。
2015/9/4
如何在 Android Studio 中批次執行不同性質的測試程式
當所開發的系統中，測試程式被依性質做區分，例如：單元測試(Unit Testing)、整合測試(Integation Testing)。通常會讓整合測試交給後端的 CI 系統來執行，因為相較於單元測試，整合測試所需的執行條件較高、所耗的時間也相對地較長。否則隨著程式日漸龐大，很有可能會出現只是幾分鐘的程式修改，但等測試執行完成卻要花上數倍時間的情況。
而單元測試就會被程式撰寫人員執行，用來確認程式是否依設計的內容來完成，所以這個時候就會需要有一個簡易的方法可以用來觸發單元測試的執行。在 Android Studio 中可以設定 Configuration 以便用來觸發不同的執行內容，像是要執行測試可以選擇新增 JUnit 或 TestNG 設定來啟動測試。
以 JUnit 為例，如果要在一堆的測試程式檔中只執行特定的測試項目，最直接的方法就是把檔案用不同的目錄或是 Package 分隔，在設定 Configuration 時指定對應的目錄或是 Package，就可以在測試啟動後只執行其下的測試檔案內容。
只是有的時候專案的結構較為複雜，因為規劃的關係同性質的測試檔案沒有辦法都歸在同一個目錄或 Package 下，更進一步可能檔案在不同階層的目錄或 Package 間交錯。而 Android Studio 的 JUnit Configuration 同時只能指定一個目錄或 Package，就算是可以指定多個，要一個一個的設定不但麻煩還會有遺漏的問題。當開發還在進行、專案結構還持續有異動時，要維持設定的正確更是個挑戰。
這時如果測試檔案的名稱有一定的規則，例如：單元測試以 UT 做為檔名的結尾、整合測試以 IT 做為檔名的結尾，可以使用 JUnit Configuration 裡的另一個選擇 - Pattern。不過這個部份在官方文件中沒有找到比較明確的說明，只有簡略地提一下可以透過搜尋由清單中選出所需的檔案。
實際上可以如下圖所示，在 Pattern 右方文字框中輸入 Regular Expression 內容，像是要過濾以 UT 結尾的檔案可以輸入 ^(.*UT$).*$。啟動後會依設定的搜尋範圍來進行比對，挑出檔案名稱符合樣板的測試檔案，並執行所有符合條件的測試程式。
而單元測試就會被程式撰寫人員執行，用來確認程式是否依設計的內容來完成，所以這個時候就會需要有一個簡易的方法可以用來觸發單元測試的執行。在 Android Studio 中可以設定 Configuration 以便用來觸發不同的執行內容，像是要執行測試可以選擇新增 JUnit 或 TestNG 設定來啟動測試。
以 JUnit 為例，如果要在一堆的測試程式檔中只執行特定的測試項目，最直接的方法就是把檔案用不同的目錄或是 Package 分隔，在設定 Configuration 時指定對應的目錄或是 Package，就可以在測試啟動後只執行其下的測試檔案內容。
只是有的時候專案的結構較為複雜，因為規劃的關係同性質的測試檔案沒有辦法都歸在同一個目錄或 Package 下，更進一步可能檔案在不同階層的目錄或 Package 間交錯。而 Android Studio 的 JUnit Configuration 同時只能指定一個目錄或 Package，就算是可以指定多個，要一個一個的設定不但麻煩還會有遺漏的問題。當開發還在進行、專案結構還持續有異動時，要維持設定的正確更是個挑戰。
這時如果測試檔案的名稱有一定的規則，例如：單元測試以 UT 做為檔名的結尾、整合測試以 IT 做為檔名的結尾，可以使用 JUnit Configuration 裡的另一個選擇 - Pattern。不過這個部份在官方文件中沒有找到比較明確的說明，只有簡略地提一下可以透過搜尋由清單中選出所需的檔案。
實際上可以如下圖所示，在 Pattern 右方文字框中輸入 Regular Expression 內容，像是要過濾以 UT 結尾的檔案可以輸入 ^(.*UT$).*$。啟動後會依設定的搜尋範圍來進行比對，挑出檔案名稱符合樣板的測試檔案，並執行所有符合條件的測試程式。
2015/8/27
在 Spock 測試方法間共用程式碼
在進行測試程式開發時，經常會有執行或驗證的程序是在不同的測試案例間一直重覆，當然使用 Spock 時也不例外。根據 Spock 的官方文件提到，在 Spock 中可以使用 Helper Methods 來把要被共用的程式碼收納於其中，並且在不同的測試方法間呼叫。
以下為測試方法共用程式碼的範例：
而驗證的部份也可以使用相同的模式來實作，以下是根據官方文件所建立的程式碼：
在以上程式碼第 25 行的 Helper Method 中加入 assert 依據官方文件的說明是為了確保在測試結果輸出時，可以顯示是哪一行驗證結果不符合預期。而照實作的經驗，如果把 assert 移除，發生驗證失敗時不會顯示訊息，甚至顯示測試通過的結果。
這裡有個細節要注意的是 Helper Method 必須要明確的以 void 宣告無傳回值，否則 Spock 可能會依據 Helper Method 的內容解譯產生不符合預期的結果。另外有一個小差異是在 Android Studio 裡，如果使用 '&&' 的語法串起所有的驗證指令，沒有辦法像官方文件所示範的把 '&&' 放在程式碼的最開頭，必須要把 '&&' 放在程式碼的結尾後斷行，否則會顯示語法錯誤的訊息。
以下為測試方法共用程式碼的範例：
而驗證的部份也可以使用相同的模式來實作，以下是根據官方文件所建立的程式碼：
在以上程式碼第 25 行的 Helper Method 中加入 assert 依據官方文件的說明是為了確保在測試結果輸出時，可以顯示是哪一行驗證結果不符合預期。而照實作的經驗，如果把 assert 移除，發生驗證失敗時不會顯示訊息，甚至顯示測試通過的結果。
這裡有個細節要注意的是 Helper Method 必須要明確的以 void 宣告無傳回值，否則 Spock 可能會依據 Helper Method 的內容解譯產生不符合預期的結果。另外有一個小差異是在 Android Studio 裡，如果使用 '&&' 的語法串起所有的驗證指令，沒有辦法像官方文件所示範的把 '&&' 放在程式碼的最開頭，必須要把 '&&' 放在程式碼的結尾後斷行，否則會顯示語法錯誤的訊息。
2015/8/23
Android Studio dose not highlight task tags
A couple days ago, I upgraded Android Studio to 1.3.1 from 1.3 in OS X 10.10.4. After Android Studio was reopened by upgrade program, I found all the TODO and FIXME task tags were not highlighted. They looked just as normal comments and not listed in TODO Tool Window.
It really annoyed me when I can't identify these task tags at first sight in my code. I use task tags for my suspended work and they can remind me what I still not done. I really don't want to use 'Find' to confirm if I clear all the task tags, it's not smart.
So I opened Settings dialog and tried to find out what was going wrong. In the TODO page, I found cause. All the TODO patterns were cleared and made my custom filters turned into red.
I put these two default patterns as below back into list:
But I don't like this solution. I use FIXME and TODO to distinct different tasks. The tasks must be done before go live are tagged with FIXME. The rest of them are tagged with TODO. This solution means I can't switch the list between different priority tasks and focus on them.
To get better solution, I tried many combinations of patterns and filters in TODO page. There is a workaround after many times reopened of Android Studio. It is quit simple, just add a custom pattern into list and set filters what I did. I got the highlight and filter both.
It really annoyed me when I can't identify these task tags at first sight in my code. I use task tags for my suspended work and they can remind me what I still not done. I really don't want to use 'Find' to confirm if I clear all the task tags, it's not smart.
So I opened Settings dialog and tried to find out what was going wrong. In the TODO page, I found cause. All the TODO patterns were cleared and made my custom filters turned into red.
I put these two default patterns as below back into list:
- \btodo\b.*
- \bfixme\b.*
But I don't like this solution. I use FIXME and TODO to distinct different tasks. The tasks must be done before go live are tagged with FIXME. The rest of them are tagged with TODO. This solution means I can't switch the list between different priority tasks and focus on them.
To get better solution, I tried many combinations of patterns and filters in TODO page. There is a workaround after many times reopened of Android Studio. It is quit simple, just add a custom pattern into list and set filters what I did. I got the highlight and filter both.
2015/8/22
如何使用 Spock 測試 Static Method
使用 Spock 來開發測試程式除了在之前的文章中提到的：可輔助 BDD 的開發流程、與 JUnit 相容及內建 Data Driven 功能等特性之外，還有另外一項優點是內建了 Mock 的功能。Spock 所提供的 Mock 功能在使用上相當的簡潔，以下是一段範例的程式碼：
由以上的程式碼可以看到只要使用 Mock() 函式就可以對指定的對象進行 Mock 的程序，同時也提供二種彈性的宣告方式，一是把要 Mock 的對象傳入 Mock() 函式(第 3, 4 行)，另一個方式是使用 Mock() 函式來建立執行個體(第 5 行)。第二種 Java-like 的語法主要是希望在編輯程式碼時 IDE 可以提供較好的支援，執行時會以宣告的型別來判定要產生的 Mock 對象之 Instance。
Spock 所提供的 Mock 功能有另一個亮點是不僅能夠針對 Interface，同時也可以使用在一般的 Class 上。如此在進行系統設計時，就可以不用遷就「是否有辦法分開測試」這個問題而要使用大量的 IoC 在設計之中，以致形成了過度設計的情況。在 Mock Class 前，專案必須要引用 cglib-nodep 和 objenesis 這二個函式庫，所以在 build.gradle 的 dependencies 應該像以下所示範的內容：
根據官方文件的說明，如果要驗證目標 Class 與其週邊 Object 互動的過程是否符合像是循序圖所表達的設計內容，可以使用範例程式中所示範之內容。使用的語法規格是：[互動的次數] * [互動的標的]，1 * mockClass.start() 就是驗證 Processor.run 是否有呼叫 ConcreteClass.start()，而且整個 Processor.run 的執行過程中只呼叫一次。
從範例程式中還可以看到，Spock 所提供的 Mock 功能，除了可以用來驗證 Class 間互動過程，同時也具有 Stub 的能力。可以依據呼叫的內容來提供對應的動作，增加了測試程式的靈活性。像範例程式中的第 8 行，當有程式呼中 mockInterface2.getInfo() 時，就會固定傳回 "二號測試字串" 的內容。而在第 15, 16 行，是代表當 Processor.run 的執行過程中，有呼叫到這二個目標函式時所會取得的內容。
雖然 Spock 提供了許多優異的特性，不過，美中不足的地方是目前的版本沒有辦法 Mock 靜態函式。在網路上看了一些討論之後，PowerMock 似乎是一個可用來搭配 Spock 解決這個問題的框架。進一步了解發現 PowerMock 所提供的套件種類繁多，包含了與幾個主流的測試框架整合的功能。而如何在 Gradle 中設定對應的套件，可以讓 Spock 與 PowerMock 協同運作會是一個門檻。
基本上要在 Spock 中使用 PowerMock 來 Mock 靜態函式，會用到 JUnit、Mockito 和 PowerMock 這幾個框架，這使得在設定 build.gradle 內容時更加的棘手。而在測試程式中要把這四個框架整合起來，以便能夠達到 Mock 靜態函式的目的，也是很費心神的一件事。
目前網路上查到的資訊都是片斷的，所以在這裡把相關的資訊統整起來，做為日後研究的起點。以下是 build.gradle 的內容：
以上的套件應該要依照所屬框架更新的狀況來調整對應的版本編號。
在測試程式中，如果有一個以下待測的 Class：
測試程式應該像以下所示範的內容來進行靜態函式的測試：
由以上的程式碼可以看到只要使用 Mock() 函式就可以對指定的對象進行 Mock 的程序，同時也提供二種彈性的宣告方式，一是把要 Mock 的對象傳入 Mock() 函式(第 3, 4 行)，另一個方式是使用 Mock() 函式來建立執行個體(第 5 行)。第二種 Java-like 的語法主要是希望在編輯程式碼時 IDE 可以提供較好的支援，執行時會以宣告的型別來判定要產生的 Mock 對象之 Instance。
Spock 所提供的 Mock 功能有另一個亮點是不僅能夠針對 Interface，同時也可以使用在一般的 Class 上。如此在進行系統設計時，就可以不用遷就「是否有辦法分開測試」這個問題而要使用大量的 IoC 在設計之中，以致形成了過度設計的情況。在 Mock Class 前，專案必須要引用 cglib-nodep 和 objenesis 這二個函式庫，所以在 build.gradle 的 dependencies 應該像以下所示範的內容：
根據官方文件的說明，如果要驗證目標 Class 與其週邊 Object 互動的過程是否符合像是循序圖所表達的設計內容，可以使用範例程式中所示範之內容。使用的語法規格是：[互動的次數] * [互動的標的]，1 * mockClass.start() 就是驗證 Processor.run 是否有呼叫 ConcreteClass.start()，而且整個 Processor.run 的執行過程中只呼叫一次。
從範例程式中還可以看到，Spock 所提供的 Mock 功能，除了可以用來驗證 Class 間互動過程，同時也具有 Stub 的能力。可以依據呼叫的內容來提供對應的動作，增加了測試程式的靈活性。像範例程式中的第 8 行，當有程式呼中 mockInterface2.getInfo() 時，就會固定傳回 "二號測試字串" 的內容。而在第 15, 16 行，是代表當 Processor.run 的執行過程中，有呼叫到這二個目標函式時所會取得的內容。
雖然 Spock 提供了許多優異的特性，不過，美中不足的地方是目前的版本沒有辦法 Mock 靜態函式。在網路上看了一些討論之後，PowerMock 似乎是一個可用來搭配 Spock 解決這個問題的框架。進一步了解發現 PowerMock 所提供的套件種類繁多，包含了與幾個主流的測試框架整合的功能。而如何在 Gradle 中設定對應的套件，可以讓 Spock 與 PowerMock 協同運作會是一個門檻。
基本上要在 Spock 中使用 PowerMock 來 Mock 靜態函式，會用到 JUnit、Mockito 和 PowerMock 這幾個框架，這使得在設定 build.gradle 內容時更加的棘手。而在測試程式中要把這四個框架整合起來，以便能夠達到 Mock 靜態函式的目的，也是很費心神的一件事。
目前網路上查到的資訊都是片斷的，所以在這裡把相關的資訊統整起來，做為日後研究的起點。以下是 build.gradle 的內容：
以上的套件應該要依照所屬框架更新的狀況來調整對應的版本編號。
在測試程式中，如果有一個以下待測的 Class：
測試程式應該像以下所示範的內容來進行靜態函式的測試：