BATS দিয়ে ব্যাশ পরীক্ষা করা হচ্ছে

সফ্টওয়্যার বিকাশকারীরা জাভা, রুবি এবং পাইথনের মতো ভাষায় অ্যাপ্লিকেশন লেখেন তাদের সময়ের সাথে তাদের সফ্টওয়্যারটির অখণ্ডতা বজায় রাখতে সহায়তা করার জন্য অত্যাধুনিক লাইব্রেরি রয়েছে। তারা এমন পরীক্ষা তৈরি করে যা তাদের সফ্টওয়্যারের সমস্ত দিক প্রত্যাশিতভাবে কাজ করে তা নিশ্চিত করার জন্য কাঠামোগত পরিবেশে একের পর এক এক্সিকিউশনের মাধ্যমে অ্যাপ্লিকেশন চালায়।

এই পরীক্ষাগুলি আরও শক্তিশালী হয় যখন সেগুলি একটি ক্রমাগত ইন্টিগ্রেশন (CI) সিস্টেমে স্বয়ংক্রিয় হয়, যেখানে উত্স সংগ্রহস্থলে প্রতিটি ধাক্কা পরীক্ষাগুলি চালানোর কারণ হয় এবং পরীক্ষাগুলি ব্যর্থ হলে বিকাশকারীদের অবিলম্বে অবহিত করা হয়। এই দ্রুত প্রতিক্রিয়া ডেভেলপারদের তাদের অ্যাপ্লিকেশনের কার্যকরী অখণ্ডতার উপর আস্থা বাড়ায়।

ব্যাশ অটোমেটেড টেস্টিং সিস্টেম (বিএটিএস) ডেভেলপারদের ব্যাশ স্ক্রিপ্ট এবং লাইব্রেরি লিখতে জাভা, রুবি, পাইথন এবং অন্যান্য ডেভেলপারদের দ্বারা তাদের ব্যাশ কোডে ব্যবহৃত একই অনুশীলনগুলি প্রয়োগ করতে সক্ষম করে৷

BATS ইনস্টল করা হচ্ছে

BATS GitHub পৃষ্ঠাতে ইনস্টলেশন নির্দেশাবলী অন্তর্ভুক্ত রয়েছে। দুটি BATS হেল্পার লাইব্রেরি রয়েছে যা আরও শক্তিশালী দাবী প্রদান করে বা BATS দ্বারা ব্যবহৃত টেস্ট এনিথিং প্রোটোকল (টিএপি) আউটপুট ফর্ম্যাটে ওভাররাইড করার অনুমতি দেয়। এগুলি একটি আদর্শ অবস্থানে ইনস্টল করা যেতে পারে এবং সমস্ত স্ক্রিপ্ট দ্বারা উত্স করা যেতে পারে। পরীক্ষা করা স্ক্রিপ্ট বা লাইব্রেরির প্রতিটি সেটের জন্য গিট রিপোজিটরিতে BATS এবং এর সহায়ক লাইব্রেরিগুলির একটি সম্পূর্ণ সংস্করণ অন্তর্ভুক্ত করা আরও সুবিধাজনক হতে পারে। এটি গিট সাবমডিউল ব্যবহার করে সম্পন্ন করা যেতে পারে সিস্টেম।

নিম্নলিখিত কমান্ডগুলি BATS এবং এর সহায়ক লাইব্রেরিগুলিকে পরীক্ষায় ইনস্টল করবে একটি গিট সংগ্রহস্থলে ডিরেক্টরি।

git submodule init
git submodule যোগ করুন https://github.com/sstephenson/bats test/libs/bats
git submodule https://github.com/ztombol/bats-assert পরীক্ষা যোগ করুন /libs/bats-assert
git submodule যোগ করুন https://github.com/ztombol/bats-support test/libs/bats-support
git add .
git commit -m' ইনস্টল করা হয়েছে bats'

একটি Git সংগ্রহস্থল ক্লোন করতে এবং একই সময়ে এর সাবমডিউলগুলি ইনস্টল করতে,

