জাভা, রুবি, এবং পাইথন-এর মতো ভাষায় অ্যাপ্লিকেশন লিখতে वाले সফটওয়্যার ডেভেলপাররা তাদের সফটওয়্যার অখণ্ডতা সময়ের সাথে ধরে রক্ষা করার জন্য সফিস্টিকেটেড লাইব্রেরি ব্যবহার করে। তারা টেস্ট তৈরি করে যা অ্যাপ্লিকেশনকে স্ট্রাকচারড এনভায়রনমেন্টে এক্সিকিউশনের একটি সিরিজের মধ্য দিয়ে নিয়ে যায় যাতে সফটওয়্যারের সব দিক প্রত্যাশা অনুযায়ী কাজ করে কিনা তা নিশ্চিত করা যায়।
এই টেস্টগুলো আরও শক্তিশালী হয়ে ওঠে যখন সেগুলো একটি কন্টিনিউয়াস ইন্টিগ্রেশন (CI) সিস্টেমে অটোমেটেড হয়, যেখানে সোর্স রিপোজিটরিতে প্রতিটি পুশ টেস্টগুলোকে রান করে, এবং ডেভেলপারদের সাথে সাথে নোটিফাই করা হয় যখন টেস্ট ফেইল করে। এই দ্রুত ফিডব্যাক ডেভেলপারদের তাদের অ্যাপ্লিকেশন ফাংশনাল ইন্টিগ্রিটির ওপর আত্মবিশ্বাস বাড়ায়।
বাশ অটোমেটেড টেস্টিং সিস্টেম (BATS) বাশ স্ক্রিপ্ট এবং লাইব্রেরি লিখতে वाले ডেভেলপারদের জাভা, রুবি, পাইথন, এবং অন্যান্য ডেভেলপাররা যে প্র্যাকটিসগুলো ফলো করে সেগুলো তাদের বাশ কোডে প্রয়োগ করতে সক্ষম করে।
BATS ইনস্টল করা
BATS GitHub পেজে ইনস্টলেশন ইনস্ট্রাকশন আছে। দুটি BATS হেল্পার লাইব্রেরি আছে যা আরও শক্তিশালী অ্যাসারশন প্রদান করে বা Test Anything Protocol (TAP) আউটপুট ফরম্যাট ওভাররাইড করার অনুমতি দেয় যা BATS ব্যবহার করে। এগুলো একটি স্ট্যান্ডার্ড লোকেশনে ইনস্টল করা যেতে পারে এবং সকল স্ক্রিপ্ট দ্বারা সোর্স করা যেতে পারে। প্রতিটি স্ক্রিপ্ট বা লাইব্রেরি সেটের জন্য BATS এবং এর হেল্পার লাইব্রেরির একটি কমপ্লিট ভার্সন Git রিপোজিটরিতে git submodule সিস্টেম ব্যবহার করে অন্তর্ভুক্ত করা আরও সুবিধাজনক হতে পারে।
নিচের কমান্ডগুলো 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 রিপোজিটরি ক্লোন করে এবং এর সাবমডিউলস একসাথে ইনস্টল করতে, git clone-এ --recurse-submodules ফ্ল্যাগ ব্যবহার করুন।
প্রতিটি BATS টেস্ট স্ক্রিপ্ট অবশ্যই bats এক্সিকিউটেবল দ্বারা এক্সিকিউট হতে হবে। আপনি যদি BATS আপনার সোর্স কোড রিপোজিটরির test/libs ডিরেক্টরিতে ইনস্টল করেন, তবে আপনি টেস্টটি আহ্বান করতে পারেন:
./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 <path to test script> করুন। এটি ক) সেগুলোকে ./test/libs/bats-এ ইনস্টল করা BATS-এ এক্সিকিউটেবল করবে এবং খ) এই হেল্পার লাইব্রেরিগুলো অন্তর্ভুক্ত করবে। BATS টেস্ট স্ক্রিপ্ট সাধারণত test ডিরেক্টরিতে সংরক্ষিত থাকে এবং যেটি টেস্ট করা হচ্ছে সেটির নাম অনুযায়ী নামকরণ করা হয়, কিন্তু এক্সটেনশন থাকে .bats। উদাহরণস্বরূপ, bin/build টেস্ট করা BATS স্ক্রিপ্টের নাম হওয়া উচিত test/build.bats।
আপনি পুরো সেট BATS টেস্ট ফাইলও রান করতে পারেন রেগুলার এক্সপ্রেশন BATS-এ পাস করে, যেমন: ./test/lib/bats/bin/bats test/*.bats।
লাইব্রেরি এবং স্ক্রিপ্ট BATS কভারেজের জন্য সংগঠিত করা
বাশ স্ক্রিপ্ট এবং লাইব্রেরি এমনভাবে সংগঠিত হতে হবে যাতে তাদের অন্তর্নিহিত কাজকর্ম BATS-এ দক্ষতার সাথে এক্সপোজ করা যায়। সাধারণত, লাইব্রেরি ফাংশন এবং শেল স্ক্রিপ্ট যেগুলো কল বা এক্সিকিউট হওয়ার সময় অনেক কমান্ড রান করে, সেগুলো দক্ষ BATS টেস্টের জন্য উপযুক্ত নয়।
উদাহরণস্বরূপ, build.sh একটি সাধারণ স্ক্রিপ্ট যা অনেক লোক লিখে। এটি মূলত কোডের একটি বড় ڈান। কিছু লোক এটি একটি লাইব্রেরিতে একটি ফাংশনে রাখে। কিন্তু একটি বড় কোড ডানকে BATS টেস্টে রান করে এর সম্মুখীন হতে পারা সব ধরনের ফেইলার আলাদা আলাদা টেস্ট কেসে কভার করা অসম্ভব। এই কোড ডানকে পর্যাপ্ত কভারেজের সাথে টেস্ট করার একমাত্র উপায় হলো এটিকে অনেক ছোট, পুনরায় ব্যবহারযোগ্য, এবং সবচেয়ে গুরুত্বপূর্ণভাবে, স্বাধীনভাবে টেস্টযোগ্য ফাংশনে ভাঙা।
এক লাইব্রেরিতে আরও ফাংশন যোগ করা সোজা। একটি অ্যাডেড বেনিফিট হলো এই ফাংশনগুলোর কিছু নিজস্বভাবে আশ্চর্য পরিমাণে উপকারী হতে পারে। একবার আপনি আপনার লাইব্রেরি ফাংশনকে অনেক ছোট ফাংশনে ভাঙলেন, আপনি লাইব্রেরিটি আপনার BATS টেস্টে source করে ফাংশনগুলোকে যেকোনো অন্য কমান্ডের মত রান করে টেস্ট করতে পারেন।
বাশ স্ক্রিপ্টগুলোকেও অবশ্যই একাধিক ফাংশনে ভাঙতে হবে, যা স্ক্রিপ্ট এক্সিকিউট হওয়ার সময় স্ক্রিপ্টের মূল অংশ কল করবে। thêmitionally, BATS-এ বাশ স্ক্রিপ্ট টেস্ট করা অনেক সহজ করার একটি খুব উপকারী ট্রিক আছে: স্ক্রিপ্টের মূল অংশে এক্সিকিউট হওয়া সকল কোড নিন এবং সেগুলো একটি ফাংশনে মুভ করুন, নাম দিন কিছু run_main এর মতো। তারপর স্ক্রিপ্টের শেষে নিচের কোড যোগ করুন:
if [[ "${BASH_SOURCE[0]}" == "${0}" ]]
then
run_main
fi
এই এক্সট্রা কোডটুকু কিছু 스페সিয়াল করে। এটি স্ক্রিপ্টকে ভিন্নভাবে বিহেভ করাতে পারে যখন এটি একটি স্ক্রিপ্ট হিসেবে এক্সিকিউট হয় বনাম যখন এটি source দিয়ে এনভায়রনমেন্টে আনা হয়। এই ট্রিক স্ক্রিপ্টকে একইভাবে টেস্ট করতে সক্ষম করে যেভাবে একটি লাইব্রেরি টেস্ট করা হয়, সোর্স করে এবং পৃথক ফাংশন টেস্ট করে। উদাহরণস্বরূপ, এখানে build.sh রিফ্যাক্টর করা হলো बेटার BATS টেস্টেবিলিটির জন্য।
টেস্ট লেখা এবং রান করা
উপরোক্ত উল্লেখ অনুযায়ী, BATS একটি TAP-কম্প্লায়েন্ট টেস্টিং ফ্রেমওয়ার্ক যার সিনট্যাক্স এবং আউটপুট তাদের কাছে পরিচিত যারা অন্যান্য TAP-কম্প্লায়েন্ট টেস্টিং স্যুট ব্যবহার করেছেন, যেমন JUnit, RSpec, বা Jest। এর টেস্টগুলো পৃথক টেস্ট স্ক্রিপ্টে সংগঠিত। টেস্ট স্ক্রিপ্টগুলো এক বা একাধিক বর্ণনামূলক @test ব্লকে সংগঠিত থাকে যা অ্যাপ্লিকেশন যে ইউনিটটি টেস্ট করা হচ্ছে সেটি বর্ণনা করে। প্রতিটি @test ব্লক কমান্ডের একটি সিরিজ রান করে যা টেস্ট এনভায়রনমেন্ট প্রস্তুত করে, টেস্ট করা কমান্ডটি রান করে, এবং টেস্ট করা কমান্ডের এক্সিট এবং আউটপুট সম্পর্কে অ্যাসারশন করে। অনেক অ্যাসারশন ফাংশন bats, bats-assert, এবং bats-support লাইব্রেরি থেকে ইম্পোর্ট করা হয়, যেগুলো 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 স্ক্রিপ্টে setup এবং/অথবা teardown ফাংশন থাকে, সেগুলো BATS দ্বারা প্রতিটি টেস্ট ব্লক রান হওয়ার আগে এবং পরে অটোমেটিক্যালি এক্সিকিউট হয়। এটি এনভায়রনমেন্ট ভেরিয়েবল তৈরি করা, টেস্ট ফাইল তৈরি করা, এবং এক বা সব টেস্টের জন্য দরকার অন্যান্য কাজ করা সম্ভব করে, তারপর প্রতিটি টেস্ট রান হওয়ার পরে সেগুলো টিয়ার ডাউন করে। Build.bats আমাদের নতুন ফরম্যাট করা build.sh স্ক্রিপ্টের একটি পূর্ণ BATS টেস্ট। (mock_docker কমান্ড এই টেস্টে নিচে মকিং/স্টাবিং সেকশনে ব্যাখ্যা করা হবে।)
যখন টেস্ট স্ক্রিপ্ট রান হয়, BATS প্রতিটি @test ব্লককে একটি আলাদা সাবপ্রসেস হিসেবে exec ব্যবহার করে রান করে। এটি এক @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-support, এছাড়াও BATS-এ টেস্ট করা যায়।
লাইব্রেরিগুলো BATS স্ক্রিপ্টের সাথে একই টেস্ট ডিরেক্টরিতে রাখা যায় বা test/libs ডিরেক্টরিতে যদি টেস্ট ডিরেক্টরির ফাইল সংখ্যা অনম্যানেজেবল হয়। BATS load ফাংশন প্রদান করে যা একটি পথ নেয় একটি বাশ ফাইলের যা স্ক্রিপ্টের সাথে রিলেটিভ (যেমন test, আমাদের কেসে) এবং সেটি সোর্স করে। ফাইলগুলোর অবশ্যই .bash প্রিফিক্স দিয়ে শেষ হতে হবে, কিন্তু load ফাংশনে পাস করা পথে প্রিফিক্স থাকতে পারবে না। build.bats bats-assert এবং bats-support লাইব্রেরি, একটি ছোট helpers.bash লাইব্রেরি, এবং একটি docker_mock.bash লাইব্রেরি (নিচে বর্ণিত) লোড করে নিচের কোড ইন্টারপ্রিটার ম্যাজিক লাইনের নিচে টেস্ট স্ক্রিপ্টের শুরুতে রাখে:
load 'libs/bats-support/load' load 'libs/bats-assert/load' load 'helpers' load 'docker_mock'
টেস্ট ইনপুট স্টাবিং এবং এক্সটার্নাল কল মকিং
বেশির ভাগ বাশ স্ক্রিপ্ট এবং লাইব্রেরি রান হওয়ার সময় ফাংশন এবং/অথবা এক্সিকিউটেবল এক্সিকিউট করে। প্রায়শই সেগুলো নির্দিষ্ট উপায়ে বিহেভ করার জন্য প্রোগ্রাম করা থাকে সেই ফাংশন বা এক্সিকিউটেবলের এক্সিট স্ট্যাটাস বা আউটপুট (stdout, stderr) অনুযায়ী। এই স্ক্রিপ্টগুলো সঠিকভাবে টেস্ট করার জন্য, প্রায়শই এই কমান্ডগুলোর নকল ভার্সন তৈরি করা প্রয়োজন যা একটি স্পেসিফিক টেস্টের সময় নির্দিষ্ট উপায়ে বিহেভ করার জন্য ডিজাইন করা থাকে, একটি প্রক্রিয়া যাকে "স্টাবিং" বলা হয়। এছাড়া প্রোগ্রামটিকে স্পাই করা প্রয়োজন হতে পারে যাতে নিশ্চিত করা যায় সেটি একটি স্পেসিফিক কমান্ড কল করছে, বা সেটি একটি স্পেসিফিক কমান্ড নির্দিষ্ট আর্গুমেন্টসহ কল করছে, একটি প্রক্রিয়া যাকে "মকিং" বলা হয়। এর ব্যাপারে আরো জানতে, Ruby RSpec-এ মকিং এবং স্টাবিং নিয়ে এই চমৎকার আলোচনা দেখুন, যা যেকোনো টেস্টিং সিস্টেমের জন্য প্রযোজ্য।
বাশ শেল কিছু ট্রিক প্রদান করে যা আপনার BATS টেস্ট স্ক্রিপ্টে মকিং এবং স্টাবিং করতে ব্যবহার করা যায়। সবগুলো বাশ export কমান্ডের -f ফ্ল্যাগ ব্যবহার করার প্রয়োজন যা একটি ফাংশন এক্সপোর্ট করে যা আসল ফাংশন বা এক্সিকিউটেবলকে ওভাররাইড করে। এটি টেস্ট করা প্রোগ্রাম এক্সিকিউট হওয়ার আগে করতে হবে। এখানে একটি সহজ উদাহরণ যা cat এক্সিকিউটেবলকে ওভাররাইড করে:
function cat() { echo "THIS WOULD CAT ${*}" }
export -f cat
এই মেথড একইভাবে একটি ফাংশনকে ওভাররাইড করে। যদি একটি টেস্টকে টেস্ট করা স্ক্রিপ্ট বা লাইব্রেরির ভিতরের একটি ফাংশন ওভাররাইড করতে হয়, তবে ফাংশন স্টাব বা মক করার আগে টেস্ট করা স্ক্রিপ্ট বা লাইব্রেরি সোর্স করা গুরুত্বপূর্ণ। অন্যথায়, স্টাব/মক আসল ফাংশন দ্বারা রিপ্লেসড হবে যখন স্ক্রিপ্ট সোর্স করা হবে। এছাড়া, আপনি যে কমান্ডটি টেস্ট করছেন সেটি রান করার আগে স্টাব/মক করতে ভুলবেন না। এখানে build.bats-এ একটি উদাহরণ যা raise ফাংশনকে মক করে যা 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 শুধু কারেন্ট সাবপ্রসেসকে প্রভাবিত করে কারেন্ট @test ব্লকের exec অবস্থায়। যাইহোক, কিছু কমান্ড মক/স্টাব করা সম্ভব (যেমন cat, sed, ইত্যাদি) যা BATS assert* ফাংশনগুলো ইন্টারনালি ব্যবহার করে। এই মক/স্টাব ফাংশনগুলো অবশ্যই unset করতে হবে এই অ্যাসারশন কমান্ডগুলো রান করার আগে, নাহলে সেগুলো সঠিকভাবে কাজ করবে না। এখানে 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 ফাইল সরায়, teardown ফাংশনে ব্যবহার করার জন্য। এটি টেস্ট করতে পারে যে একটি @test ব্লক সফল হয়েছিল কিনা সরানোর আগে।
যেহেতু এই ফাংশন্যালিটি প্রায়শই ভিন্ন টেস্টে পুনরায় ব্যবহার করা হয়, একটি হেল্পার লাইব্রেরি তৈরি করা যেটি অন্য লাইব্রেরির মত লোড করা যায় সেটি অর্থপূর্ণ।
একটি ভালো উদাহরণ হলো docker_mock.bash। এটি build.bats-এ লোড করা হয় এবং যেকোনো টেস্ট ব্লকে ব্যবহার করা হয় যা ডকার এক্সিকিউটেবল কল করা ফাংশন টেস্ট করে। 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}"
}
এই টেস্ট একটি এক্সপেকটেশন সেট করে যে ডকার দুবার কল হবে ভিন্ন আর্গুমেন্টসহ। দ্বিতীয় কল ডকার ফেইল হওয়ার সাথে, এটি টেস্ট করা কমান্ড রান করে, তারপর এক্সিট স্ট্যাটাস এবং ডকারের আশা করা কলগুলো টেস্ট করে।
BATS-এ mock_docker.bash দ্বারা পরিচয় করানো একটি দিক হলো ${BATS_TMPDIR} এনভায়রনমেন্ট ভেরিয়েবল, যা BATS শুরুতেই সেট করে যাতে টেস্ট এবং হেল্পাররা একটি স্ট্যান্ডার্ড লোকেশনে TMP ফাইল তৈরি এবং ধ্বংস করতে পারে। mock_docker.bash লাইব্রেরি তার পার্সিস্টেড মক ফাইল ডিলিট করবে না যদি একটি টেস্ট ফেইল করে, কিন্তু এটি প্রিন্ট করবে সেটি কোথায় অবস্থিত যাতে সেটি দেখা এবং ডিলিট করা যায়। আপনাকে এই ডিরেক্টরি থেকে পুরনো মক ফাইল পিরিয়ডিক্যালি ক্লিন করতে হতে পারে।
মকিং/স্টাবিং সম্পর্কে একটি সতর্কতা: build.bats টেস্ট সচেতনভাবে টেস্টিং এর একটি ডিক্টাম লঙ্ঘন করে যা বলে: Don't mock what you don't own! এই ডিক্টাম দাবি করে যে টেস্টের ডেভেলপার যা লিখেননি সেসব কমান্ডে কল, যেমন docker, cat, sed, ইত্যাদি, তাদের নিজস্ব লাইব্রেরিতে র্যাপ করা উচিত, যেগুলো টেস্ট করা স্ক্রিপ্টগুলোর টেস্টে মক করা উচিত। র্যাপার লাইব্রেরিগুলো তারপর এক্সটার্নাল কমান্ড মক ছাড়া টেস্ট করা উচিত।
এটি ভালো পরামর্শ এবং এটিকে উপেক্ষা করার একটি কস্ট আছে। যদি Docker CLI API পরিবর্তন হয়, টেস্ট স্ক্রিপ্টগুলো সেটি ডিটেক্ট করবে না, ফলে একটি ফলস পজিটিভ হবে যা ম্যানিফেস্ট হবে না যতক্ষণ না টেস্ট করা build.sh স্ক্রিপ্ট প্রোডাকশন সেটিং-এ নতুন ভার্সন ডকারের সাথে রান হবে। টেস্ট ডেভেলপাররা নিজেদের সিদ্ধান্ত নিতে হবে তারা কত কঠোরভাবে এই স্ট্যান্ডার্ড মেনে চলবেন, কিন্তু সেগুলো তাদের সিদ্ধান্তের ট্রেডঅফ বুঝতে হবে।
উপসংহার
যেকোনো সফটওয়্যার ডেভেলপমেন্ট প্রজেক্টে একটি টেস্টিং রেজিম চালু করা একটি ট্রেডঅফ সৃষ্টি করে a) কোড এবং টেস্ট ডেভেলপ ও মেইনটেইন করার জন্য সময় ও সংগঠনের বৃদ্ধি এবং b) অ্যাপ্লিকেশন এর আজীবন ইন্টিগ্রিটির ওপর ডেভেলপারদের বাড়ানো আত্মবিশ্বাস। টেস্টিং রেজিম সব স্ক্রিপ্ট এবং লাইব্রেরির জন্য উপযুক্ত নাও হতে পারে।
সাধারণত, স্ক্রিপ্ট এবং লাইব্রেরি যারা নিচের এক বা একাধিক শর্ত পূরণ করে সেগুলো BATS-এ টেস্ট করা উচিত:
- তারা সোর্স কন্ট্রোলে সংরক্ষণের যোগ্য
- তারা ক্রিটিক্যাল প্রসেসে ব্যবহৃত হয় এবং দীর্ঘ কাল ধরে সামঞ্জস্যপূর্ণ রান করার জন্য নির্ভর করা হয়
- তাদের কালক্রমে ফাংশন যোগ/বাদ/মডিফাই করার প্রয়োজন হয়
- তারা অন্যদের দ্বারা ব্যবহৃত হয়
একবার এক বা একাধিক বাশ স্ক্রিপ্ট বা লাইব্রেরিতে একটি টেস্টিং ডিসিপ্লিন প্রয়োগ করার সিদ্ধান্ত নেওয়া হলে, BATS স exhaustif টেস্টিং ফিচার প্রদান করে যা অন্যান্য সফটওয়্যার ডেভেলপমেন্ট এনভায়রনমেন্টে উপলব্ধ।
Acknowledgment: I am indebted to Darrin Mann for introducing me to BATS testing.
