GitHub Actionsを使っていきたいのでまだテストをきちんと作っていない sentakuのテストを追加しました。
まだ取り敢えず、の状態ですがGitHub Actionsを使っていくスタートとして。
シェルスクリプトなのでbatsを使っています。
sentaku
対話的に入力項目の中から選択が出来るシェルスクリプト製のツール。
bats
シェルスクリプトのテストツールとして恐らく一番有名なツール。
GitHub Actions
まだベータ版ですが申し込むと順次使える様になります。
新しくなってYAML形式のファイルをレポジトリの.github/workflows/の中に入れておくと 条件に応じてActionsが実行されます。
今のところまだベータ版ということもありますが非常にさくさく動いてくれます。
GitHub純正の連携なので、push後の動作はTravis CIなどに比べても早いということのがあると思います。
設定
レポジトリに.github/workflows/というディレクトリを作りそこにActionを定義したYAMLファイルを置くと それに応じてGitHub側でActionを起こしてくれます。
今回は以下の様なファイルを用意:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
push
されたときにUbuntuの環境を用意して、レポジトリを取ってきてbats
をインストール、
必要なライブラリ(bats-assert, bats-support)も取ってきて(get_bats_libs.sh)
テストスクリプト
(function_check.bats)
を実行、といった感じです。
各部分の説明については 前回のポストを参照。
テストスクリプトは取り敢えず全部関数を並べて簡単に出来るものだけテストを入れただけです。
インタラクティブツールなのでちょっとどこまでテストできるかと言うのが難しい。
あと、ちょっと面倒だったのがsentakuの中ではtput
とかを利用してターミナルの幅(tput cols
)の情報を得たり
カーソルを移動させたりしているわけですが、
こういったテストではターミナルが定義されてないのでそこで
tput: No value for $TERM and no -T specified
といったエラーが出ます。
とりあえずこれを抑えるためには適当な定義として
export TERM=dumb
と、ダミーの端末
1
を与えことでtput cols
とかに関してはエラーを回避できます。
ただ、これでも完全には回避できなくて、
tput cnorm >/dev/tty 2>/dev/null || tput vs >/dev/tty 2>/dev/null
という一度隠したカーソルをもう一度表示するコマンドのところで
sentaku: line 285: /dev/tty: No such device or address
というエラーが出てしまいます。
ちょっとこの辺は面倒なのでとりあえずテストを飛ばしています。
pushするとこんな感じで結果が見れます:
まとめ
GitHub Actionsを使ったテストを作ってみました。
他のレポジトリでも今後はGitHub Actions中心で良いかな、という感じがします。
sentakuのテスト自身に関しては細かい部分のテストはまだしも、 インタラクテ思った以上に難しそう。。。