--recurse-submodules ব্যবহার করুন গিট ক্লোন-এ পতাকা .

প্রতিটি BATS পরীক্ষার স্ক্রিপ্ট অবশ্যই bats দ্বারা কার্যকর করা উচিত নির্বাহযোগ্য আপনি যদি আপনার সোর্স কোড রেপোর পরীক্ষা/libs এ BATS ইনস্টল করেন ডিরেক্টরি, আপনি এর সাথে পরীক্ষা শুরু করতে পারেন:

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

বিকল্পভাবে, আপনার প্রতিটি BATS পরীক্ষার স্ক্রিপ্টের শুরুতে নিম্নলিখিত যোগ করুন:

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

এবং chmod +x <পাথ পরীক্ষা করার স্ক্রিপ্ট> . এটি একটি) ./test/libs/bats-এ ইনস্টল করা BATS-এর মাধ্যমে এগুলিকে সম্পাদনযোগ্য করে তুলবে। এবং খ) এই সহায়ক গ্রন্থাগারগুলি অন্তর্ভুক্ত করুন। 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<বলা হয়। . তারপর, স্ক্রিপ্টের শেষে নিম্নলিখিত যোগ করুন:

যদি [[ "${BASH_SOURCE[0]}" =="${0}" ]]
তাহলে
  run_main
fi

অতিরিক্ত কোড এই বিট বিশেষ কিছু করে. যখন এটি উৎস এর সাথে পরিবেশে আনা হয় তখন স্ক্রিপ্ট হিসাবে এটি কার্যকর করা হলে এটি স্ক্রিপ্টটিকে ভিন্নভাবে আচরণ করে . এই কৌশলটি স্ক্রিপ্টটিকে একইভাবে পরীক্ষা করতে সক্ষম করে যেভাবে একটি লাইব্রেরি পরীক্ষা করা হয়, এটি সোর্সিং করে এবং পৃথক ফাংশন পরীক্ষা করে। উদাহরণস্বরূপ, উন্নত BATS পরীক্ষাযোগ্যতার জন্য এখানে build.sh রিফ্যাক্টর করা হয়েছে।

লেখা এবং পরীক্ষা চালানো

উপরে উল্লিখিত হিসাবে, BATS হল একটি সিনট্যাক্স এবং আউটপুট সহ একটি TAP-সঙ্গতিপূর্ণ পরীক্ষার কাঠামো যা তাদের কাছে পরিচিত হবে যারা অন্যান্য TAP-সঙ্গতিপূর্ণ টেস্টিং স্যুটগুলি ব্যবহার করেছেন, যেমন JUnit, RSpec, বা Jest৷ এর পরীক্ষাগুলি পৃথক পরীক্ষার স্ক্রিপ্টে সংগঠিত হয়। পরীক্ষার স্ক্রিপ্টগুলি এক বা একাধিক বর্ণনামূলক @test-এ সংগঠিত হয়৷ ব্লক যা পরীক্ষা করা অ্যাপ্লিকেশনটির ইউনিট বর্ণনা করে। প্রতিটি @পরীক্ষা ব্লক একাধিক কমান্ড চালাবে যা পরীক্ষার পরিবেশ প্রস্তুত করে, পরীক্ষা করার জন্য কমান্ড চালায় এবং পরীক্ষিত কমান্ডের প্রস্থান এবং আউটপুট সম্পর্কে দাবি করে। অনেক দাবী ফাংশন ব্যাট দিয়ে আমদানি করা হয় , ব্যাট-জ্যাসার্ট , এবং ব্যাট-সাপোর্ট লাইব্রেরি, যা BATS পরীক্ষার স্ক্রিপ্টের শুরুতে পরিবেশে লোড করা হয়। এখানে একটি সাধারণ BATS পরীক্ষার ব্লক রয়েছে:

@test "requires CI_COMMIT_REF_SLUG এনভায়রনমেন্ট ভেরিয়েবল" {
  CI_COMMIT_REF_SLUG আনসেট করুন
  assert_empty "${CI_COMMIT_REF_SLUG}"
  কিছু_কমান্ড চালান
  "assert_M_REF_SLUG অংশ হিসাবে 
 ureF_REF_SLUG> ureF_REF_SLUG অংশ চালান -- "
}

