ทดสอบ Bash ด้วย BATS

นักพัฒนาซอฟต์แวร์ที่เขียนแอปพลิเคชันในภาษาต่างๆ เช่น Java, Ruby และ Python มีไลบรารีที่ซับซ้อนเพื่อช่วยในการรักษาความสมบูรณ์ของซอฟต์แวร์เมื่อเวลาผ่านไป พวกเขาสร้างการทดสอบที่เรียกใช้แอปพลิเคชันผ่านชุดของการดำเนินการในสภาพแวดล้อมที่มีโครงสร้างเพื่อให้แน่ใจว่าด้านซอฟต์แวร์ทั้งหมดทำงานตามที่คาดไว้

การทดสอบเหล่านี้มีประสิทธิภาพมากขึ้นเมื่อเป็นแบบอัตโนมัติในระบบการรวมอย่างต่อเนื่อง (CI) ซึ่งทุกการกดไปยังที่เก็บต้นทางจะทำให้การทดสอบทำงาน และนักพัฒนาจะได้รับแจ้งทันทีเมื่อการทดสอบล้มเหลว ข้อเสนอแนะที่รวดเร็วนี้ช่วยเพิ่มความมั่นใจให้กับนักพัฒนาในความสมบูรณ์ของฟังก์ชันของแอปพลิเคชัน

ระบบทดสอบอัตโนมัติของ Bash (BATS) ช่วยให้นักพัฒนาเขียนสคริปต์และไลบรารีของ Bash เพื่อใช้แนวทางปฏิบัติเดียวกันกับ Java, Ruby, Python และนักพัฒนารายอื่นๆ กับโค้ด Bash ของตนได้

กำลังติดตั้ง BATS

หน้า BATS GitHub มีคำแนะนำในการติดตั้ง มีไลบรารีตัวช่วย BATS สองไลบรารีที่ให้การยืนยันที่มีประสิทธิภาพมากขึ้นหรืออนุญาตให้แทนที่รูปแบบเอาต์พุต Test Anything Protocol (TAP) ที่ใช้โดย BATS สิ่งเหล่านี้สามารถติดตั้งในตำแหน่งมาตรฐานและมาจากสคริปต์ทั้งหมด อาจสะดวกกว่าที่จะรวม BATS เวอร์ชันสมบูรณ์และไลบรารีตัวช่วยในที่เก็บ Git สำหรับชุดสคริปต์หรือไลบรารีแต่ละชุดที่กำลังทดสอบ สามารถทำได้โดยใช้ โมดูลย่อย git ระบบ

คำสั่งต่อไปนี้จะติดตั้ง BATS และไลบรารีตัวช่วยใน การทดสอบ ไดเร็กทอรีในที่เก็บ Git

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 และติดตั้งโมดูลย่อยพร้อมกัน ให้ใช้

--recurse-submodules ตั้งค่าสถานะเป็น git clone .

สคริปต์ทดสอบ BATS แต่ละรายการต้องดำเนินการโดย ค้างคาว ปฏิบัติการได้ หากคุณติดตั้ง BATS ลงใน test/libs . ของซอร์สโค้ด repo ไดเรกทอรี คุณสามารถเรียกใช้การทดสอบด้วย:

./test/libs/bats/bin/bats <path to test script>

หรือเพิ่มสิ่งต่อไปนี้ที่จุดเริ่มต้นของสคริปต์ทดสอบ BATS ของคุณ:

#!/usr/bin/env ./test/libs/bats/bin/bats

load 'libs/bats-support/load'

load 'libs/bats-assert/load'

และ chmod +x <เส้นทางเพื่อทดสอบสคริปต์> . สิ่งนี้จะทำให้ a) ปฏิบัติการได้ด้วย BATS ที่ติดตั้งใน ./test/libs/bats และ b) รวมไลบรารีตัวช่วยเหล่านี้ โดยทั่วไปสคริปต์ทดสอบ BATS จะถูกเก็บไว้ใน การทดสอบ ไดเร็กทอรีและตั้งชื่อตามสคริปต์ที่กำลังทดสอบ แต่มี .bats การขยาย. ตัวอย่างเช่น สคริปต์ BATS ที่ทดสอบ bin/build ควรเรียกว่า test/build.bats .

