কতটা পরীক্ষা খুব বেশি?

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

অন্যদিকে, আপনি এইমাত্র লিখেছেন যেটি একটি ক্ষুদ্র বৈশিষ্ট্য পাঠানোর জন্য 200টি পরীক্ষার মতো মনে হচ্ছে৷ 100% পরীক্ষা কভারেজ আঘাত করার জন্য আপনাকে ক্রমাগত ইতিমধ্যে-কাজ করা কোড পুনরায় ডিজাইন করতে হবে। আপনার সেরা-পরীক্ষিত কোড কোনোভাবে কম হচ্ছে এমন অনুভূতি আপনি কাঁপতে পারবেন না পঠনযোগ্য এবং সবথেকে খারাপ, আপনি আপনার অ্যাপটি নষ্ট হতে শুরু করেছেন।

একটা মাঝামাঝি জায়গা থাকতে হবে। তাহলে সঠিক পরিমাণে কত পরীক্ষা করা হয়?

এটি দুর্দান্ত হবে যদি আপনি একটি নিয়ম হিসাবে ব্যবহার করতে পারেন এমন একটি সুন্দর রাউন্ড নম্বর থাকে:অ্যাপ কোডের চেয়ে দ্বিগুণ পরীক্ষার কোড, হতে পারে, বা 95% পরীক্ষার কভারেজ। কিন্তু এমনকি "95% পরীক্ষার কভারেজ" বলাটাও অস্পষ্ট৷৷

কভারেজ একটি সূচক হতে পারে ভাল-পরীক্ষিত কোডের, কিন্তু এটি একটি গ্যারান্টি নয় ভাল-পরীক্ষিত কোডের। আমার কাছে 100%-আচ্ছন্ন অ্যাপ আছে যেগুলোতে 85% কভারেজের অ্যাপের চেয়ে বেশি বাগ রয়েছে।

সুতরাং, পরীক্ষার সঠিক পরিমাণ একটি সংখ্যা সম্পর্কে হতে পারে না। পরিবর্তে, এটি কিছু অস্পষ্ট এবং সংজ্ঞায়িত করা কঠিন। এটি দক্ষভাবে পরীক্ষা করার বিষয়ে .

দক্ষ পরীক্ষা

দক্ষতার সাথে পরীক্ষা করা হল সর্বনিম্ন কাজের জন্য সর্বাধিক সুবিধা পাওয়ার বিষয়ে। দারুন শোনাচ্ছে, তাই না?

কিন্তু এমন অনেক কিছু আছে যা আরও দক্ষতার সাথে পরীক্ষায় যায়। সুতরাং এটি বিশেষভাবে তিনটি জিনিস সম্পর্কে চিন্তা করতে সাহায্য করে:আকার, বিচ্ছিন্নতা এবং ফোকাস৷

আকার

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

কিন্তু ইন্টিগ্রেশন পরীক্ষা ধীর। তারা দীর্ঘ এবং অগোছালো হতে পারে। এবং আপনি যদি আপনার সিস্টেমের একটি ছোট অংশ পুঙ্খানুপুঙ্খভাবে পরীক্ষা করতে চান তবে তারা অনেক বেশি ওভারহেড যোগ করে।

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

কিন্তু তারা জাল হতে পারে. শুধুমাত্র একটি ইউনিট পরীক্ষার ভিতরে কিছু কাজ করে তার মানে এই নয় যে এটি বাস্তব জগতেও কাজ করবে। (বিশেষ করে যদি আপনি অনেক উপহাস করছেন)।

তাহলে আপনি কীভাবে তাদের ভারসাম্য রাখবেন?

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

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

আপনি "টেস্ট পিরামিড" নামে এই ধারণাটি শুনতে পাবেন৷৷ এটি কয়েকটি ইন্টিগ্রেশন পরীক্ষা, অনেক ইউনিট পরীক্ষার একটি বেসের উপরে বসে। এবং আপনি যদি এটি সম্পর্কে আরও জানতে চান, তাহলে আমার বইয়ের তৃতীয় অধ্যায় দেখুন, প্র্যাকটিসিং রেলস৷

বিচ্ছিন্নতা

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

বলুন আপনার কাছে এমন একটি বস্তু আছে যা কয়েকটি ভিন্ন অবস্থায় থাকতে পারে:

case user.type
when :admin
  message = admin_message
when :user
  message = user_message
