Bashアプリケーションをテストする

以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高いbashで書かれたテスト用フレームワークを使いました。

既存ソリューションの概要

手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。

重要になるのは、どんな基準でしょうか？

  1. 依存関係：bassのテスト用フレームワークを選ぶときに、python、luaなどのシステムパッケージも一緒に引きずり込むのは嫌ですね。
  2. インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要でした。理想的な選択肢はパッケージマネージャで、許容できる選択肢はgit clone、wgetです。
  3. ドキュメンテーションとサポート：アプリケーションは複数の異なるUnixディストリビューションで実行できなければならないので、テストは、さまざまなプラットフォーム、シェル、それらの組み合わせを含めてどこででも、アップデートの速さに合わせて正常に働かなければならず、しかも、コミュニティやその他のユーザの経験から離れてのテストは望ましくありません。
  4. 何らかの形でのフィクスチャと、（少なくとも！）setup()関数とteardown()関数が利用できること。
  5. 新しいテストを記述するための妥当な構文：bashの世界では重要な必要条件です。
  6. 慣習的な結果：テストを行った回数、何が成功して何が成功しなかったか、（必須ではないが、望ましくは）何が起こったか。

assert.sh

最初に目にとまった選択肢はassert.hという小さなフレームワークでした。なかなか良いソリューションで、インストールと使い方が簡単です。最初のテストを記述するためには、test.shというファイルを作成する必要があります（下の例はドキュメンテーションから引用しました）。

  1. . assert.sh
  2.  
  3. # `echo test` is expected to write "test" on stdout
  4. assert "echo test" "test"
  5. # `seq 3` is expected to print "1", "2" and "3" on different lines
  6. assert "seq 3" "1\n2\n3"
  7. # exit code of `true` is expected to be 0
  8. assert_raises "true"
  9. # exit code of `false` is expected to be 1
  10. assert_raises "false" 1
  11. # end of test suite
  12. assert_end examples

ファイルを記述したら、それを実行できます。

  1. $ ./tests.sh
  2. all 4 examples tests passed in 0.014s.

その他には、次のような利点があります。

  • シンプルな構文と使い方
  • 優良なドキュメンテーションと使用例
  • 条件付きと条件無しのテストスキップが可能
  • フェイルファスト（fail-fast）や全実行（run-all）が可能
  • （フラグ-vを使えば）エラーの詳細を表示可能。初期設定では、どのテストが失敗しているか通知されません。

しかし、重大な欠点もいくつかあります。

  • この記事の執筆時点では、Githubに「ビルド失敗」という赤いアイコンがあり、恐怖を感じました。
  • このフレームワークは簡単な部類に入るように見えましたが、各テストのためにデータを準備して完了時に削除するためのsetup()とteardown()のメソッドが欠如しています。
  • ある1つのフォルダから全てのテストを実行させることはできません。

結論：基本的なshellスクリプト用のシンプルなテストを書く必要があるなら、お勧めできる良いツールです。複雑な仕事には向いていません。

shunit2

shunit2のインストールはassert.hほど簡単ではありません。私は適切なリポジトリを見つけることができませんでした。Google Codeにいくつか、Githubにも少数のプロジェクトがあり、3年から5年前にいろいろな段階で放置されています。さらに、svnリポジトリもいくつかあります。したがって、どのリリースが最新で、どうやってダウンロードするのかを知ることは不可能です。でも、それは大した不便ではありません。

テストはどのようなものでしょうか？　次の例は、ドキュメンテーションからの引用です。

  1. testAdding()
  2. {
  3.   result=`expr 1 + 2`
  4.   assertEquals \
  5.       "the result of '${result}' was wrong" \
  6.       3 "${result}"
  7. }

これを実行させます。

  1. /bin/bash math_test.sh testAdding  
  2. Ran 1 test.  
  3. OK

このフレームワークは、このクラスなりのいくつかの独自機能を誇ります。

  • コード内にテストスイートを作成可能です。この機能は、ある種のプラットフォームまたはシェルのためのテストがあるときには便利です。この場合、zsh_やdebian_などの自分専用の名前空間を使うことができます。
  • 各テストについて実行できるsetUp関数とteardown関数、テストセッションの最初と最後に実行できるoneTimeSetUpとoneTimeTearDownがあります。
  • さまざまなアサートを幅広く選択でき、${_ASSERT_EQUALS_}を使ってテストが失敗したラインの数を入力することが可能。ただし、ラインのナンバリングがサポートされているシェル（bash（>=3.0）、ksh、pdksh、zsh）でのみ有効です。
  • テストをスキップすることができます。