যদি একটি BATS স্ক্রিপ্ট সেটআপ অন্তর্ভুক্ত করে এবং/অথবা টিয়ারডাউন ফাংশন, প্রতিটি পরীক্ষার ব্লক চলার আগে এবং পরে সেগুলি স্বয়ংক্রিয়ভাবে BATS দ্বারা কার্যকর হয়। এটি এনভায়রনমেন্ট ভেরিয়েবল তৈরি করা, ফাইল পরীক্ষা করা এবং এক বা সমস্ত পরীক্ষার জন্য প্রয়োজনীয় অন্যান্য জিনিসগুলি করা সম্ভব করে তোলে, তারপর প্রতিটি পরীক্ষা চালানোর পরে সেগুলি ছিঁড়ে ফেলুন। build.bats আমাদের নতুন ফর্ম্যাট করা build.sh এর সম্পূর্ণ BATS পরীক্ষা লিপি. (মক_ডকার এই পরীক্ষার কমান্ডটি নীচে ব্যাখ্যা করা হবে, মকিং/স্টাবিং বিভাগে।)

যখন টেস্ট স্ক্রিপ্ট চলে, তখন BATS exec ব্যবহার করে প্রতিটি @পরীক্ষা চালানোর জন্য একটি পৃথক সাবপ্রসেস হিসাবে ব্লক করুন। এটি একটি @test-এ পরিবেশের ভেরিয়েবল এবং এমনকি ফাংশন রপ্তানি করা সম্ভব করে তোলে অন্য @test কে প্রভাবিত না করে s বা আপনার বর্তমান শেল অধিবেশন দূষণ. একটি পরীক্ষা চালানোর আউটপুট একটি আদর্শ বিন্যাস যা মানুষ বুঝতে পারে এবং TAP গ্রাহকদের দ্বারা প্রোগ্রাম্যাটিকভাবে পার্স বা ম্যানিপুলেট করা যায়। এখানে CI_COMMIT_REF_SLUG-এর আউটপুটের একটি উদাহরণ রয়েছে পরীক্ষা ব্লক যখন এটি ব্যর্থ হয়:

 ✗ এর জন্য CI_COMMIT_REF_SLUG এনভায়রনমেন্ট ভেরিয়েবল প্রয়োজন
 (ফাইল test/libs/bats-asssert/src/assert.bash, লাইন 231,
  পরীক্ষা ফাইল test/ci_deploy.bats-এ ফাংশন `assert_output' থেকে, লাইন 26)
   `assert_output --partial "CI_COMMIT_REF_SLUG"' ব্যর্থ হয়েছে

   -- আউটপুটে সাবস্ট্রিং নেই --
   সাবস্ট্রিং (1 লাইন):
   CI_COMMIT_REF_SLUG
    আউটপুট (3 লাইন):
    ./bin/deploy.sh:join_string_by:কমান্ড পাওয়া যায়নি
    oc ত্রুটি
     লগইন করা যায়নি
   --

   ** মোছা হয়নি, পরীক্ষা ব্যর্থ হওয়ায় **

1 পরীক্ষা, 1 ব্যর্থ

এখানে একটি সফল পরীক্ষার আউটপুট:

✓ requires CI_COMMIT_REF_SLUG environment variable 

সহায়ক

যেকোনো শেল স্ক্রিপ্ট বা লাইব্রেরির মতো, BATS টেস্ট স্ক্রিপ্টগুলি পরীক্ষা জুড়ে সাধারণ কোড শেয়ার করতে বা তাদের ক্ষমতা বাড়াতে সহায়ক লাইব্রেরি অন্তর্ভুক্ত করতে পারে। এই সাহায্যকারী লাইব্রেরি, যেমন bats-assert এবং ব্যাট-সাপোর্ট , এমনকি BATS দিয়ে পরীক্ষা করা যেতে পারে।

লাইব্রেরিগুলিকে BATS স্ক্রিপ্টের মতো একই টেস্ট ডিরেক্টরিতে বা test/libs-এ রাখা যেতে পারে টেস্ট ডিরেক্টরিতে ফাইলের সংখ্যা অপ্রত্যাশিত হলে ডিরেক্টরি। BATS লোড প্রদান করে ফাংশন যা পরীক্ষিত স্ক্রিপ্টের সাপেক্ষে একটি ব্যাশ ফাইলের পথ নেয় (যেমন, পরীক্ষা , আমাদের ক্ষেত্রে) এবং সূত্র যে ফাইল. ফাইলগুলি অবশ্যই .bash উপসর্গ দিয়ে শেষ হবে৷ , কিন্তু ফাইলের পাথ লোড-এ চলে গেছে ফাংশন উপসর্গ অন্তর্ভুক্ত করতে পারে না। build.bats ব্যাট-অ্যাসার্ট লোড করে এবং ব্যাট-সাপোর্ট লাইব্রেরি, একটি ছোট helpers.bash লাইব্রেরি, এবং একটি docker_mock.bash লাইব্রেরি (নীচে বর্ণিত) নিম্নলিখিত কোড সহ দোভাষী ম্যাজিক লাইনের নীচে পরীক্ষার স্ক্রিপ্টের শুরুতে স্থাপন করা হয়েছে:

লোড 'libs/bats-support/load'
load 'libs/bats-assert/load'
লোড 'helpers'
লোড 'docker_mock'

স্টাবিং টেস্ট ইনপুট এবং বহিরাগত কলগুলিকে উপহাস করা

বেশিরভাগ ব্যাশ স্ক্রিপ্ট এবং লাইব্রেরি ফাংশন এবং/অথবা এক্সিকিউটেবল চালানোর সময় চালায়। প্রায়শই তারা প্রস্থান অবস্থা বা আউটপুট (stdout এর উপর ভিত্তি করে নির্দিষ্ট উপায়ে আচরণ করার জন্য প্রোগ্রাম করা হয় , stderr ) এই ফাংশন বা এক্সিকিউটেবল। এই স্ক্রিপ্টগুলি সঠিকভাবে পরীক্ষা করার জন্য, প্রায়ই এই কমান্ডগুলির জাল সংস্করণ তৈরি করা প্রয়োজন যেগুলি একটি নির্দিষ্ট পরীক্ষার সময় একটি নির্দিষ্ট পদ্ধতিতে আচরণ করার জন্য ডিজাইন করা হয়েছে, একটি প্রক্রিয়া যাকে "স্টাবিং" বলা হয়। এটি একটি নির্দিষ্ট কমান্ড কল করে তা নিশ্চিত করার জন্য পরীক্ষা করা হচ্ছে এমন প্রোগ্রামের উপর গুপ্তচরবৃত্তি করার প্রয়োজন হতে পারে বা এটি নির্দিষ্ট আর্গুমেন্ট সহ একটি নির্দিষ্ট কমান্ডকে কল করে, একটি প্রক্রিয়া যাকে "মকিং" বলা হয়। এই বিষয়ে আরও জানতে, Ruby RSpec-এ উপহাস এবং স্টাবিংয়ের এই দুর্দান্ত আলোচনাটি দেখুন, যা যে কোনও পরীক্ষা পদ্ধতিতে প্রযোজ্য৷

ব্যাশ শেল এমন কৌশলগুলি সরবরাহ করে যা আপনার BATS পরীক্ষার স্ক্রিপ্টগুলিতে উপহাস এবং স্টাবিং করতে ব্যবহার করা যেতে পারে। সকলেরই ব্যাশ রপ্তানি ব্যবহার করা প্রয়োজন -f দিয়ে কমান্ড মূল ফাংশন বা এক্সিকিউটেবল ওভাররাইড করে এমন একটি ফাংশন এক্সপোর্ট করতে পতাকা। পরীক্ষিত প্রোগ্রামটি কার্যকর করার আগে এটি অবশ্যই করা উচিত। এখানে একটি সহজ উদাহরণ যা বিড়ালকে ওভাররাইড করে এক্সিকিউটেবল:

ফাংশন cat() { echo "এই বিড়াল ${*}" 
export -f cat

এই পদ্ধতিটি একই পদ্ধতিতে একটি ফাংশনকে ওভাররাইড করে। যদি একটি পরীক্ষার স্ক্রিপ্ট বা লাইব্রেরির মধ্যে একটি ফাংশন ওভাররাইড করার প্রয়োজন হয় যা পরীক্ষা করা হচ্ছে, তাহলে ফাংশনটি স্টাব বা উপহাস করার আগে পরীক্ষিত স্ক্রিপ্ট বা লাইব্রেরিটি উৎস করা গুরুত্বপূর্ণ। অন্যথায়, স্ক্রিপ্টটি উৎসারিত হলে স্টাব/মক প্রকৃত ফাংশনের সাথে প্রতিস্থাপিত হবে। এছাড়াও, আপনি যে কমান্ডটি পরীক্ষা করছেন তা চালানোর আগে স্টাব/মক করা নিশ্চিত করুন। এখানে build.bats থেকে একটি উদাহরণ দেওয়া হল যে বৃদ্ধিকে উপহাস করে build.sh-এ বর্ণিত ফাংশন লগইন ফাংশন দ্বারা একটি নির্দিষ্ট ত্রুটি বার্তা উত্থাপিত হয়েছে তা নিশ্চিত করতে:

@test ". লগইন oc ত্রুটির উপর উত্থাপন করে" {
  উৎস ${profile_script}
  ফাংশন raise() { echo "${1} rises"; 
  export -f raise
  login চালান
  assert_failure
  assert_output -p "লগইন করা যায়নি"
}

সাধারণত, পরীক্ষার পরে একটি স্টাব/মক ফাংশন আনসেট করার প্রয়োজন নেই, যেহেতু রপ্তানি শুধুমাত্র exec চলাকালীন বর্তমান সাবপ্রসেসকে প্রভাবিত করে বর্তমান @test এর ব্লক যাইহোক, উপহাস/স্টাব কমান্ড করা সম্ভব (যেমন cat , sed , ইত্যাদি) যেটি BATS আবেদন করে * ফাংশন অভ্যন্তরীণভাবে ব্যবহার করে। এই মক/স্টাব ফাংশনগুলি অবশ্যই আনসেট হতে হবে৷ এই assert কমান্ড চালানোর আগে, অথবা তারা সঠিকভাবে কাজ করবে না। এখানে build.bats থেকে একটি উদাহরণ দেওয়া হল যে sed উপহাস করে , build_deployable চালায় ফাংশন, এবং আনসেট sed কোনো দাবী চালানোর আগে:

@test ".build_deployable তথ্য মুদ্রণ করে, একটি পরিবর্তিত Dockerfile.production-এ ডকার বিল্ড চালায় এবং publish_image যখন এটি ড্রাই_রান না হয়" {
  local expect_dockerfile='Dockerfile.production'
  local application='application '
  local environment='environment'
  local expect_original_base_image="${application}"
  local expect_candidate_image="${application}-candidate:${environment}"
  local expect_deployable_image ="${application}:${environment}"
  উৎস ${profile_script}
  mock_docker build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t "${ expect_deployable_image}" -
  ফাংশন publish_image() { echo "publish_image ${*}"; 
  export -f publish_image
  ফাংশন 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 "বিল্ডিং ${expected_original_base_image} স্থাপনযোগ্য ${expected_deployable_image} FROM ${expected_candidate_image}"
  assert_output -p$_expected_p/id FROM_id-p হিসাবে $expected_output -p/id/ext_p_id করতে পারেন। -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_deploy>"}} /প্রে> 

 কখনও কখনও একই আদেশ, যেমন foo, পরীক্ষা করা একই ফাংশনে বিভিন্ন আর্গুমেন্ট সহ একাধিকবার আহ্বান করা হবে। এই পরিস্থিতিতে ফাংশনগুলির একটি সেট তৈরি করা প্রয়োজন:
 
 
mock_foo:প্রত্যাশিত আর্গুমেন্টগুলিকে ইনপুট হিসাবে নেয় এবং এগুলিকে একটি TMP ফাইলে স্থির রাখে
 
foo:কমান্ডের উপহাস করা সংস্করণ, যা প্রত্যাশিত আর্গুমেন্টের স্থায়ী তালিকা সহ প্রতিটি কল প্রক্রিয়া করে। এটি অবশ্যই রপ্তানি -f দিয়ে রপ্তানি করা উচিত।
 
cleanup_foo:টিএমপি ফাইল সরিয়ে দেয়, টিয়ারডাউন ফাংশনে ব্যবহারের জন্য। এটি একটি @test ব্লক অপসারণ করার আগে সফল হয়েছে তা নিশ্চিত করতে পরীক্ষা করতে পারে। 
 
 

 যেহেতু এই কার্যকারিতাটি প্রায়শই বিভিন্ন পরীক্ষায় পুনরায় ব্যবহার করা হয়, তাই এটি একটি সহায়ক লাইব্রেরি তৈরি করা বোধগম্য হয় যা অন্যান্য লাইব্রেরির মতো লোড করা যায়৷
 

 একটি ভাল উদাহরণ হল docker_mock.bash . এটি build.bats-এ লোড করা হয় এবং যেকোন পরীক্ষা ব্লকে ব্যবহৃত হয় যা একটি ফাংশন পরীক্ষা করে যা ডকারকে এক্সিকিউটেবল বলে। ডকার_মক ব্যবহার করে একটি সাধারণ পরীক্ষার ব্লক মনে হচ্ছে:
 
@test ".publish_image ব্যর্থ হলে ডকার পুশ ব্যর্থ হয়" {
  setup_publish
  local expect_image="image"
  local expect_publishable_image="${CI_REGISTRY_IMAGE}/${expected_image}"
  উৎস ${profile_script}
  mock_docker ট্যাগ "${expected_image}" "${expected_publishable_image}"
  mock_docker পুশ "${expected_publishable_image}" এবং_fail
  publish_image "${image}" চালান 
  assert_failure
  assert_output -p "${expected_image} কে ${expected_publishable_image} হিসাবে ট্যাগ করা"
  assert_output -p "ট্যাগ ${expected_image} ${expected_publishable_image}"
  "assert_output -p গিটল্যাব রেজিস্ট্রিতে ছবি পুশ করা হচ্ছে"
  assert_output -p "পুশ ${expected_publishable_image}"
}
 

 এই পরীক্ষাটি একটি প্রত্যাশা সেট করে যে ডকারকে বিভিন্ন যুক্তি সহ দুবার ডাকা হবে। ডকারে দ্বিতীয় কল ব্যর্থ হলে, এটি পরীক্ষিত কমান্ড চালায়, তারপর প্রস্থান স্থিতি পরীক্ষা করে এবং ডকারে প্রত্যাশিত কলগুলি পরীক্ষা করে৷
 

 BATS এর একটি দিক mock_docker.bash দ্বারা প্রবর্তিত হয়েছে হল ${BATS_TMPDIR} এনভায়রনমেন্ট ভেরিয়েবল, যা BATS শুরুতে সেট করে পরীক্ষা এবং সাহায্যকারীকে একটি স্ট্যান্ডার্ড অবস্থানে TMP ফাইল তৈরি ও ধ্বংস করতে দেয়। mock_docker.bash একটি পরীক্ষা ব্যর্থ হলে লাইব্রেরি তার স্থায়ী মক ফাইল মুছে ফেলবে না, তবে এটি মুদ্রণ করবে যেখানে এটি অবস্থিত যাতে এটি দেখা এবং মুছে ফেলা যায়। আপনাকে এই ডিরেক্টরি থেকে পর্যায়ক্রমে পুরানো মক ফাইলগুলি পরিষ্কার করতে হতে পারে৷
 

 উপহাস/স্টাবিং সংক্রান্ত সতর্কতার একটি নোট:The build.bats পরীক্ষা সচেতনভাবে পরীক্ষার একটি আদেশ লঙ্ঘন করে যা বলে:আপনি যা মালিক নন তাকে উপহাস করবেন না! এই আদেশটি দাবি করে যে কমান্ডগুলিকে কল করা হয় যা পরীক্ষার বিকাশকারী লিখেননি, যেমন ডকার , বিড়াল , sed , ইত্যাদি, তাদের নিজস্ব লাইব্রেরিতে মোড়ানো উচিত, যা তাদের ব্যবহার করে এমন স্ক্রিপ্টগুলির পরীক্ষায় উপহাস করা উচিত। র্যাপার লাইব্রেরিগুলি তখন বহিরাগত কমান্ডগুলিকে উপহাস না করে পরীক্ষা করা উচিত৷
 

 এটি একটি ভাল পরামর্শ এবং এটি উপেক্ষা করা একটি খরচ সঙ্গে আসে. Docker CLI API পরিবর্তিত হলে, পরীক্ষার স্ক্রিপ্টগুলি এই পরিবর্তনটি সনাক্ত করবে না, ফলে একটি মিথ্যা পজিটিভ যা পরীক্ষিত build.sh পর্যন্ত প্রকাশ পাবে না। স্ক্রিপ্ট ডকারের নতুন সংস্করণের সাথে একটি উত্পাদন সেটিংসে চলে। টেস্ট ডেভেলপারদের অবশ্যই সিদ্ধান্ত নিতে হবে যে তারা এই মানকে কতটা কঠোরভাবে মেনে চলতে চায়, তবে তাদের সিদ্ধান্তের সাথে জড়িত ট্রেডঅফগুলি বোঝা উচিত।
 
উপসংহার
 

 যেকোন সফ্টওয়্যার ডেভেলপমেন্ট প্রজেক্টে একটি টেস্টিং শাসন প্রবর্তন করা একটি ট্রেডঅফ তৈরি করে ক) কোড এবং পরীক্ষাগুলি বিকাশ এবং বজায় রাখার জন্য প্রয়োজনীয় সময় এবং সংস্থার বৃদ্ধি এবং খ) বিকাশকারীরা তার জীবদ্দশায় অ্যাপ্লিকেশনটির অখণ্ডতার উপর বর্ধিত আস্থা রাখে৷ সমস্ত স্ক্রিপ্ট এবং লাইব্রেরির জন্য পরীক্ষার ব্যবস্থাগুলি উপযুক্ত নাও হতে পারে৷
৷ 

 সাধারণভাবে, স্ক্রিপ্ট এবং লাইব্রেরি যা নিম্নলিখিত এক বা একাধিক পূরণ করে BATS দিয়ে পরীক্ষা করা উচিত:
 
 
এগুলি উৎস নিয়ন্ত্রণে সংরক্ষণ করার যোগ্য
 
এগুলি সমালোচনামূলক প্রক্রিয়াগুলিতে ব্যবহৃত হয় এবং দীর্ঘ সময়ের জন্য ধারাবাহিকভাবে চালানোর জন্য নির্ভর করে
 
তাদের ফাংশন যোগ/অপসারণ/সংশোধন করতে পর্যায়ক্রমে পরিবর্তন করতে হবে
 
এগুলি অন্যদের দ্বারা ব্যবহৃত হয়
 
 

 একবার এক বা একাধিক ব্যাশ স্ক্রিপ্ট বা লাইব্রেরিতে পরীক্ষামূলক শৃঙ্খলা প্রয়োগ করার সিদ্ধান্ত নেওয়া হলে, BATS অন্যান্য সফ্টওয়্যার ডেভেলপমেন্ট পরিবেশে উপলব্ধ ব্যাপক পরীক্ষার বৈশিষ্ট্যগুলি প্রদান করে৷
 

 স্বীকৃতি:BATS পরীক্ষায় আমাকে পরিচয় করিয়ে দেওয়ার জন্য আমি ড্যারিন মানের কাছে ঋণী৷