when :author
  message = author_message
else
  message = anonymous_message
end

if user.preferred_notification_method = :email
  send_email(message)
elsif user.preferred_notification_method = :text
  send_text_message(message)
else
  queue_notification(message) 
end

আপনি যদি এখানে প্রতিটি সম্ভাব্য পথ পরীক্ষা করতে চান, আপনার পরীক্ষা করার জন্য 12টি ভিন্ন পরিস্থিতি থাকবে:

1. ব্যবহারকারী হল একজন প্রশাসক, preferred_notification_method ইমেল হল
2. ব্যবহারকারী হল একজন প্রশাসক, preferred_notification_method এটি পাঠ্য
3. ব্যবহারকারী হল একজন প্রশাসক, preferred_notification_method হয় না
4. ব্যবহারকারী হল একজন ব্যবহারকারী, preferred_notification_method ইমেল হল
5. ব্যবহারকারী হল একজন ব্যবহারকারী, preferred_notification_method এটি পাঠ্য
6. ব্যবহারকারী হল একজন ব্যবহারকারী, preferred_notification_method হয় না
7. ব্যবহারকারী একজন লেখক, preferred_notification_method ইমেল হল
8. ব্যবহারকারী একজন লেখক, preferred_notification_method এটি পাঠ্য
9. ব্যবহারকারী একজন লেখক, preferred_notification_method হয় না
10. ব্যবহারকারী বেনামী, preferred_notification_method ইমেল হল
11. ব্যবহারকারী বেনামী, preferred_notification_method এটি পাঠ্য
12. ব্যবহারকারী বেনামী, preferred_notification_method হয় না

পরীক্ষা করার জন্য অনেকগুলি কেস রয়েছে কারণ "একটি বিজ্ঞপ্তি পদ্ধতির উপর ভিত্তি করে একটি বার্তা পাঠানো" এবং "ব্যবহারকারীর প্রকারের উপর ভিত্তি করে একটি বার্তা তৈরি করা" একসাথে আবদ্ধ। আপনি হয়ত৷ কম দিয়ে চেপে ধরতে সক্ষম হবেন, কিন্তু এটি স্পষ্ট নয় - এবং এটি কেবল বাগগুলির জন্য জিজ্ঞাসা করছে৷

কিন্তু আপনি যদি তাদের আলাদা করে ফেলেন তাহলে কি হবে?

message = get_message_based_on_user_type(user.type)

send_notification(message, user.preferred_notification_method)

এখন আপনি প্রতিটি অংশ আলাদাভাবে পরীক্ষা করতে পারেন৷৷

প্রথম অংশের জন্য, আপনি পরীক্ষা করতে পারেন যে প্রতিটি ধরনের ব্যবহারকারীর জন্য সঠিক বার্তাটি ফেরত দেওয়া হয়েছে।

দ্বিতীয় অংশের জন্য, আপনি পরীক্ষা করতে পারেন যে preferred_notification_method এর মানের উপর ভিত্তি করে একটি প্রদত্ত বার্তা সঠিকভাবে পাঠানো হয়েছে। .

এবং অবশেষে, আপনি পরীক্ষা করতে পারেন যে মূল পদ্ধতিটি do_stuff_based_on_user_type থেকে প্রত্যাবর্তিত বার্তাটি পাস করবে send_email_or_text বরাবর . তাই এখন, আপনার পরীক্ষা করার জন্য 8টি রাজ্য আছে:

1. ব্যবহারকারী একজন প্রশাসক
2. ব্যবহারকারী একজন ব্যবহারকারী
3. ব্যবহারকারী একজন লেখক
4. ব্যবহারকারী বেনামী
5. preferred_notification_method ইমেল হল
6. preferred_notification_method এটি পাঠ্য
7. preferred_notification_method হয় না
8. এবং অভিভাবক পদ্ধতির জন্য একটি পরীক্ষা

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

আপনি বিচ্ছিন্নতা এবং পাঠযোগ্যতার মধ্যে সর্বোত্তম ভারসাম্য খুঁজে পাওয়ার আগে এটি সময় এবং অনুশীলন করে। কিন্তু আপনি যদি সঠিক জায়গায় আপনার নির্ভরতা ভাঙেন, তাহলে আপনি অনেক কম পরীক্ষা দিয়ে যেতে পারবেন।

ফোকাস

