BATSを使用したBashのテスト

Bashスクリプトとライブラリの大部分は、実行時に関数や実行可能ファイルを実行します。多くの場合、終了ステータスまたは出力（ stdout ）に基づいて特定の方法で動作するようにプログラムされています。 、 stderr ）これらの関数または実行可能ファイル。これらのスクリプトを適切にテストするには、特定のテスト中に特定の方法で動作するように設計されたこれらのコマンドの偽のバージョンを作成する必要があります。これは「スタブ」と呼ばれるプロセスです。また、テスト対象のプログラムをスパイして、特定のコマンドを呼び出すことを確認したり、特定の引数を使用して特定のコマンドを呼び出すことも必要になる場合があります。これは「モッキング」と呼ばれるプロセスです。詳細については、RubyRSpecでのモックとスタブに関するこのすばらしい議論をチェックしてください。これはすべてのテストシステムに適用されます。

Bashシェルは、BATSテストスクリプトでモックとスタブを実行するために使用できるトリックを提供します。すべてBashのエクスポートを使用する必要があります -fを使用したコマンド 元の関数または実行可能ファイルをオーバーライドする関数をエクスポートするためのフラグ。これは、テストされたプログラムを実行する前に実行する必要があります。これは、猫をオーバーライドする簡単な例です。 実行可能ファイル：

function cat() { echo "THIS WOULD CAT ${*}" }

export -f cat

このメソッドは、同じ方法で関数をオーバーライドします。テストするスクリプトまたはライブラリ内の関数をテストでオーバーライドする必要がある場合は、関数をスタブまたはモックする前に、テストしたスクリプトまたはライブラリを入手することが重要です。それ以外の場合、スタブ/モックは、スクリプトのソース時に実際の関数に置き換えられます。また、テストするコマンドを実行する前に、必ずスタブ/モックを作成してください。これがbuild.batsの例です それはレイズを嘲笑します build.shで説明されている関数 ログイン機能によって特定のエラーメッセージが表示されるようにするには：

@test ".login raises on oc error" {

  source ${profile_script}

  function raise() { echo "${1} raised"; }

  export -f raise

  run login

  assert_failure

  assert_output -p "Could not login raised"

}

export なので、通常、テスト後にスタブ/モック関数の設定を解除する必要はありません。 exec中の現在のサブプロセスにのみ影響します 現在の@test ブロック。ただし、コマンドをモック/スタブすることは可能です（例： cat 、 sed 、など）BATSが主張する *関数は内部で使用します。これらのモック/スタブ関数は未設定である必要があります これらのassertコマンドが実行される前に、または正しく機能しません。これがbuild.batsの例です そのモックはsed 、 build_deployableを実行します 機能し、 sedの設定を解除します アサーションを実行する前：

@test ".build_deployable prints information, runs docker build on a modified Dockerfile.production and publish_image when its not a dry_run" {

  local expected_dockerfile='Dockerfile.production'

  local application='application'

  local environment='environment'

  local expected_original_base_image="${application}"

  local expected_candidate_image="${application}-candidate:${environment}"

  local expected_deployable_image="${application}:${environment}"

  source ${profile_script}

  mock_docker build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t "${expected_deployable_image}" -

  function publish_image() { echo "publish_image ${*}"; }

  export -f publish_image

  function sed() {

    echo "sed ${*}" >&2;

    echo "FROM application-candidate:environment";

  }

  export -f sed

  run build_deployable "${application}" "${environment}"

  assert_success

  unset sed

  assert_output --regexp "sed.*${expected_dockerfile}"

  assert_output -p "Building ${expected_original_base_image} deployable ${expected_deployable_image} FROM ${expected_candidate_image}"

  assert_output -p "FROM ${expected_candidate_image} piped"

  assert_output -p "build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t ${expected_deployable_image} -"

  assert_output -p "publish_image ${expected_deployable_image}"

}

時々同じコマンド、例えばfooは、テストされている同じ関数内で、異なる引数を使用して複数回呼び出されます。これらの状況では、一連の関数を作成する必要があります。

• mock_foo：期待される引数を入力として受け取り、それらをTMPファイルに保持します
• foo：コマンドのモックバージョン。予想される引数の永続化されたリストを使用して各呼び出しを処理します。これは、export-fを使用してエクスポートする必要があります。
• cleanup_foo：ティアダウン機能で使用するためにTMPファイルを削除します。これは、削除する前に@testブロックが成功したことを確認するためにテストできます。

この機能はさまざまなテストで再利用されることが多いため、他のライブラリと同じようにロードできるヘルパーライブラリを作成することは理にかなっています。

良い例はdocker_mock.bashです 。 build.batsに読み込まれます Docker実行可能ファイルを呼び出す関数をテストするテストブロックで使用されます。 docker_mockを使用した一般的なテストブロック 次のようになります：

@test ".publish_image fails if docker push fails" {

  setup_publish

  local expected_image="image"

  local expected_publishable_image="${CI_REGISTRY_IMAGE}/${expected_image}"

  source ${profile_script}

  mock_docker tag "${expected_image}" "${expected_publishable_image}"

  mock_docker push "${expected_publishable_image}" and_fail

  run publish_image "${expected_image}"

  assert_failure

  assert_output -p "tagging ${expected_image} as ${expected_publishable_image}"

  assert_output -p "tag ${expected_image} ${expected_publishable_image}"

  assert_output -p "pushing image to gitlab registry"

  assert_output -p "push ${expected_publishable_image}"

}

このテストは、Dockerが異なる引数で2回呼び出されるという期待を設定します。 Dockerへの2回目の呼び出しが失敗すると、testedコマンドが実行され、終了ステータスとDockerへの予想される呼び出しがテストされます。

mock_docker.bashによって導入されたBATSの1つの側面 $ {BATS_TMPDIR}です 環境変数。BATSが最初に設定して、テストとヘルパーが標準の場所でTMPファイルを作成および破棄できるようにします。 mock_docker.bash ライブラリは、テストが失敗した場合に永続化されたmocksファイルを削除しませんが、ファイルが配置されている場所を印刷して、表示および削除できるようにします。このディレクトリから古いモックファイルを定期的に削除する必要がある場合があります。

モック/スタブに関する注意事項： build.bats テストは、次のようなテストの規定に意識的に違反しています。所有していないものをあざけるな！このディクタムでは、 docker のように、テストの開発者が作成しなかったコマンドを呼び出す必要があります。 、猫 、 sed などは、それらを使用するスクリプトのテストでモックする必要がある独自のライブラリにラップする必要があります。次に、外部コマンドをモックせずにラッパーライブラリをテストする必要があります。

これは良いアドバイスであり、無視するとコストがかかります。 Docker CLI APIが変更された場合、テストスクリプトはこの変更を検出しないため、テストされた build.shまで明示されない誤検知が発生します。 スクリプトは、新しいバージョンのDockerを使用した本番環境で実行されます。テスト開発者は、この標準をどの程度厳守するかを決定する必要がありますが、決定に伴うトレードオフを理解する必要があります。