টেস্ট বাগগুলি সংশোধন করার সময় কি আমাদের সর্বদা ইউনিট করা উচিত?


29

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

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

অতএব আমার প্রশ্ন: আপনি পুনরুত্পাদন করার জন্য জটিল যে বাগগুলির জন্য কীভাবে পরীক্ষা করবেন? আপনি কীভাবে এমন জিনিস তৈরি করা এড়িয়ে যাবেন যা বাস্তবায়নের পরীক্ষা করে, এবং রিফ্যাক্টরিং এবং পঠনযোগ্যতার ক্ষতি করে?


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

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

1
যদি কোনও ইউনিটের জন্য এটি খুব জটিল হয় তবে এটি ইন্টিগ্রেশন পরীক্ষার অংশ হিসাবে তৈরি করবে
ফ্রিক

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

উত্তর:


27

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

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


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

2
ভাল, প্রকৃতপক্ষে, শেষ অবধি পরীক্ষাটি বজায় রাখতে প্রয়োজনীয় সময়ের মধ্যে ভারসাম্য বজায় রাখার সময় বনাম যদি এটি আবার ঘটে থাকে তবে এটি সনাক্ত করতে এবং বাগটি সংশোধন করতে সময় লাগবে vs
জোনকো

আমি পরীক্ষাটি সাধারণীকরণের পক্ষেও থাকব যাতে এটি কোনও নির্দিষ্ট রাজ্যে পৌঁছানোর পরে কেবল চাকরীটি বাতিল এবং পুনরায় চেষ্টা করার পরীক্ষা করা হয় না, বরং যে কোনও রাজ্যে কোনও চাকরি থাকতে পারে তা পরীক্ষা বন্ধ করে দেওয়া এবং পুনরায় চেষ্টা করা হয়
ওল্ড প্রো

+1 এর জন্য "যেহেতু ব্যাগগুলি চালিয়ে যেতে বাধাগুলিতে ইউনিট পরীক্ষার বিকাশ এবং বজায় রাখার চেয়ে ওভারহেড থাকে" "
পিটার কে।

16

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


7

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

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

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

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


5

হ্যাঁ তুমি পারবে.

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.