আপনার অ্যাপটি ভালভাবে পরীক্ষা করা উচিত। কিন্তু এর মানে এই নয় যে আপনার অ্যাপের প্রতিটি অংশই পরীক্ষায় একই পরিমাণ মনোযোগের দাবি রাখে।

এমনকি যদি আপনি 100% পরীক্ষার কভারেজের লক্ষ্য রাখেন, তবুও আপনি সবকিছু পরীক্ষা করবেন না। আপনি সম্ভবত আপনার দৃষ্টিভঙ্গিতে পাঠ্যের প্রতিটি লাইন পরীক্ষা করবেন না, উদাহরণস্বরূপ, বা আপনি দশটির পরিবর্তে প্রতি পাঁচ সেকেন্ডে আপডেটের জন্য পোলিং করছেন৷

সেখানেই ফোকাস আসে৷ কম লেখা, আরও দরকারী পরীক্ষা৷৷ এবং একটি সচেতন সিদ্ধান্ত নিন যেখানে আপনি আপনার সময় কাটাতে পারেন।

ফোকাস হল আরেকটি জিনিস যা ঠিক করা কঠিন। এই কয়েকটি প্রশ্ন আমি নিজেকে জিজ্ঞাসা করি যা আমাকে সবচেয়ে গুরুত্বপূর্ণ পরীক্ষাগুলিতে মনোনিবেশ করতে সাহায্য করে:

• আমার অ্যাপের বাকি অংশের সাথে এটি কতটা আন্তঃসংযুক্ত? যদি এটি ভেঙ্গে যায় তবে এর সাথে আরও কত টুকরো পড়ে যাবে?

• এটা স্বাভাবিকভাবে পরিবর্তন হবে এটা কতটা সম্ভব? যদি আমার পরীক্ষা ব্যর্থ হয়, তাহলে কি এটি একটি বাগ বা কেউ UI-তে কিছু পাঠ্য আপডেট করার কারণে হবে?

• এই ভাঙার প্রভাব কী? আমি কি কারোর ক্রেডিট কার্ড থেকে দুবার চার্জ করতে যাচ্ছি, নাকি এটি কিছু অনুপস্থিত পাঠ্যের সাথে শেষ হতে চলেছে?

• কত ঘন ঘন এই অংশ ব্যবহার করা হয়? এটি কি অ্যাপের আচরণের জন্য সমালোচনামূলক, নাকি এটি পাদচরণে কোথাও সমাহিত একটি সম্পর্কে পাতা?

আপনার শুধু করা উচিত নয় গুরুত্বপূর্ণ অংশ পরীক্ষা করুন। কিন্তু আপনার কাছে এমন একটি অ্যাপ থাকবে যা অনুভূত হয় উচ্চ মানের যদি আপনি আপনার পরীক্ষার সময় ভালভাবে ব্যয় করেন।

আপনি যদি আপনার অ্যাপের মাধ্যমে কেউ নিতে পারে এমন প্রতিটি সম্ভাব্য পথ পরীক্ষা করার চেষ্টা করেন, আপনি কখনই শিপিং করবেন না। TDD সাহায্য করে, কিন্তু এটি আপনার সমস্ত পরীক্ষার সমস্যার সমাধান করবে না।

অবশ্যই, এর মানে এই নয় যে আপনার মোটেও পরীক্ষা করা উচিত নয়।

আপনার পরীক্ষা ছোট রাখতে আপনি পরীক্ষা পিরামিড ব্যবহার করতে পারেন। আপনি m * n চালু করতে নির্ভরতাকে আলাদা করতে এবং ভাঙতে পারেন কেসগুলিকে m + n-এ পরীক্ষা করুন . এবং আপনি অগ্রাধিকার দিতে পারেন, যাতে আপনি আপনার অ্যাপের সবচেয়ে গুরুত্বপূর্ণ অংশগুলি পরীক্ষা করার জন্য আরও সময় ব্যয় করতে পারেন৷

সুতরাং, কতটা আপনি করেন পরীক্ষা? আপনি কি আপনার অ্যাপ তৈরি করার সময় এই ধারনাগুলির কোনটি বিবেচনা করেন? এবং আপনি কীভাবে জানেন যে আপনার অ্যাপের কোন অংশগুলিতে ফোকাস করতে হবে? একটি মন্তব্য করুন এবং আমাকে এটি সম্পর্কে সব বলুন!৷