คุณยังสามารถเรียกใช้ไฟล์ทดสอบ BATS ทั้งชุดได้โดยส่งนิพจน์ทั่วไปไปที่ BATS เช่น ./test/lib/bats/bin/bats test/*.bats .

การจัดระเบียบไลบรารีและสคริปต์สำหรับการครอบคลุม BATS

สคริปต์ทุบตีและไลบรารีต้องได้รับการจัดระเบียบในลักษณะที่แสดงการทำงานภายในของพวกเขาต่อ BATS อย่างมีประสิทธิภาพ โดยทั่วไป ฟังก์ชันไลบรารีและเชลล์สคริปต์ที่เรียกใช้คำสั่งจำนวนมากเมื่อมีการเรียกใช้หรือดำเนินการจะไม่ตอบสนองต่อการทดสอบ BATS อย่างมีประสิทธิภาพ

ตัวอย่างเช่น build.sh เป็นสคริปต์ทั่วไปที่หลายคนเขียน มันเป็นรหัสกองใหญ่ บางคนอาจใส่โค้ดกองนี้ไว้ในฟังก์ชันในไลบรารี แต่เป็นไปไม่ได้ที่จะเรียกใช้โค้ดจำนวนมากในการทดสอบ BATS และครอบคลุมความล้มเหลวทุกประเภทที่อาจเกิดขึ้นได้ในกรณีทดสอบแยกกัน วิธีเดียวที่จะทดสอบโค้ดกองนี้ด้วยความครอบคลุมที่เพียงพอคือการแยกออกเป็นฟังก์ชันขนาดเล็ก ใช้ซ้ำได้ และที่สำคัญที่สุดคือ สามารถทดสอบได้อย่างอิสระ

การเพิ่มฟังก์ชันต่างๆ ลงในไลบรารีเป็นเรื่องง่าย ประโยชน์เพิ่มเติมคือฟังก์ชันบางอย่างอาจมีประโยชน์อย่างน่าประหลาดใจในสิทธิของตนเอง เมื่อคุณแบ่งฟังก์ชันไลบรารีของคุณออกเป็นฟังก์ชันย่อยๆ มากมายแล้ว คุณสามารถซอร์ส ไลบรารีใน BATS ของคุณจะทดสอบและเรียกใช้ฟังก์ชันต่างๆ เหมือนกับที่คุณทำกับคำสั่งอื่นๆ เพื่อทดสอบ

สคริปต์ทุบตียังต้องแบ่งออกเป็นหลายฟังก์ชัน ซึ่งส่วนหลักของสคริปต์ควรเรียกเมื่อเรียกใช้สคริปต์ นอกจากนี้ยังมีเคล็ดลับที่มีประโยชน์มากในการทำให้การทดสอบสคริปต์ทุบตีด้วย BATS ง่ายขึ้นมาก:นำโค้ดทั้งหมดที่ดำเนินการในส่วนหลักของสคริปต์และย้ายไปยังฟังก์ชันที่เรียกว่า run_main . จากนั้น เพิ่มสิ่งต่อไปนี้ต่อท้ายสคริปต์:

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]

then

  run_main

fi

รหัสพิเศษนี้ทำสิ่งพิเศษ มันทำให้สคริปต์ทำงานแตกต่างออกไปเมื่อถูกเรียกใช้งานเป็นสคริปต์มากกว่าเมื่อถูกนำเข้าสู่สภาพแวดล้อมด้วย แหล่งที่มา . เคล็ดลับนี้ช่วยให้สคริปต์สามารถทดสอบได้เช่นเดียวกับการทดสอบไลบรารี โดยการจัดหาและทดสอบแต่ละฟังก์ชัน ตัวอย่างเช่น นี่คือ build.sh ที่ปรับโครงสร้างใหม่เพื่อให้ทดสอบ BATS ได้ดีขึ้น

การเขียนและเรียกใช้การทดสอบ

ดังที่กล่าวไว้ข้างต้น BATS เป็นเฟรมเวิร์กการทดสอบที่สอดคล้องกับ TAP ที่มีรูปแบบและเอาต์พุตที่คุ้นเคยกับผู้ที่เคยใช้ชุดการทดสอบที่สอดคล้องกับ TAP อื่นๆ เช่น JUnit, RSpec หรือ Jest การทดสอบถูกจัดเป็นสคริปต์ทดสอบแต่ละรายการ สคริปต์ทดสอบถูกจัดเป็น @test หนึ่งคำอธิบายหรือมากกว่า บล็อกที่อธิบายหน่วยของแอปพลิเคชันที่กำลังทดสอบ แต่ละ @test block จะรันชุดคำสั่งที่เตรียมสภาพแวดล้อมการทดสอบ รันคำสั่งที่จะทดสอบ และทำการยืนยันเกี่ยวกับการออกและเอาต์พุตของคำสั่งที่ทดสอบ ฟังก์ชันการยืนยันจำนวนมากนำเข้าด้วย ค้างคาว , ค้างคาว-ยืนยัน และ สนับสนุนค้างคาว ไลบรารีซึ่งโหลดเข้าสู่สภาพแวดล้อมที่จุดเริ่มต้นของสคริปต์ทดสอบ BATS นี่คือบล็อกทดสอบ 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 มีการตั้งค่า และ/หรือ การฉีกขาด ฟังก์ชันเหล่านี้จะถูกดำเนินการโดยอัตโนมัติโดย BATS ก่อนและหลังการรันบล็อกการทดสอบแต่ละครั้ง ทำให้สามารถสร้างตัวแปรสภาพแวดล้อม ทดสอบไฟล์ และทำสิ่งอื่นๆ ที่จำเป็นสำหรับการทดสอบหนึ่งรายการหรือทั้งหมด จากนั้นแยกส่วนออกหลังจากการทดสอบแต่ละครั้งทำงาน Build.bats เป็นการทดสอบ BATS เต็มรูปแบบของ build.sh . ที่จัดรูปแบบใหม่ของเรา สคริปต์ (mock_docker คำสั่งในการทดสอบนี้จะอธิบายไว้ด้านล่างในหัวข้อการเยาะเย้ย/การขัดสี)

เมื่อสคริปต์ทดสอบทำงาน BATS จะใช้ exec เพื่อเรียกใช้ @test . แต่ละรายการ บล็อกเป็นกระบวนการย่อยที่แยกจากกัน ทำให้สามารถส่งออกตัวแปรสภาพแวดล้อมและแม้กระทั่งฟังก์ชันใน @test โดยไม่กระทบต่อ @test . อื่นๆ หรือสร้างมลพิษให้กับเซสชันเชลล์ปัจจุบันของคุณ ผลลัพธ์ของการทดสอบเป็นรูปแบบมาตรฐานที่มนุษย์สามารถเข้าใจได้ และแยกวิเคราะห์หรือจัดการโดยทางโปรแกรมโดยผู้บริโภค TAP นี่คือตัวอย่างผลลัพธ์สำหรับ CI_COMMIT_REF_SLUG บล็อกทดสอบเมื่อล้มเหลว:

 ✗ 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

ตัวช่วย

เช่นเดียวกับเชลล์สคริปต์หรือไลบรารีอื่นๆ สคริปต์ทดสอบ BATS สามารถรวมไลบรารีตัวช่วยเพื่อแชร์โค้ดทั่วไปในการทดสอบหรือปรับปรุงความสามารถ ไลบรารีตัวช่วยเหล่านี้ เช่น bats-assert และ สนับสนุนค้างคาว สามารถทดสอบได้ด้วย BATS

ไลบรารีสามารถวางในไดเร็กทอรีทดสอบเดียวกันกับสคริปต์ BATS หรือใน test/libs ไดเร็กทอรีหากจำนวนไฟล์ในไดเร็กทอรีทดสอบนั้นเทอะทะ BATS ให้ โหลด ฟังก์ชันที่นำพา ธ ไปยังไฟล์ Bash ที่สัมพันธ์กับสคริปต์ที่กำลังทดสอบ (เช่น ทดสอบ ในกรณีของเรา) และแหล่งที่มาของไฟล์นั้น ไฟล์ต้องลงท้ายด้วยคำนำหน้า .bash แต่เส้นทางไปยังไฟล์ส่งผ่านไปยัง load ฟังก์ชันไม่สามารถรวมคำนำหน้าได้ build.bats โหลด bats-assert และ สนับสนุนค้างคาว ไลบรารี helpers.bash . ขนาดเล็ก ไลบรารี่ และ docker_mock.bash ไลบรารี่ (อธิบายไว้ด้านล่าง) โดยมีโค้ดต่อไปนี้วางไว้ที่จุดเริ่มต้นของสคริปต์ทดสอบด้านล่างเส้นเวทย์มนตร์ของล่าม:

load 'libs/bats-support/load'

load 'libs/bats-assert/load'

load 'helpers'

load 'docker_mock'

การทดสอบอินพุตและการเยาะเย้ยการโทรภายนอก

สคริปต์และไลบรารีของ Bash ส่วนใหญ่เรียกใช้ฟังก์ชันและ/หรือไฟล์เรียกทำงานเมื่อทำงาน มักถูกตั้งโปรแกรมให้ทำงานในลักษณะเฉพาะตามสถานะการออกหรือเอาต์พุต (stdout , stderr ) ของฟังก์ชันหรือไฟล์สั่งการเหล่านี้ ในการทดสอบสคริปต์เหล่านี้อย่างถูกต้อง มักจะจำเป็นต้องสร้างเวอร์ชันปลอมของคำสั่งเหล่านี้ ซึ่งได้รับการออกแบบมาให้ทำงานในลักษณะเฉพาะในระหว่างการทดสอบเฉพาะ กระบวนการที่เรียกว่า "stubbing" อาจจำเป็นต้องสอดแนมโปรแกรมที่กำลังทดสอบเพื่อให้แน่ใจว่าเรียกใช้คำสั่งเฉพาะ หรือเรียกคำสั่งเฉพาะที่มีอาร์กิวเมนต์เฉพาะ กระบวนการที่เรียกว่า "การเยาะเย้ย" สำหรับข้อมูลเพิ่มเติม โปรดดูการอภิปรายที่ยอดเยี่ยมเกี่ยวกับการเยาะเย้ยและการขัดจังหวะใน Ruby RSpec ซึ่งใช้กับระบบการทดสอบใดๆ

เปลือก Bash มีเทคนิคที่สามารถใช้ในสคริปต์ทดสอบ BATS ของคุณเพื่อทำการเยาะเย้ยและตัดทอน ทั้งหมดต้องใช้ Bash ส่งออก คำสั่งด้วย -f ตั้งค่าสถานะเพื่อส่งออกฟังก์ชันที่แทนที่ฟังก์ชันเดิมหรือเรียกใช้งานได้ ต้องทำก่อนที่จะรันโปรแกรมที่ทดสอบ นี่เป็นตัวอย่างง่ายๆ ที่แทนที่ แมว ปฏิบัติการ:

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

export -f cat

เมธอดนี้จะแทนที่ฟังก์ชันในลักษณะเดียวกัน หากการทดสอบจำเป็นต้องแทนที่ฟังก์ชันภายในสคริปต์หรือไลบรารีที่กำลังทดสอบ สิ่งสำคัญคือต้องระบุแหล่งที่มาของสคริปต์หรือไลบรารีที่ทดสอบก่อนที่ฟังก์ชันนั้นจะถูกตัดทอนหรือเยาะเย้ย มิฉะนั้น stub/mock จะถูกแทนที่ด้วยฟังก์ชันจริงเมื่อมีการจัดหาสคริปต์ นอกจากนี้ ตรวจสอบให้แน่ใจว่าได้ stub/mock ก่อนที่คุณจะรันคำสั่งที่คุณกำลังทดสอบ นี่คือตัวอย่างจาก 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"

}

โดยปกติ ไม่จำเป็นต้องยกเลิกการตั้งค่าฟังก์ชัน stub/mock หลังจากการทดสอบ เนื่องจาก ส่งออก มีผลเฉพาะกับกระบวนการย่อยปัจจุบันระหว่าง exec ของ @test current ปัจจุบัน บล็อก. อย่างไรก็ตาม เป็นไปได้ที่จะจำลอง/คำสั่งต้นขั้ว (เช่น แมว , เส็ด เป็นต้น) ที่ BATS ยืนยัน * ฟังก์ชั่นใช้ภายใน ฟังก์ชันจำลอง/ต้นขั้วเหล่านี้ต้อง ยกเลิกการตั้งค่า ก่อนที่คำสั่งยืนยันเหล่านี้จะรัน มิฉะนั้นคำสั่งเหล่านั้นจะทำงานไม่ถูกต้อง นี่คือตัวอย่างจาก build.bats ที่เยาะเย้ย เส็ด , รัน 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 จะถูกเรียกสองครั้งโดยมีอาร์กิวเมนต์ต่างกัน เมื่อเรียกใช้ Docker ครั้งที่สองล้มเหลว ระบบจะเรียกใช้คำสั่งที่ทดสอบแล้ว จากนั้นทดสอบสถานะการออกและการเรียกใช้ที่คาดหวังไปยัง Docker

แง่มุมหนึ่งของ BATS นำเสนอโดย mock_docker.bash คือ ${BATS_TMPDIR} ตัวแปรสภาพแวดล้อม ซึ่ง BATS ตั้งค่าไว้ที่จุดเริ่มต้นเพื่อให้การทดสอบและผู้ช่วยสร้างและทำลายไฟล์ TMP ในตำแหน่งมาตรฐาน mock_docker.bash ไลบรารีจะไม่ลบไฟล์ mocks ที่คงอยู่หากการทดสอบล้มเหลว แต่จะพิมพ์ตำแหน่งที่อยู่เพื่อให้สามารถดูและลบได้ คุณอาจต้องล้างไฟล์จำลองเก่าออกจากไดเรกทอรีนี้เป็นระยะ

ข้อควรระวังเกี่ยวกับการเยาะเย้ย/สลบ:build.bats การทดสอบละเมิดคำสั่งของการทดสอบที่ระบุว่า:อย่าเยาะเย้ยสิ่งที่คุณไม่ได้เป็นเจ้าของ! คำสั่งนี้เรียกร้องให้เรียกใช้คำสั่งที่นักพัฒนาทดสอบไม่ได้เขียน เช่น นักเทียบท่า , แมว , เส็ด ฯลฯ ควรรวมไว้ในไลบรารีของตนเอง ซึ่งควรล้อเลียนในการทดสอบสคริปต์ที่ใช้ จากนั้น ไลบรารีของ wrapper ควรได้รับการทดสอบโดยไม่ต้องเยาะเย้ยคำสั่งภายนอก

นี่เป็นคำแนะนำที่ดีและไม่สนใจมันมาพร้อมกับค่าใช้จ่าย หาก Docker CLI API เปลี่ยนแปลง สคริปต์ทดสอบจะไม่ตรวจพบการเปลี่ยนแปลงนี้ ส่งผลให้เกิดผลบวกที่ผิดพลาดซึ่งจะไม่ปรากฏจนกว่า build.sh ที่ทดสอบแล้ว สคริปต์ทำงานในการตั้งค่าการใช้งานจริงด้วย Docker เวอร์ชันใหม่ นักพัฒนาทดสอบต้องตัดสินใจว่าพวกเขาต้องการปฏิบัติตามมาตรฐานนี้อย่างเคร่งครัดเพียงใด แต่ควรเข้าใจข้อเสียที่เกี่ยวข้องกับการตัดสินใจของพวกเขา

บทสรุป

การแนะนำระบบการทดสอบสำหรับโครงการพัฒนาซอฟต์แวร์ใดๆ ทำให้เกิดการแลกเปลี่ยนระหว่าง a) การเพิ่มเวลาและองค์กรที่จำเป็นในการพัฒนาและรักษารหัสและการทดสอบ และ b) ความมั่นใจที่เพิ่มขึ้นของนักพัฒนาที่มีต่อความสมบูรณ์ของแอปพลิเคชันตลอดอายุการใช้งาน ระบบการทดสอบอาจไม่เหมาะสมกับสคริปต์และไลบรารีทั้งหมด

โดยทั่วไป สคริปต์และไลบรารีที่ตรงตามข้อใดข้อหนึ่งต่อไปนี้ควรได้รับการทดสอบด้วย BATS:

มีค่าควรเก็บไว้ในการควบคุมแหล่งที่มา
มีการใช้ในกระบวนการที่สำคัญและต้องอาศัยการทำงานอย่างต่อเนื่องเป็นระยะเวลานาน
จำเป็นต้องแก้ไขเป็นระยะเพื่อเพิ่ม/ลบ/แก้ไขฟังก์ชัน
คนอื่นใช้

เมื่อตัดสินใจใช้วินัยการทดสอบกับสคริปต์หรือไลบรารีของ Bash ตั้งแต่หนึ่งรายการขึ้นไป BATS จะมอบคุณลักษณะการทดสอบที่ครอบคลุมซึ่งมีให้ใช้งานในสภาพแวดล้อมการพัฒนาซอฟต์แวร์อื่นๆ

รับทราบ:ฉันเป็นหนี้บุญคุณ Darrin Mann ที่ได้แนะนำให้ฉันรู้จักกับการทดสอบ BATS