初探命令列測試工具 cram

cram 簡介

cram 是一個設計來適用於測試命令列的工具。包括下面特性

• 執行一個 .t extention file 來進行測試
• 測試結果使用 unified format[1] 呈現

我的心得是似乎是一個可以用於 function test or API test 的工具：測試產品整體的執行結果。[2] 另外就是近年來似乎使用 command pattern + factory pattern 的命令列實作似乎越來越常見[3]，或許是一個值得了解的測試方式。

[1] https://en.wikipedia.org/wiki/Diff_utility#Unified_format

[2] 請見下面的「mercurial 的測試設計思想」

[3] kubernetes, mercurial, MAAS, checkbox(這個不完全是，沒有前面三者這麼"API")

使用範例

安裝

pip install cram

取得 cram source code (我只是要拿裡面 cram 測試自己 source code 的 test file)

git clone git@github.com:brodie/cram.git

進到取得的 source code 中存放  test file 之處

cd <cram source root>/cram/tests

執行看看

cram usage.t

稍微改動一下 usage.t，比較一下前後輸入輸出結果，大概就會有些感覺了。包括：

• .t file 基本上由兩者構成：「要執行的命令」、「執行後的輸出」
• 由空白兩行的縮排來告知 cram 「這是要執行的命令與執行後的輸出」

已經有過的討論案例：mercurial 的測試設計思想

在研究 cram 的過程中，我發現了這個討論串[1][2]，大致上是說

• mercurial 的開發上，產品的測試佔極大部份（程式碼幾乎是產品本身行數的一半），unit test 只有一點點
• 上面這種測試的中心思想是「我只保證 API 行為始終一致，中間怎麼實作基本上你不要管我」。優點是向下相容容易、測試程式碼不需要跟著一直改動。
• 有人就建議那這樣可能適合使用 cram[3]

[1] https://www.selenic.com/blog/?p=663

[2] https://www.selenic.com/blog/?p=582

[3] 我不知道最後 mercurial 最後有沒有採取這個作法，有興趣可以追一下。cram 的開發好像也沈寂了一段時間了就是。（cram 在 github 上面的 README 中，有些 link 還是指到 bitbucket 上呢）

自己想用上的案例：SOLVCON 上面使用 cram

動機

在 2015 的計畫中（對滿一年了 XD），我們有考慮設計 mesh IO 的 API。目前 mesh 工具也是朝著 command + factory pattern 的方式實作。

可以預期的問題

• 有些行為本質是亂數，例如切  partition 的方式
• elapsed time 資訊不太可能每次一樣

所以至少第一步是要先挑出究竟哪些 mesh/block 行為並不會改變，再去實作。