সিস্টেম অ্যাডমিনিস্ট্রেটরদের জন্য একটি শক্তিশালী ব্যাশ স্ক্রিপ্ট টেমপ্লেট তৈরি করা

এই সিরিজের প্রথম আর্টিকেলে, আপনি একটি খুব ছোট, এক-লাইনের ব্যাশ স্ক্রিপ্ট তৈরি করেছিলেন এবং শেল স্ক্রিপ্ট তৈরি করার কারণগুলো এক্সপ্লোর করেছিলেন এবং কেন সেগুলো কম্পাইলড প্রোগ্রামের চেয়ে সিস্টেম অ্যাডমিনের জন্য সবচেয়ে এফিশিয়েন্ট অপশন সেটি।

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

কেন একটি টেমপ্লেট তৈরি করবেন?

অটোমেশনের সাধারণ মত, টেমপ্লেট তৈরি করার পেছনে ধারণা হল "লেজি সিস্টেম অ্যাডমিন" হওয়া। একটি টেমপ্লেটে বেসিক কম্পোনেন্ট থাকে যা আপনি আপনার সব স্ক্রিপ্টে চান। এটি সময় বাঁচায় সেসব কম্পোনেন্ট প্রতিটি নতুন স্ক্রিপ্টে যোগ করার চেয়ে এবং একটি নতুন স্ক্রিপ্ট শুরু করা সহজ করে দেয়।

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

आवश्यकতা

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

এই ব্যাশ টেমপ্লেটের রিকোয়ারমেন্টগুলো খুব সহজ:

একটি টেমপ্লেট তৈরি করুন যা ভবিষ্যতের ব্যাশ প্রোগ্রামিং প্রজেক্টের জন্য শুরুর বিন্দু হিসেবে ব্যবহার করা যাবে।
টেমপ্লেটটি স্ট্যান্ডার্ড ব্যাশ প্রোগ্রামিং প্র্যাকটিস ফলো করা উচিত।
এতে অবশ্যই অন্তর্ভুক্ত থাকতে হবে:
- একটি হেডিং সেকশন যেটি প্রোগ্রামের ফাংশন বর্ণনা করতে এবং একটি চেঞ্জলগ রাখতে ব্যবহার করা যাবে
- একটি লাইসেন্সিং স্টেটমেন্ট
- ফাংশনদের জন্য একটি সেকশন
- একটি Help ফাংশন
- প্রোগ্রাম ইউজার রুট কিনা টেস্ট করার একটি ফাংশন
- কমান্ড-লাইন অপশন ইভ্যালুয়েট করার একটি মেথড

বেসিক স্ট্রাকচার

একটি বেসিক ব্যাশ স্ক্রিপ্টের তিনটি সেকশন থাকে। ব্যাশ সেকশন ডিলাইনেট করার কোনো উপায় দেয় না, কিন্তু সেকশনগুলোর মধ্যে বাউন্ডারিগুলো ইমপ্লিসিট।

