কি পরীক্ষা করতে হবে, টেস্টিং কিসের বিপরীতে, সমস্ত দলের জন্য একটি গুরুত্বপূর্ণ প্রশ্ন। পরীক্ষা শেষ করার একটি উপায়, এবং আপনার কোডবেসের বিভিন্ন অংশের পরীক্ষাকে কীভাবে অগ্রাধিকার দেওয়া যায় তা বেছে নেওয়া কঠিন হতে পারে।
আপনার কোডবেস এবং আপনার দলের লক্ষ্যগুলির উপর ভিত্তি করে অগ্রাধিকার দেওয়ার সর্বোত্তম উপায়। এটা মনে রাখা গুরুত্বপূর্ণ, যদিও, অনেকগুলি ছোট পরীক্ষা (পরীক্ষা পিরামিডের নীচে, যেমন ইউনিট টেস্টের মতো) লিখতে অল্প সময় এবং ব্যান্ডউইথ লাগে, যেগুলিতে প্রচুর কোড কভারেজ রয়েছে, সেগুলি অগত্যা সামগ্রিকভাবে হ্রাস করে না আপনার প্রকল্পের জন্য ঝুঁকি।
আপনি আপনার অ্যাপ্লিকেশন, ওয়েবসাইট বা লাইব্রেরির প্রাথমিক ব্যবহারের ক্ষেত্রে চিন্তা করে প্রথমে কী পরীক্ষা করবেন তা চয়ন করতে পারেন। এটি আপনার সাইটের গুরুত্বপূর্ণ অংশগুলির উপর উপাদান পরীক্ষা লেখার মাধ্যমে হতে পারে, মূল উপাদান যা আপনার ব্যবহারকারীর অভিজ্ঞতাকে ভিত্তি করে। উদাহরণস্বরূপ, এমন একটি সাইটের বিকাশকারী যা ব্যবহারকারীদের টাইমসিরিজ ডেটা আপলোড এবং পরিচালনা করার অনুমতি দেয় তাদের কল্পনা করা উচিত এবং পরীক্ষা করা উচিত যে কোনও ব্যবহারকারী সেই কাজগুলি কীভাবে সম্পাদন করতে পারে।
অগ্রাধিকারের আরেকটি পদ্ধতির মধ্যে সবচেয়ে বেশি তথ্য লাভ করা জড়িত। যদি আপনার কোডবেসের একটি "বিপজ্জনক", উত্তরাধিকার, বা খারাপভাবে লেখা লোড-বহনকারী অংশ থাকে যা আপনার দলের কেউ কাজ করতে পছন্দ করে না, তাহলে আপনি উপেক্ষা করার আগে এটির আচরণকে আরও সামঞ্জস্যপূর্ণ করতে এটির চারপাশে পরীক্ষা তৈরি করা কার্যকর হতে পারে এটি আরও, বা এটি ঠিক করতে রিফ্যাক্টর করুন। এটিকে এমন একটি বিল্ডিংয়ের জন্য ভারা হিসাবে ভাবুন যা ইতিমধ্যেই নিন্দা করা হয়েছে, কিন্তু এখনও আপনার ডেটা সেন্টারে রয়েছে।
মাত্রিকতা
আমরা একটি টেস্টিং পিরামিড বা অন্য একটি টেস্টিং আকৃতির ধারণা প্রবর্তন করেছি, তবে এগুলি শুধুমাত্র পরীক্ষার একটি একক মাত্রা উপস্থাপন করে: একটি লাইন যা ছোট সুযোগ থেকে যায়, সাধারণ ইউনিট পরীক্ষা থেকে জটিল, বিস্তৃত পরীক্ষা- ইউনিট পরীক্ষা বনাম ইন্টিগ্রেশন টেস্ট বনাম এন্ড-টু-এন্ড টেস্ট।
যাইহোক, সম্ভাব্য পরীক্ষার ধরণের কিছু দীর্ঘ তালিকা জটিলতার স্তরের প্রতিনিধিত্ব করে না, বরং পরীক্ষার লক্ষ্য বা কৌশলগুলিকে উপস্থাপন করে। উদাহরণ স্বরূপ, ধোঁয়া পরীক্ষাগুলি হল পরীক্ষার একটি ভিন্ন শ্রেণী যা নিজেরাই একক, শেষ থেকে শেষ, বা অন্যান্য পরীক্ষা হতে পারে, কিন্তু পরীক্ষকদের সামগ্রিক আস্থা দেওয়ার উদ্দেশ্যে করা হয় যে পরীক্ষা করা হচ্ছে সেই প্রকল্পটি একটি বৈধ অবস্থায় রয়েছে। ভিজ্যুয়াল টেস্টিং একটি ছোট উপাদান বা সম্পূর্ণরূপে আপনার সাইটে প্রয়োগ করা কার্যকর হতে পারে।
আপনার কোডবেসের অনন্য প্রয়োজনীয়তা থাকবে। উদাহরণস্বরূপ, আপনার কোডবেসে একটি একক বৈশিষ্ট্যের সাথে সারিবদ্ধ করা অনেক বেশি গুরুত্বপূর্ণ হতে পারে, এটি সঠিকভাবে কাজ করে তা নিশ্চিত করার জন্য বিভিন্ন ধরনের পরীক্ষা লিখতে পারে। একটি নতুন বৈশিষ্ট্য যা পরীক্ষার প্রয়োজন হয় তা খুব কমই একটি একক উপাদান, কার্য বা পদ্ধতি এবং আপনার প্রকল্পে এর প্রভাব ব্যাপকভাবে এবং বিভিন্ন স্কেলে বিতরণ করা হতে পারে।
আপনার পরীক্ষার অগ্রাধিকারগুলি আপনার ব্যবসার চাহিদার উপরও নির্ভর করতে পারে। একটি অনন্য অ্যালগরিদম সঠিকভাবে কাজ করে কিনা তা নিশ্চিত করার জন্য উচ্চ প্রযুক্তিগত সিস্টেমগুলির জটিল ইউনিট পরীক্ষার প্রয়োজন হতে পারে, যেখানে জটিল স্পর্শ ইনপুটগুলি সঠিক প্রতিক্রিয়া তৈরি করে তা নিশ্চিত করার জন্য অত্যন্ত ইন্টারেক্টিভ সরঞ্জামগুলি ভিজ্যুয়াল টেস্টিং বা এন্ড-টু-এন্ড টেস্টিংয়ের উপর ফোকাস করতে পারে।
পরীক্ষার জন্য আপনার পদ্ধতি
আপনার কোডবেসের ব্যবহারের ক্ষেত্রে তাদের স্কেল নির্বিশেষে পরীক্ষা করার উপর ফোকাস করার চেষ্টা করুন। কল্পনা করুন যে ব্যবহারকারী কীভাবে আপনার প্রকল্পের যেকোনো অংশ ব্যবহার করতে পারে—এটি একটি একক উপাদান, বা একটি নিম্ন-স্তরের ফাংশন, বা একটি উচ্চ-স্তরের এন্ড-টু-এন্ড ব্যবহারের ক্ষেত্রে প্রতিনিধিত্ব করতে পারে। (এটি যেকোনো স্কেলে আপনার বিমূর্ততার ঘাটতিগুলিও প্রকাশ করতে পারে, যদি আপনি দেখেন যে আপনার পরীক্ষাটি পরীক্ষার অধীনে কোডের সাথে সুন্দরভাবে ইন্টারঅ্যাক্ট করতে পারে না।)
এটি গুরুত্বপূর্ণ যে প্রতিটি পরীক্ষার ক্ষেত্রে একটি স্পষ্টভাবে সংজ্ঞায়িত লক্ষ্য রয়েছে। আপনার নন-টেস্ট কোডের মতোই বড় "ক্যাচ-অল" পরীক্ষাগুলি অবাস্তব হতে পারে।
পরীক্ষা-চালিত উন্নয়নের উপর একটি সরাইয়া
টেস্ট-চালিত উন্নয়ন (TDD) হল পরীক্ষার জন্য একটি অনন্য পদ্ধতি—অর্থোগোনাল থেকে স্কেল বা টাইপস- যাতে এটি লিখিত পরীক্ষাগুলিকে অন্তর্ভুক্ত করে যা অন্তত প্রথমে ব্যর্থ হওয়ার উদ্দেশ্যে করা হয়। এটি ম্যানুয়াল এবং স্বয়ংক্রিয় পরীক্ষা উভয় ক্ষেত্রেই প্রযোজ্য হতে পারে: আপনি যে লক্ষ্যগুলি অর্জন করতে চান তা বর্ণনা করুন, আপনার বর্তমান সমাধান বা কোডে কী অনুপস্থিত তা খুঁজে বের করুন এবং একটি সমাধানের দিকে নির্দেশিকা হিসাবে ব্যর্থ পরীক্ষাটি ব্যবহার করুন৷
অবশ্যই, আপনি এটি নির্মাণ শুরু করার আগেও একটি অনুমানমূলক অ্যাপ্লিকেশন বা উপাদানে প্রতিটি সম্ভাব্য দৃশ্য পরীক্ষা করা দরকারী নয়। TDD এর জায়গা আছে, এবং এটি সহায়ক হতে পারে কারণ আপনার কোডবেস আরও জটিল হয়ে ওঠে।
বাগ ঠিক করার সময় টিডিডিও ভালো অনুশীলন। যদি আপনি একটি বাগ জন্য প্রজনন ক্ষেত্রে কোডিফাই করতে পারেন, এটি একটি স্বয়ংক্রিয় পরীক্ষা করা যেতে পারে যা প্রাথমিকভাবে ব্যর্থ হবে। আপনি যখন বাগটি ঠিক করেছেন, পরীক্ষাটি পাস হয়, আপনাকে ম্যানুয়াল নিশ্চিতকরণ ছাড়াই সমাধানটি সফল হয়েছে কিনা তা নির্ধারণ করতে দেয়৷
অস্বচ্ছ বনাম পরিষ্কার বাক্স
এটি আপনার সিস্টেমের যেকোনো অংশের পরীক্ষা করার পদ্ধতিকে নির্দেশ করে। যদি এটি অস্বচ্ছ হয়, আপনি ভিতরে দেখতে পাবেন না, উদাহরণস্বরূপ, একটি ক্লাসের পাবলিক ইন্টারফেস ব্যবহার করার সময়, এর অভ্যন্তরীণ পরিদর্শন করার পরিবর্তে।
আপনার কাছে না করার নির্দিষ্ট কারণ না থাকলে, অস্বচ্ছ বক্স পরীক্ষা দিয়ে শুরু করা ভাল যাতে আপনি কীভাবে আপনার উপাদানগুলি ব্যবহার করা হয় তার উপর ভিত্তি করে পরীক্ষাগুলি ডিজাইন করতে পারেন এবং তাদের অভ্যন্তরীণগুলি কীভাবে কাজ করছে তাতে বিভ্রান্ত হবেন না। আপনি যদি শুধুমাত্র একটি কোড পাথের "পাবলিক" ইন্টারফেসের উপর নির্ভর করেন (অগত্যা আপনার ব্যবহারকারীদের কাছে সর্বজনীন নয়, তবে আপনার কোডের অন্যান্য অংশের জন্য), আপনি সেই কোডটি রিফ্যাক্টর করতে এবং উন্নত করতে মুক্ত হন এই জেনে যে আপনার পরীক্ষা কোনো পরিবর্তন শনাক্ত করবে।
আপনার "ক্লিয়ার বক্স" কোডটিকে আরও অস্বচ্ছ করতে রূপান্তর করার একটি উপায় হল কোডের নির্ভরতাগুলির জন্য বিমূর্তকরণের মতো কনফিগারযোগ্য উপাদানগুলি প্রবর্তন করা, অথবা সেই অবস্থাটিকে অন্যান্য সিস্টেমের সাথে শক্তভাবে সংযুক্ত করার পরিবর্তে, অবস্থা পর্যবেক্ষণ করার জন্য কলব্যাকগুলি প্রবর্তন করা৷ এটি আপনার কোডকে আরও ডিকপল করে তোলে এবং আপনাকে 'পরীক্ষা' সংস্করণ সরবরাহ করতে দেয়। বিকল্পভাবে, আপনি উপহাস করতে পারেন যেখানে আপনার কোড অন্যান্য সিস্টেমের সাথে ইন্টারঅ্যাক্ট করে।