利用 BATS 測試 Bash 腳本和庫

作者：Darin London 2021-03-11 21:30:43

Bash 自動(dòng)測試系統(tǒng)可以使 Bash 代碼也通過 Java、Ruby 和 Python 開發(fā)人員所使用的同類測試過程。

[[387054]]

Bash 自動(dòng)測試系統(tǒng)可以使 Bash 代碼也通過 Java、Ruby 和 Python 開發(fā)人員所使用的同類測試過程。

用 Java、Ruby 和 Python 等語言編寫應(yīng)用程序的軟件開發(fā)人員擁有復(fù)雜的庫，可以幫助他們隨著時(shí)間的推移保持軟件的完整性。他們可以創(chuàng)建測試，以在結(jié)構(gòu)化環(huán)境中通過執(zhí)行一系列動(dòng)作來運(yùn)行應(yīng)用程序，以確保其軟件所有的方面均按預(yù)期工作。

當(dāng)這些測試在持續(xù)集成（CI）系統(tǒng)中自動(dòng)進(jìn)行時(shí)，它們的功能就更加強(qiáng)大了，每次推送到源代碼庫都會觸發(fā)測試，并且在測試失敗時(shí)會立即通知開發(fā)人員。這種快速反饋提高了開發(fā)人員對其應(yīng)用程序功能完整性的信心。

Bash 自動(dòng)測試系統(tǒng)Bash Automated Testing System（BATS）使編寫 Bash 腳本和庫的開發(fā)人員能夠?qū)?Java、Ruby、Python 和其他開發(fā)人員所使用的相同慣例應(yīng)用于其 Bash 代碼中。

安裝 BATS

BATS GitHub 頁面包含了安裝指令。有兩個(gè) BATS 輔助庫提供更強(qiáng)大的斷言或允許覆寫 BATS 使用的 Test Anything Protocol（TAP）輸出格式。這些庫可以安裝在一個(gè)標(biāo)準(zhǔn)位置，并被所有的腳本引用。更方便的做法是，將 BATS 及其輔助庫的完整版本包含在 Git 倉庫中，用于要測試的每組腳本或庫。這可以通過 git 子模塊系統(tǒng)來完成。

以下命令會將 BATS 及其輔助庫安裝到 Git 知識庫中的 test 目錄中。

git submodule init
git submodule add https://github.com/sstephenson/bats test/libs/bats
git submodule add https://github.com/ztombol/bats-assert test/libs/bats-assert
git submodule add https://github.com/ztombol/bats-support test/libs/bats-support
git add .
git commit -m 'installed bats'

要克隆 Git 倉庫并同時(shí)安裝其子模塊，請?jiān)?nbsp;git clone 時(shí)使用 --recurse-submodules 標(biāo)記。

每個(gè) BATS 測試腳本必須由 bats 可執(zhí)行文件執(zhí)行。如果你將 BATS 安裝到源代碼倉庫的 test/libs 目錄中，則可以使用以下命令調(diào)用測試：

./test/libs/bats/bin/bats <測試腳本的路徑>

或者，將以下內(nèi)容添加到每個(gè) BATS 測試腳本的開頭：

#!/usr/bin/env ./test/libs/bats/bin/bats
load 'libs/bats-support/load'
load 'libs/bats-assert/load'

并且執(zhí)行命令 chmod +x <測試腳本的路徑>。這將 a、使它們可與安裝在 ./test/libs/bats 中的 BATS 一同執(zhí)行，并且 b、包含這些輔助庫。BATS 測試腳本通常存儲在 test 目錄中，并以要測試的腳本命名，擴(kuò)展名為 .bats。例如，一個(gè)測試 bin/build 的 BATS 腳本應(yīng)稱為 test/build.bats。

