আমার পরীক্ষা কভারেজ কি ঘটেছে?

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

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

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

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

আপনাকে সিদ্ধান্ত নিতে হবে না

আপনি যদি আপনার কীবোর্ডে বসে সিদ্ধান্ত নেওয়ার চেষ্টা করছেন বিট অফকোড পরীক্ষা করা দরকার কিনা, আপনি ইতিমধ্যেই ভুল পথে যাচ্ছেন। আপনি সবসময় ডিফল্ট করা উচিত "এটি পরীক্ষা করুন!" এমনকি যদি এটি খুব তুচ্ছ টোনড পরীক্ষা বলে মনে হয়, পরীক্ষা লিখুন।

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

কিন্তু আপনি ওভারটেস্ট করতে চান না

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

এটা কি আমার আগের বিন্দুর বিরোধিতা করে? অগত্যা. আপনার পরীক্ষাগুলি সর্বদা আপনার কোডের ইন্টারফেসের উপর ফোকাস করা উচিত , এরবাস্তবায়ন নয় . যেমন:

class Cart
  def initialize(item_params)
    @line_items = Array(item_params).map {|item| LineItem.new(item[:name], item[:price])}
  end

  def total
    @line_items.sum(&:price)
  end
end

এটা সত্যিই মনে হচ্ছে যে কোডটি এখানে Cart উভয়ই পরীক্ষা করতে হবে ক্লাস এবং LineItem ক্লাস কিন্তু হল LineItem ক্লাস অন্য কিছু দ্বারা ব্যবহৃত? যদি এটি শুধুমাত্র Cart এর বাস্তবায়নের বিশদ হয় , এবং বহির্বিশ্বের কাছে প্রকাশ করা হয় না, এটির আসলে কতগুলি পরীক্ষার প্রয়োজন?এটি কি কেবল মাঝে পরীক্ষা করা যায় না আপনার Cart ক্লাস?

রিফ্যাক্টরিং দ্বারা নিষ্কাশিত ক্লাসগুলি প্রায়ই তাদের নিজস্ব পরীক্ষা স্যুটের প্রয়োজন হয় না। এগুলি কেবলমাত্র একটি বাস্তবায়নের বিবরণ৷৷ শুধুমাত্র যখন তারা নিজেরাই ব্যবহার করা হয় তখনই তাদের সেই অতিরিক্ত পরীক্ষার প্রয়োজন হয়।

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

টেস্ট-চালিত বিকাশের সাথে আপনার পরীক্ষার খরচ পরিবর্ধন করুন

প্রথম বিভাগে, আপনি শিখেছেন যে আপনার সবকিছু পরীক্ষা করা উচিত। দ্বিতীয় বিভাগে, আপনি শিখেছেন যে আপনার শুধুমাত্র পাবলিক ইন্টারফেস পরীক্ষা করা উচিত। এটি টেস্ট-চালিত উন্নয়ন যা এই দুটি বিপরীত লক্ষ্যকে একত্রিত করে।

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

1. একটি ব্যর্থ পরীক্ষা লিখুন যা ধরে নেয় যে আপনার প্রয়োজনীয় কোডটি ইতিমধ্যেই আছে৷
৷
2. পরীক্ষায় উত্তীর্ণ কোডের সহজতম প্রয়োগ লিখুন।
3. ডুপ্লিকেশন অপসারণের জন্য রিফ্যাক্টর (অথবা কোডটিকে আরও অভিব্যক্তিপূর্ণ করে তোলে)।
4. পরীক্ষাগুলি আবার চালান (তারা এখনও পাস করেছে তা নিশ্চিত করতে)।
5. ধাপ 1 এ ফিরে যান।

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

এটি কখনই ঠিক এত সহজ নয়। কিন্তু এখনও সবচেয়ে জটিল কোড পরীক্ষা করার উপায় আছে।

TDD এর কিছু পার্শ্ব সুবিধা রয়েছে:

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

তাহলে আমি কিভাবে শুরু করব?

শুরু করা কঠিন অংশ! একবার আপনি টেস্ট-চালিত কোড লেখার ছন্দে চলে গেলে, এটি বন্ধ করা কঠিন।

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

আপনি হয়ে গেলে, আমাকে একটি ইমেল পাঠান এবং আমাকে জানান যে এটি কেমন হয়েছে।

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