সব স্ক্রিপ্ট অবশ্যই শব্যাং (#!) দিয়ে শুরু হতে হবে, এবং এটি যেকোনো ব্যাশ প্রোগ্রামের প্রথম লাইন হতে হবে।
ফাংশন সেকশন অবশ্যই শব্যাং-এর পরে এবং প্রোগ্রামের বডির আগে শুরু হতে হবে। সবকিছু ডকুমেন্ট করার আমার আগ্রহের অংশ হিসেবে, আমি প্রতিটি ফাংশনের আগে একটি কমেন্ট রাখি যেটি সংক্ষিপ্তে বর্ণনা করে সেটি কী করার জন্য ইনটেন্ডেড। আমি ফাংশনের ভেতরেও কমেন্ট রাখি আরও ইলাবোরেট করার জন্য। ছোট, সহজ প্রোগ্রামগুলোর ফাংশন দরকার নাও হতে পারে।
প্রোগ্রামের মূল অংশ ফাংশন সেকশনের পরে আসে। এটি একটি একক ব্যাশ স্টেটমেন্ট হতে পারে বা হাজার হাজার লাইন কোড। আমার এক প্রোগ্রামে ২০০ লাইনেরও বেশি কোড আছে, কমেন্ট কাউন্ট ছাড়া। সেই প্রোগ্রামে ৬০০ লাইনেরও বেশি কমেন্ট লাইন আছে।

এটিই সব—যেকোনো ব্যাশ প্রোগ্রামের স্ট্রাকচারে শুধু তিনটি সেকশন।

লিডিং কমেন্টস

আমি সবসময় এর চেয়ে বেশি যোগ করি বিভিন্ন কারণ থেকে। প্রথম, আমি শব্যাং-এর অবিলম্বে কয়েকটি কমেন্ট সেকশন যোগ করি। এই কমেন্ট সেকশনগুলো অপশনাল, কিন্তু আমি সেগুলো খুব هيل্পফুল পাই।

প্রথম কমেন্ট সেকশন হল প্রোগ্রামের নাম এবং বিবরণ এবং একটি চেঞ্জ হিস্টরি। আমি IBM-এ কাজ করার সময় এই ফরম্যাট শিখলাম, এবং এটি প্রোগ্রামের লং-টার্ম ডেভেলপমেন্ট এবং এতে প্রয়োগ করা যেকোনো ফিক্স ডকুমেন্ট করার একটি মেথড প্রদান করে। এটি আপনার প্রোগ্রাম ডকুমেন্ট করার একটি গুরুত্বপূর্ণ শুরু।

দ্বিতীয় কমেন্ট সেকশন হল একটি কপিরাইট এবং লাইসেন্স স্টেটমেন্ট। আমি GPLv2 ব্যবহার করি, এবং GPLv2-র অধীনে লাইসেন্সড প্রোগ্রামের জন্য এটি একটি স্ট্যান্ডার্ড স্টেটমেন্ট মনে হয়। আপনি যদি অন্য ওপেন সোর্স লাইসেন্স ব্যবহার করেন, সেটি ঠিক আছে, কিন্তু আমি কোডে একটি এক্সপ্লিসিট স্টেটমেন্ট যোগ করার পরামর্শ দিই যাতে লাইসেন্সিং সম্পর্কে যেকোনো সম্ভাব্য কনফিউশন দূর হয়। Scott Peterson-এর আর্টিকেল The source code is the license এর পেছনে যুক্তিটি বুঝতে সাহায্য করে।

তাহলে এখন স্ক্রিপ্টটি এরকম দেখে:

#!/bin/bash
 ################################################################################
 # scriptTemplate #
 # #
 # Use this template as the beginning of a new program. Place a short #
 # description of the script here. #
 # #
 # Change History #
 # 11/11/2019 David Both Original code. This is a template for creating #
 # new Bash shell scripts. #
 # Add new history entries as needed. #
 # #
 # #
 ################################################################################
 ################################################################################
 ################################################################################
 # #
 # Copyright (C) 2007, 2019 David Both #
 # LinuxGeek46@both.org #
 # #
 # This program is free software; you can redistribute it and/or modify #
 # it under the terms of the GNU General Public License as published by #
 # the Free Software Foundation; either version 2 of the License, or #
 # (at your option) any later version. #
 # #
 # This program is distributed in the hope that it will be useful, #
 # but WITHOUT ANY WARRANTY; without even the implied warranty of #
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #
 # GNU General Public License for more details. #
 # #
 # You should have received a copy of the GNU General Public License #
 # along with this program; if not, write to the Free Software #
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA #
 # #
 ################################################################################
 ################################################################################
 ################################################################################
 
 echo "hello world!"

রিভাইজড প্রোগ্রামটি রান করুন যেন নিশ্চিত হয় সেটি এখনও এক্সপেক্টেডভাবে কাজ করছে।

টেস্টিং সম্পর্কে

এখন টেস্টিং সম্পর্কে কথা বলার সঠিক সময়।

"There is always one more bug."

— Lubarsky's Law of Cybernetic Entomology

Lubarsky—কে কেউ যেনে—Sundar। আপনি কখনো আপনার কোডে সকল বাগ খুঁজে বের করতে পারবেন না। আমি যত বাগ খুঁজি পাই, সবসময় আরও একটি ক্রপ আপ করে, সাধারণত খুব অনুপযোগী সময়ে।

টেস্টিং শুধু প্রোগ্রাম সম্পর্কে নয়। এটিও হল ভেরিফিকেশন যে সমস্যাগুলো—হার্ডওয়্যার, সফটওয়্যার, বা যেসব উদ্ভাবনী উপায়ে ব্যবহারকারীরা জিনিসগুলো ভাঙতে পারে সেগুলো—যেগুলো রেজল্ভ করা সাপPOSED ছিল সেগুলো আসলে রেজল্ভ হয়েছে কিনা। ততো’importantly, টেস্টিং হল নিশ্চিত করা যে কোডটি ব্যবহার করা সহজ এবং ইন্টারফেস ইউজারকে সেন্সIBLE লাগে।

শেল স্ক্রিপ্ট লেখা এবং টেস্ট করার সময় একটি ভালো ডিফাইনড প্রসেস ফলো করলে কনসিস্টেন্ট এবং হাই-কোয়ালিটি রেজাল্টে কন্ট্রিবিউট করতে পারে। আমার প্রসেস সিম্পল:

একটি সিম্পল টেস্ট প্ল্যান তৈরি করুন।
ডেভেলপমেন্টের শুরু থেকেই টেস্টিং শুরু করুন।
কোড কমপ্লিট হলে একটি ফাইনাল টেস্ট করুন।
প্রোডাকশনে যান এবং আরও টেস্ট করুন।

টেস্ট প্ল্যান

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

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

গুগল ব্যবহার করে আমি যেসব স্যাম্পল টেস্ট প্ল্যান ডকুমেন্ট খুঁজে পেলাম সেগুলো কমপ্লেক্স এবং বড় অর্গানাইজেশনের জন্য ইনটেন্ডেড যাদের ভেরি ফর্মাল ডেভেলপমেন্ট এবং টেস্ট প্রসেস আছে। যদিও সেসব টেস্ট প্ল্যান "test" তাদের জব টাইটেলে থাকা লোকেদের জন্য ভালো হবে, সেগুলো সিস্টেম অ্যাডমিনদের আরও কাотиক এবং টাইম-ডিপেন্ডেন্ট ওয়ার্কিং কন্ডিশনে খুব ভালো অ্যাপ্লাই হয় না। অধিকাংশ জবের দিকের মত, সিস্টেম অ্যাডমিনদের ক্রিয়েটিভ হতে হয়। তাই এখানে আপনার টেস্ট প্ল্যানে অন্তর্ভুক্ত করার জন্য কিছু বিষয়ের একটি সংক্ষিপ্ত তালিকা। আপনার চাহিদা অনুযায়ী এটিকে মডিফাই করুন:

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

এই লিস্ট আপনার টেস্ট প্ল্যান তৈরি করার কিছু আইডিয়া দেবে। অধিকাংশ সিস্টেম অ্যাডমিনদের জন্য এটিকে সিম্পল এবং ফेयरলি ইনফরমেল রাখা উচিত।

দ্রুত টেস্ট করুন—বারবার টেস্ট করুন

আমি সবসময় আমার শেল স্ক্রিপ্ট টেস্ট করা শুরু করি যতক্ষণ না আমি প্রথম এক্সিকিউটেবল অংশটি কমপ্লিট করি। এটি সত্য চাড়া একটি শর্ট কমান্ড-লাইন প্রোগ্রাম লিখি বা একটি স্ক্রিপ্ট যা একটি এক্সিকিউটেবল ফাইল।

আমি সাধারণত নতুন প্রোগ্রাম তৈরি শুরু করি শেল স্ক্রিপ্ট টেমপ্লেট দিয়ে। আমি Help ফাংশনের কোড লিখি এবং টেস্ট করি। এটি সাধারণত প্রসেসের একটি তুচ্ছ অংশ, কিন্তু এটি আমাকে শুরু করতে সাহায্য করে এবং নিশ্চিত করে যে টেমপ্লেটের জিনিসগুলো আউটসেট-এ ঠিকঠাক কাজ করছে। এই পয়েন্টে, টেমপ্লেট পোर्शनগুলোর সমস্যা ফিক্স করা বা এটিকে মডিফাই করা যাতে সেটি দরকার মিট করে যা স্ট্যান্ডার্ড টেমপ্লেটে নেই, সহজ।

একবার টেমপ্লেট এবং Help ফাংশন কাজ করলে, আমি প্রোগ্রামের বডি তৈরি করতে যাই প্রোগ্রামিং স্টেপের কমেন্ট যোগ করে যেগুলো প্রোগ্রাম স্পেসিফিকেশনের রিকোয়ারমেন্ট মিট করতে হবে। এখন আমি প্রতিটি কমেন্টে স্টেট করা রিকোয়ারমেন্ট মিট করার জন্য কোড যোগ করি। এই কোডটি হয়তো ভেরিয়েবল যোগ করতে হবে যা টেমপ্লেটের সেকশনে ইনিশিয়ালাইজ করা হয়—যেটি এখন একটি শেল স্ক্রিপ্ট হয়ে উঠছে।

এখানেই টেস্টিং শুধু ডেটা ইনপুট করে রেজাল্ট ভেরিফাই করার চেয়ে বেশি। এটিতে একটু একস্ট্রা ওয়ার্ক লাগে। কখনও কখনও আমি একটি কমান্ড যোগ করি যা সিম্পলি আমি লিখা কোডের ইন্টারমিডিয়েট রেজাল্ট প্রিন্ট করে এবং ভেরিফাই করি। আরও কমপ্লেক্স স্ক্রিপ্টের জন্য, আমি একটি -t অপশন যোগ করি "test mode" এর জন্য। এই কেসে, ইন্টারন্যাল টেস্ট কোড শুধু এক্সিকিউট হয় যখন -t অপশন কমান্ড লাইনে লিখা হয়।

ফাইনাল টেস্টিং

কোড কমপ্লিট হলে, আমি ফিরে যাই সব ফিচার এবং ফাংশন একটি কমপ্লিট টেস্ট করার জন্য জানানো ইনপুট ব্যবহার করে স্পেসিফিক আউটপুট প্রডিউস করতে। আমি কিছু র‍্যান্ডম ইনপুটও টেস্ট করি যেন দেখতে পাই প্রোগ্রামটি অনপ্রত্যাশিত ইনপুট হ্যান্ডেল করতে পারে কিনা।

ফাইনাল টেস্টিং ইনটেন্ডেড যেন ভেরিফাই করা হয় প্রোগ্রামটি এসেনশিয়ালি ইনটেন্ডেডভাবে ফাংশন করছে। ফাইনাল টেস্টের বড় অংশ হল নিশ্চিত করা যে ডেভেলপমেন্ট সাইকলের আগে যেসব ফাংশন কাজ করতো সেগুলো পরবর্তীতে যোগ করা বা পরিবর্তন করা কোড দ্বারা ব্রেক হয়নি।

যদি আপনি স্ক্রিপ্টটি টেস্ট করেন যেহেতু আপনি নতুন কোড যোগ করছেন, আপনি মনে করতে পারেন ফাইনাল টেস্টে কোনো সারপ্রাইজ হওয়া উচিত নয়। ভুল! ফাইনাল টেস্টিং-এ সবসময় সারপ্রাইজ থাকে। সবসময়। সেসব সারপ্রাইজ এক্সপেক্ট করুন, এবং সেসব ফিক্স করার জন্য সময় ব্যয় করার জন্য প্রস্তুত रहুন। যদি ফাইনাল টেস্টিং-এ কখনো কোনো বাগ ডিসকভার না হত, ফাইনাল টেস্ট করার পয়েন্টই থাকত না, কি না?

প্রোডাকশনে টেস্টিং

হু—কী?

"Not until a program has been in production for at least six months will the most harmful error be discovered."

— Troutman's Programming Postulates

হ্যাঁ, প্রোডাকশনে টেস্টিং এখন নরমাল এবং ডিজায়ারেবল মনে করা হয়। নিজে একজন টেস্টার হয়ে, এটি মেনে যেতে পারছি। "But wait! That's dangerous," আপনি বলবেন। আমার এক্সপেরিয়েন্সে এটি একটি ডেডিকেটেড টেস্ট এনভায়রনমেন্টে এক্সটেনসিভ এবং রিগরস টেস্টিং-এর চেয়ে বেশি ডেঞ্জারাস নয়। কিছু কেসে, কোনো চয়েস নেই কারণ টেস্ট এনভায়রনমেন্ট নেই—শুধু প্রোডাকশন।

সিস্টেম অ্যাডমিনরা নতুন বা রিভাইজড স্ক্রিপ্ট প্রোডাকশনে টেস্ট করার প্রয়োজনীয়তায় অজানা নন। যেকোনো সময় একটি স্ক্রিপ্ট প্রোডাকশনে মুভ করা হয়, সেটি চূড়ান্ত টেস্ট হয়ে যায়। প্রোডাকশন এনভায়রনমেন্ট সেই টেস্টের সবচেয়ে ক্রিটিক্যাল অংশ। কোনো কিছু যা টেস্টাররা টেস্ট এনভায়রনমেন্টে ড্রিম আপ করতে পারে সেটি সত্যিকারের প্রোডাকশন এনভায়রনমেন্টকে ফুলি রেপ্লিকেট করতে পারে না।

প্রোডাকশনে টেস্টিংয়ের খ্যাতিঅর্জিত নতুন প্র্যাকটিস শুধু সিস্টেম অ্যাডমিনরা সবসময় যেটি জানতেন সেটির স্বীকৃতি। সেরা টেস্ট হল প্রোডাকশন—সত্যিকারের টেস্ট না হোক।

ফাজি টেস্টিং

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

ফাজি টেস্টিং কিছুটা সেরকম যখন আমার ছেলে এক মিনিটে র‍্যান্ডম ইনপুট দিয়ে একটি গেমের কোড ভাঙলো। সেটি আমার তার জন্য গেম লিখার চেষ্টা প্রায় শেষ করলো।

বেশিরভাগ টেস্ট প্ল্যান খুব স্পেসিফিক ইনপুট ব্যবহার করে যা একটি স্পেসিফিক রেজাল্ট বা আউটপুট জেনারেট করে। রিগার্ডলেস অফ ইফ দ টেস্ট ডিফাইনস আ পজিটিভ অর নেগেটিভ আউটকাম আজ অ সাক্সেস, ইট ইজ স্টিল কন্ট্রোলড, অ্যান্ড দ ইনপুটস অন্ড রেজাল্টস आर স্পেসিফাইড অন্ড এক্সপেক্টেড, সাচ আজ অ স্পেসিফিক এরর মেসেজ ফর অ স্পেসিফিক ফেইল মোড।

ফাজি টেস্টিং হল র‍্যান্ডমনেসের সাথে ডিল করা টেস্টের সকল দিকে, যেন: শুরুর কন্ডিশন, খুব র‍্যান্ডম এবং অনপ্রত্যাশিত ইনপুট, অপশন সিলেক্টের র‍্যান্ডম কম্বিনেশন, লো মেমরি, অন্য প্রোগ্রামের সাথে হাই সিপিইউ কনটেনশন, টেস্ট আন্ডার প্রোগ্রামের মাল্টিপল ইনস্ট্যান্স, এবং অন্য যেকোনো র‍্যান্ডম কন্ডিশন যা আপনি টেস্টে প্রয়োগ করতে পারেন।

আমি শুরু থেকে কিছু ফাজি টেস্টিং করার চেষ্টা করি। যদি ব্যাশ স্ক্রিপ্ট তার খুব আধুনিক স্টেজে সিগনিফিক্যান্ট র‍্যান্ডমনেস ডিল করতে না পারে, তবে এটি কোড আরো যোগ করার সাথে সাথে ভালো হবena। এটি সমস্যা ধরতে এবং সেগুলো ফিক্স করার চমৎকার সময় যতক্ষণ কোড রিলেটিভলি সিম্পল। প্রতিটি স্টেজে একটু ফাজি টেস্টিংও প্রয়োজন সমস্যা লোকেট করার জন্য যেন সেগুলো আরও কোড দ্বারা মাস্কড হয়ে যাওয়ার আগে।

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

আগামী আকর্ষণের প্রিভিউ

এই আর্টিকেলটি টেমপ্লেট তৈরি করার দিক থেকে কিছুটা অর্জন করল, কিন্তু অধিকাংশ টেস্টিং নিয়ে কথা বলল। এর কারণ টেস্টিং যেকোনো ধরনের প্রোগ্রাম তৈরির একটি ক্রিটিক্যাল অংশ। এই সিরিজের পরবর্তী আর্টিকেলে, আপনি আপনার ব্যাশ স্ক্রিপ্ট টেমপ্লেটে একটি বেসিক Help ফাংশন এবং -h এর মত অপশন ডিটেক্ট এবং একট করতে কিছু কোড যোগ করবেন।

রিসোর্স

How to program with Bash: Syntax and tools
How to program with Bash: Logical operators and shell expansions
How to program with Bash: Loops

এই আর্টিকেল সিরিজটি আংশিকভাবে ডেভিড বথের তিন-খণ্ডের লিনাক্স সেলফ-স্টাডি কোর্স, Using and Administering Linux—Zero to SysAdmin-এর ভলিউম ২, অধ্যায় ১০-র ওপর ভিত্তি করে।