你還可以通過向 BATS 傳遞正則表達(dá)式來運(yùn)行一整套 BATS 測試文件，例如 ./test/lib/bats/bin/bats test/*.bats。

為 BATS 覆蓋率而組織庫和腳本

Bash 腳本和庫必須以一種有效地方式將其內(nèi)部工作原理暴露給 BATS 進(jìn)行組織。通常，在調(diào)用或執(zhí)行時(shí)庫函數(shù)和運(yùn)行諸多命令的 Shell 腳本不適合進(jìn)行有效的 BATS 測試。

例如，build.sh 是許多人都會編寫的典型腳本。本質(zhì)上是一大堆代碼。有些人甚至可能將這堆代碼放入庫中的函數(shù)中。但是，在 BATS 測試中運(yùn)行一大堆代碼，并在單獨(dú)的測試用例中覆蓋它可能遇到的所有故障類型是不可能的。測試這堆代碼并有足夠的覆蓋率的唯一方法就是把它分解成許多小的、可重用的、最重要的是可獨(dú)立測試的函數(shù)。

向庫添加更多的函數(shù)很簡單。額外的好處是其中一些函數(shù)本身可以變得出奇的有用。將庫函數(shù)分解為許多較小的函數(shù)后，你可以在 BATS 測試中援引source這些庫，并像測試任何其他命令一樣運(yùn)行這些函數(shù)。

Bash 腳本也必須分解為多個(gè)函數(shù)，執(zhí)行腳本時(shí)，腳本的主要部分應(yīng)調(diào)用這些函數(shù)。此外，還有一個(gè)非常有用的技巧，可以讓你更容易地用 BATS 測試 Bash 腳本：將腳本主要部分中執(zhí)行的所有代碼都移到一個(gè)函數(shù)中，稱為 run_main。然后，將以下內(nèi)容添加到腳本的末尾：

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]
then
  run_main
fi

這段額外的代碼做了一些特別的事情。它使腳本在作為腳本執(zhí)行時(shí)與使用援引source進(jìn)入環(huán)境時(shí)的行為有所不同。通過援引并測試單個(gè)函數(shù)，這個(gè)技巧使得腳本的測試方式和庫的測試方式變得一樣。例如，這是重構(gòu)的 build.sh，以獲得更好的 BATS 可測試性。

編寫和運(yùn)行測試

如上所述，BATS 是一個(gè) TAP 兼容的測試框架，其語法和輸出對于使用過其他 TAP 兼容測試套件（例如 JUnit、RSpec 或 Jest）的用戶來說將是熟悉的。它的測試被組織成單個(gè)測試腳本。測試腳本被組織成一個(gè)或多個(gè)描述性 @test 塊中，它們描述了被測試應(yīng)用程序的單元。每個(gè) @test 塊將運(yùn)行一系列命令，這些命令準(zhǔn)備測試環(huán)境、運(yùn)行要測試的命令，并對被測試命令的退出和輸出進(jìn)行斷言。許多斷言函數(shù)是通過 bats、bats-assert 和 bats-support 庫導(dǎo)入的，這些庫在 BATS 測試腳本的開頭加載到環(huán)境中。下面是一個(gè)典型的 BATS 測試塊：

@test "requires CI_COMMIT_REF_SLUG environment variable" {
  unset CI_COMMIT_REF_SLUG
  assert_empty "${CI_COMMIT_REF_SLUG}"
  run some_command
  assert_failure
  assert_output --partial "CI_COMMIT_REF_SLUG"
}

如果 BATS 腳本包含 setup（安裝）和/或 teardown（拆卸）函數(shù)，則 BATS 將在每個(gè)測試塊運(yùn)行之前和之后自動(dòng)執(zhí)行它們。這樣就可以創(chuàng)建環(huán)境變量、測試文件以及執(zhí)行一個(gè)或所有測試所需的其他操作，然后在每次測試運(yùn)行后將其拆卸。Build.bats 是對我們新格式化的 build.sh 腳本的完整 BATS 測試。（此測試中的 mock_docker 命令將在以下關(guān)于模擬/打標(biāo)的部分中進(jìn)行說明。）

當(dāng)測試腳本運(yùn)行時(shí)，BATS 使用 exec（執(zhí)行）來將每個(gè) @test 塊作為單獨(dú)的子進(jìn)程運(yùn)行。這樣就可以在一個(gè) @test 中導(dǎo)出環(huán)境變量甚至函數(shù)，而不會影響其他 @test 或污染你當(dāng)前的 Shell 會話。測試運(yùn)行的輸出是一種標(biāo)準(zhǔn)格式，可以被人理解，并且可以由 TAP 使用端以編程方式進(jìn)行解析或操作。下面是 CI_COMMIT_REF_SLUG 測試塊失敗時(shí)的輸出示例：

 ✗ requires CI_COMMIT_REF_SLUG environment variable
   (from function `assert_output' in file test/libs/bats-assert/src/assert.bash, line 231,
    in test file test/ci_deploy.bats, line 26)
     `assert_output --partial "CI_COMMIT_REF_SLUG"' failed
 
   -- output does not contain substring --
   substring (1 lines):
     CI_COMMIT_REF_SLUG
   output (3 lines):
     ./bin/deploy.sh: join_string_by: command not found
     oc error
     Could not login
   --
 
   ** Did not delete , as test failed **
 
1 test, 1 failure

下面是成功測試的輸出：

✓ requires CI_COMMIT_REF_SLUG environment variable

輔助庫

像任何 Shell 腳本或庫一樣，BATS 測試腳本可以包括輔助庫，以在測試之間共享通用代碼或增強(qiáng)其性能。這些輔助庫，例如 bats-assert 和 bats-support 甚至可以使用 BATS 進(jìn)行測試。

庫可以和 BATS 腳本放在同一個(gè)測試目錄下，如果測試目錄下的文件數(shù)量過多，也可以放在 test/libs 目錄下。BATS 提供了 load 函數(shù)，該函數(shù)接受一個(gè)相對于要測試的腳本的 Bash 文件的路徑（例如，在我們的示例中的 test），并援引該文件。文件必須以后綴 .bash 結(jié)尾，但是傳遞給 load 函數(shù)的文件路徑不能包含后綴。build.bats 加載 bats-assert 和 bats-support 庫、一個(gè)小型 helpers.bash 庫以及 docker_mock.bash 庫（如下所述），以下代碼位于測試腳本的開頭，解釋器魔力行下方：

load 'libs/bats-support/load'
load 'libs/bats-assert/load'
load 'helpers'
load 'docker_mock'

打標(biāo)測試輸入和模擬外部調(diào)用

大多數(shù) Bash 腳本和庫運(yùn)行時(shí)都會執(zhí)行函數(shù)和/或可執(zhí)行文件。通常，它們被編程為基于這些函數(shù)或可執(zhí)行文件的輸出狀態(tài)或輸出（stdout、stderr）以特定方式運(yùn)行。為了正確地測試這些腳本，通常需要制作這些命令的偽版本，這些命令被設(shè)計(jì)成在特定測試過程中以特定方式運(yùn)行，稱為“打標(biāo)stubbing”。可能還需要監(jiān)視正在測試的程序，以確保其調(diào)用了特定命令，或者使用特定參數(shù)調(diào)用了特定命令，此過程稱為“模擬mocking”。有關(guān)更多信息，請查看在 Ruby RSpec 中有關(guān)模擬和打標(biāo)的討論，它適用于任何測試系統(tǒng)。

Bash shell 提供了一些技巧，可以在你的 BATS 測試腳本中使用這些技巧進(jìn)行模擬和打標(biāo)。所有這些都需要使用帶有 -f 標(biāo)志的 Bash export 命令來導(dǎo)出一個(gè)覆蓋了原始函數(shù)或可執(zhí)行文件的函數(shù)。必須在測試程序執(zhí)行之前完成此操作。下面是重寫可執(zhí)行命令 cat 的簡單示例：

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

此方法以相同的方式覆蓋了函數(shù)。如果一個(gè)測試需要覆蓋要測試的腳本或庫中的函數(shù)，則在對函數(shù)進(jìn)行打標(biāo)或模擬之前，必須先聲明已測試腳本或庫，這一點(diǎn)很重要。否則，在聲明腳本時(shí)，打標(biāo)/模擬將被原函數(shù)替代。另外，在運(yùn)行即將進(jìn)行的測試命令之前確認(rèn)打標(biāo)/模擬。下面是build.bats 的示例，該示例模擬 build.sh 中描述的raise 函數(shù)，以確保登錄函數(shù)會引發(fā)特定的錯(cuò)誤消息：

@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"
}

一般情況下，沒有必要在測試后復(fù)原打標(biāo)/模擬的函數(shù)，因?yàn)?nbsp;export（輸出）僅在當(dāng)前 @test 塊的 exec（執(zhí)行）期間影響當(dāng)前子進(jìn)程。但是，可以模擬/打標(biāo) BATS assert 函數(shù)在內(nèi)部使用的命令（例如 cat、sed 等）是可能的。在運(yùn)行這些斷言命令之前，必須對這些模擬/打標(biāo)函數(shù)進(jìn)行 unset（復(fù)原），否則它們將無法正常工作。下面是 build.bats 中的一個(gè)示例，該示例模擬 sed，運(yùn)行 build_deployable 函數(shù)并在運(yùn)行任何斷言之前復(fù)原 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}"
}

有的時(shí)候相同的命令，例如 foo，將在被測試的同一函數(shù)中使用不同的參數(shù)多次調(diào)用。這些情況需要?jiǎng)?chuàng)建一組函數(shù)：

mock_foo：將期望的參數(shù)作為輸入，并將其持久化到 TMP 文件中
foo：命令的模擬版本，該命令使用持久化的預(yù)期參數(shù)列表處理每個(gè)調(diào)用。必須使用 export -f 將其導(dǎo)出。
cleanup_foo：刪除 TMP 文件，用于拆卸函數(shù)。這可以進(jìn)行測試以確保在刪除之前成功完成 @test 塊。

由于此功能通常在不同的測試中重復(fù)使用，因此創(chuàng)建一個(gè)可以像其他庫一樣加載的輔助庫會變得有意義。

docker_mock.bash 是一個(gè)很棒的例子。它被加載到 build.bats 中，并在任何測試調(diào)用 Docker 可執(zhí)行文件的函數(shù)的測試塊中使用。使用 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}"
}

該測試建立了一個(gè)使用不同的參數(shù)兩次調(diào)用 Docker 的預(yù)期。在對Docker 的第二次調(diào)用失敗時(shí)，它會運(yùn)行測試命令，然后測試退出狀態(tài)和對 Docker 調(diào)用的預(yù)期。

一方面 BATS 利用 mock_docker.bash 引入 ${BATS_TMPDIR} 環(huán)境變量，BATS 在測試開始的位置對其進(jìn)行了設(shè)置，以允許測試和輔助程序在標(biāo)準(zhǔn)位置創(chuàng)建和銷毀 TMP 文件。如果測試失敗，mock_docker.bash 庫不會刪除其持久化的模擬文件，但會打印出其所在位置，以便可以查看和刪除它。你可能需要定期從該目錄中清除舊的模擬文件。

關(guān)于模擬/打標(biāo)的一個(gè)注意事項(xiàng)：build.bats 測試有意識地違反了關(guān)于測試聲明的規(guī)定：不要模擬沒有擁有的！該規(guī)定要求調(diào)用開發(fā)人員沒有編寫代碼的測試命令，例如 docker、cat、sed 等，應(yīng)封裝在自己的庫中，應(yīng)在使用它們腳本的測試中對其進(jìn)行模擬。然后應(yīng)該在不模擬外部命令的情況下測試封裝庫。

這是一個(gè)很好的建議，而忽略它是有代價(jià)的。如果 Docker CLI API 發(fā)生變化，則測試腳本不會檢測到此變化，從而導(dǎo)致錯(cuò)誤內(nèi)容直到經(jīng)過測試的 build.sh 腳本在使用新版本 Docker 的生產(chǎn)環(huán)境中運(yùn)行后才顯示出來。測試開發(fā)人員必須確定要嚴(yán)格遵守此標(biāo)準(zhǔn)的程度，但是他們應(yīng)該了解其所涉及的權(quán)衡。