python decorator 也可以吃參數

看了草稿累積的狀況感覺... 來寫一點簡單的筆記好了。

最近碰了一點 python 的 decorator，透過 wrapper 的方式幫你處理一些 function 重複的部分，相對簡明而好懂。
但如果我需要多種 decorator 但只有些微的不同呢？
可能會考慮直接寫多個來實現， dec1, dec2, ... 然後再用 function 的方式去包裝，考慮了 http://stackoverflow.com/questions/10176226/how-to-pass-extra-arguments-to-python-decorator 裡面說的，也可以透過傳一個參數的方式去實現。

python 並非原生支援這種語法，所以寫起來有點難讀，不過使用的時候會比較簡潔。

另外一個在寫 decorator 遇到的事, 就是要注意進入 function wrapper 的時候，原來要傳入的 arguments 並不存在 wrapper 的 scope 。所以只能多包東西進去，不能調整傳進來的東西。

軟體測試這回事

做了幾年的軟體測試, 覺得這行飯其實還滿微妙的.

有些人叫測試工程師, 或者 QA (Quality Assurance 品管?) QC (Quality Control), SQA, Tester, blabla.... 這個 domain 對台灣人比較陌生, 最酷的是你在學校很難學到.
一般測試可能會遭遇到以下工作:

• Manual Test, 使用開發完的產品. 包括照表操課的 (有準備 test plan), 或者隨便亂試的. 這類的工作價值有一部分是使用產品本身就是模擬使用者 (客戶) 去操作產品, 相對於其他測試會更能貼近用戶會遇到的問題. 由於正職的測試人員對產品會有一定的熟悉 (也應該熟悉啦), 這件事會讓測試用戶體驗上有負面的影響, 所以也常有公司單獨作這一塊的測試, 有點像是市場調查.
• Test Planning (Design?) , 泛指 test case creation, test plan creation, ... 跟產品相關的. 這邊的工作常與上面的工作重疊.  也有些公司把這邊的工作特化出來. 或者產品根本就是有白紙黑字的規格, 這邊的工作負荷相對少. 軟體測試因為產品改變的速度極快 (一天變好幾版也有可能), 規格改變導致測試項目與預期結果也急遽改變, 擔任這個角色的工作內容比較吃重.
• Test Reporting, 根據測試結果產生測試報告. 這邊提到的測試報告是一個彙整, 根據所有測試報告產生列表或者圖像的結果, 以提供決策人員客觀的品質評估. 有些公司是 Developer 作這件事; 也有些地方是 Lead, Manager 在做的.
• Test Automation, 測試自動化. 有鑑於人作的永遠不會比程式快, 很多公司在考慮流程優化的時候會想到這件事. 如果讓我來說, 最好的自動測試也許就是作一個產品專門使用你的產品, 但實務上相當不切實際.  試著考慮一個產品, 可能的架構是, 他使用了許多 Library, 如下圖的 OS/Driver/Platform 這塊. 程式本身提供了一些 Interface 來完成流程, 或者與使用者互動.  然後跟使用者互動時的圖形界面. 理論上 presentation 這一層之所以要切開就是為了讓 UI 可以頻繁的更動. 以寫一份自動測試的成本/ 效益而言, 過多對於呈現面的自動化無疑自討苦吃. 市面上有許多產品試著解決這樣的問題, 像是 selenium. 相較之下, 在 API 層作自動化, 可以保證作低限度的正確性. 而相較之下不易改變的 API 行為, 也會保證測試本身有較高的性價比. 
• Write Test Tool, 輔助測試用工具. 這跟測試自動化有相關但我把他切成兩個部份, 因為目標不完全一致. 通常是幫助測試者完成冗長而不易完成的準備工作, 或者是使用一般狀況下無法碰觸到的情境 (高記憶體用量等等). 有些公司會有專屬的人作這些開發, 包括測試自動化; 但如果 QA 能負擔這些工作, 便能減少許多溝通造成的成本.
• Test Process, 測試流程規劃, 一般來說是 Manager 以上的角色在做的工作, 如果你作的夠久也可能碰的到. 內容像是, 定義開發流程之中的測試工作.

測試所帶來的價值

• 提供使用者經驗
• 風險管理
• 幫助釐清問題

前面兩個項目前面提過了, 我想談一下幫助釐清問題這件事. 作為一個測試人員, 除了發現問題以外, 很多的時間會花在重現問題, 而這是釐清問題的一個重要關鍵. 測試工程師不能只是對問題束手無策. 常用的作法是在 test case 中列舉, 經由交叉比對縮小問題點. 發現 root cause 這個工作如果在測試這邊就有足夠的資訊, 當問題交到開發工程師手上便會減少處理時花費的時間.

自動化在這個地方就扮演一個極其重要的角色.  如果 test case 設計時考慮到平行處理與容易程式化, 便能大幅縮短執行一個完整測試所需時間. 而兩個完整測試的間隔時間若縮短, 就可以縮小回歸 (regression) 問題所需翻查的 code/commit 數. 當發現問題與研究 root cause 的時間縮短, 可以想見的是品質將隨之提昇, 並且需要的開發時間也縮短了, 兩全其美?

測試是很重要的工作, 最重要的是不要把他作小了.

用 Mockito 的 injectMocks

官方網站上面沒找到, google 一下看到這篇 http://gladkowski.blogspot.tw/2011/06/mocking-objects-and-injecting.html

常常會遇到待測目標是用 @Resource, 或者其他方法拿到的, 測試的時候一般會想要排除這些依賴項目而嘗試寫假物件來提供更一致的行為; 這邊是要提用 Mockito 時候應該怎麼做.

首先必須 import 以下項目:

import org.mockito.Mock;

import org.mockito.InjectMocks;

import org.mockito.runners.MockitoJUnitRunner;
import org.junit.runner.RunWith;




在你的test class 宣告前面放上

@RunWith(MockitoJUnitRunner.class)

假設欲測的 class 叫做 target, 需要 inject 的 resource 叫做 dependent; 那麼在 class 的 scope, 可以宣告

@Mock

private Dependent dependent;

@InjectMocks

Target target = new Target();

之後你就可以跟原本一樣使用 dependent 來達成測試的需求了, 例如

when(dependent.func(anyString()).thenReturn("Hello");

        assertEquals("Hello", target.getStringFromDependentFunc());

Resize(Shrink) image size

大部份 resize VM image的文章都是講怎麼 expand, 讓既有的VM繼續長大; 這次我的需求是要從一個VM刪除掉多餘的資料以作出base image.

install SVN in OSX

因為新公司使用subversion 做 revision control, 很自然地找到 eclipse 的 subversion plug-in.  結果狀況還是東缺西缺的.
參考網路搜尋到的文章, 從eclipse -> help -> install new software, 找svn然後裝起來.
看起來版本有問題, 抓到的東西跟 repository上面的差很多....
上了subclipse的官網去撈, 確定版本之後抓下來, 準備要撈source的時候跳了一個 javahl not found的error..... google了一下, 有人說用macport裝 subversion就可了, 於是去找了brew上面的解法, 實驗之後仍然出現了java hl 的問題, 不過 ignore 之後 code好像抓下來了..... 來確認一下....