それでもなお、下記のような非常に不利な点がいくつかあったことで、結局は選択肢から消えました。

  • プロジェクトがほとんど放置されています。
  • 上記の点から、何をインストールすべきかの判断が困難。直近のリリースは2011年のようです。
  • 機能の数が過剰気味。例えば、等式の確認に、assertEqualsとassertSameの2つの方法が存在します。信じられません。
  • フォルダから全ファイルを実行することができません。

結論： 本格的なツール。十分柔軟にセットアップでき、プロジェクトに不可欠なパーツになり得ます。しかし、shunit2プロジェクトそのものが構造を欠いているのは怖いので、もう少し探してみることにしました。

roundup

最初にこのフレームワークに惹かれたのは、rubyのSinatraの作者が書いたものだったからです。また、誰もが知っているmochaに似たテスト構文も気に入りました。ファイル内でit_から始まる関数は全てテストとみなされ、デフォルトで実行されます。面白いことに、全テストがそれぞれ独自のサンドボックス内で走るので、余分なエラーを避けられるのです。下記は、ドキュメンテーションにある事例です。

  1. describe "roundup(5)"
  2. before() {
  3.     foo="bar"
  4. }
  5. after() {
  6.     rm -f foo.txt
  7. }
  8. it_runs_before() {
  9.     test "$foo" "=" "bar"
  10. }

出力の事例は紹介されていません。自分でインストールして確認しなければならず、実際それほど良いものではありません。しかし、プラスの面もあります。

  • 各テストがそれぞれのサンドボックス内で実行されるのは、非常に便利です。
  • 使い方が簡単です。
  • git cloneと./configure && make経由でインストール可能。加えてローカルディレクトリにインストールできるので、$PATHを編集するだけで済みます。

とはいえ、かなりの欠点もあります。

  • 全テストに対する共通関数のソースを作成できません（本当に正確に言えば、不正をすれば可能）。
  • フォルダから全ファイルを実行することができません。
  • ドキュメンテーションはTODOマークだらけ、ここ数年開発が進んでいません。
  • テストをスキップできません。

結論： 全くの平凡なツールで、良いとは言えずとも、それほど悪くもないといったところです。その機能はassert.shをより幅広くした感じです。どのような時に使えるでしょうか。assert.shを使ってみて、後はbefore()やafter()さえあれば、と思う場合には向いているかもしれません。

bats

言ってしまいましょう、最終的に私はこのフレームワークを選びました。気に入った点はたくさんあります。何より、優れたドキュメンテーションです。使用事例やセマンティックバージョン管理。そして、batsを使っているプロジェクトのリストを特に挙げたいと思います。

batsは、「内部の全てのコマンドがコード0を返すなら、テストは完了したとみなす（set –eがするように）」というアプローチを取っています。以下がbatsに書かれたテストの例です。

  1. #!/usr/bin/env bats
  2. @test "addition using bc" {
  3.   result="$(echo 2+2 | bc)"
  4.   [ "$result" -eq 4 ]
  5. }
  6. @test "addition using dc" {
  7.   result="$(echo 2 2+p | dc)"
  8.   [ "$result" -eq 4 ]
  9. }

そして出力は次のとおりです。

  1. $ bats addition.bats
  2.  ✓ addition using bc
  3.  ✓ addition using dc
  4. 2 tests, 0 failures

--tapフラグを使えば、Test Anything Protocolに対応するテキストでテスト情報を取得できます。おびただしい数のプログラムへのプラグインを、Jenkins、Redmine、SublimeTextなどで見つけられます。

独特のテスト構文以外にも、batsには興味深い特徴があります。

  • runコマンドで、まずコマンドを実行し、その結果とテキスト出力をテストできます。その際は、専用の変数、$statusと$outputを使います。
  • loadコマンドで、共通のコードベースをロードできます。
  • skipコマンドで、必要な時にテストをスキップできます。
  • setup()関数とteardown()関数で、環境を調整したり、後にクリーンアップするように設定したりすることができます。
  • 特定の変数が完全に揃っています。
  • フォルダ内で全テストを実行できます。
  • コミュニティが活発です。

batsの利点をたくさん挙げてきました。欠点については、私が指摘できるのは1つだけです。

  • batsは正当なbashからはほど遠いこと。テストは、異なるシバンを使って.bats拡張子を持つファイル内に書く必要があります。

結論： 欠点なしに近い高品質なツール。強く勧めます。

結果

このリサーチは、私の個人的なプロジェクト、git-secretのために質の良いテストを書く試みとして行いました。その主な目標は暗号化されたファイルをgitリポジトリに保存することです。チェックしてみてください。

sobolevn/git-secret
git-secret – :busts_in_silhouette: プライベートデータをgitリポジトリ内に格納するbashツールgithub.com

Previous Post