ইউনিট পরীক্ষাগুলি কেন খারাপ হিসাবে দেখা হচ্ছে?


93

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

ব্যক্তিগতভাবে, আমি মনে করি নিম্নলিখিত কারণে এটি হওয়া উচিত নয়:

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

  2. এটি ব্যর্থ হবে এমন ইউনিট পরীক্ষাগুলি ভাবা একটি বিতর্ককারী। অথবা অবশ্যই ইউনিট পরীক্ষা নিয়ে আসুন যা ঠিক করা কঠিন।

  3. যদি কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষাগুলি পাস করে তবে সময়ে কোনও সময়ে সফ্টওয়্যারটির অবস্থার কোনও বড় চিত্র নেই। কোনও রোডম্যাপ / লক্ষ্য নেই।

  4. এটি প্রয়োগের পূর্বে - ইউনিট লেখার ইউনিট পরীক্ষার প্রতিরোধ করে।

আমি এমনকি সুপারিশ করব যে এমনকি ইউনিট পরীক্ষায় ব্যর্থতার সাথে সফ্টওয়্যার প্রকাশ করাও খারাপ নয়। অন্ততপক্ষে আপনি জানেন যে সফ্টওয়্যারটির কিছু দিকের সীমাবদ্ধতা রয়েছে।

আমি কি এখানে কিছু মিস করছি? সংস্থাগুলি কেন সব ইউনিট পরীক্ষা পাসের আশা করে? এটি কি স্বপ্নের জগতে বাস করে না? এবং এটি আসলে কোডের সত্যিকারের বোঝাকে বাধা দেয় না?


মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।
ম্যাপেল_শ্যাফ্ট

উত্তর:


270

এই প্রশ্নে আইএমএইচও বেশ কয়েকটি ভুল ধারণা রয়েছে, তবে প্রধান যেটিটিতে আমি আলোকপাত করতে চাই তা হ'ল এটি স্থানীয় উন্নয়ন শাখা, ট্রাঙ্ক, মঞ্চায়ন বা প্রকাশের শাখাগুলির মধ্যে পার্থক্য করে না।

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

স্টেজিং বা রিলিজ ব্রাঞ্চে, ব্যর্থ পরীক্ষাগুলি "রেড অ্যালার্ট" হয় যা দেখায় কিছু ট্রান্সসেটের সাথে পুরোপুরি কিছু ভুল হয়েছে, যখন এটি ট্রাঙ্ক থেকে রিলিজ শাখায় একীভূত করা হয়েছিল।

আমি এমনকি সুপারিশ করব যে এমনকি ইউনিট পরীক্ষায় ব্যর্থতার সাথে সফ্টওয়্যার প্রকাশ করাও খারাপ নয়।

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

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


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

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

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

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

1
+1, যদিও আমি এই বাক্যে সামান্য সংযোজনের (সাহসী) পরামর্শ দিচ্ছি: "এটি জটিল, ত্রুটি-প্রবণ হয়ে ওঠে , শর্ত হিসাবে মানুষ পরীক্ষার স্যুটটিতে ব্যর্থতা উপেক্ষা করার শর্ত দেয় এবং ইউনিট পরীক্ষার অটোমেশন দিকের বিশাল অংশটি ত্যাগ করে conditions
mtraceur

228

... সব ইউনিট পরীক্ষা সবুজ মধ্যে পাস - যা ভাল বলে মনে হয়।

এটা তোলে হয় ভাল। এটি সম্পর্কে "থাকার কথা" নেই।

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

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

এটি ব্যর্থ হবে এমন ইউনিট পরীক্ষাগুলি ভাবা একটি বিতর্ককারী।

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

বিকাশকারী এবং পরীক্ষকের মানসিকতার তুলনা করতে:

  • কোনও বিকাশকারী কোড তারা যা চায় তা করার সাথে সাথেই থেমে যায়।
  • একটি পরীক্ষক থামিয়ে দেয় যখন তারা আর কোড ব্রেক করতে পারবেন না।

এগুলি মূলত ভিন্ন দৃষ্টিভঙ্গি এবং এটি অনেক বিকাশকারীদের মধ্যে পুনর্মিলন করা কঠিন difficult

অথবা অবশ্যই ইউনিট পরীক্ষা নিয়ে আসুন যা ঠিক করা কঠিন।

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

  • ডিবাগিং "প্রমাণিত করে" যে কোডটি আপনি আজ এটি চান তা করে ।
  • পরীক্ষাগুলি "প্রমাণিত করুন" যে কোডটি আপনি সময়ের সাথে এটি যা চান তা এখনও করে ।

যদি কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষাগুলি পাস করে তবে সময়ে কোনও সময়ে সফ্টওয়্যারটির অবস্থার কোনও বড় চিত্র নেই। কোনও রোডম্যাপ / লক্ষ্য নেই।

কেবলমাত্র "চিত্র" পরীক্ষাটি আপনাকে দেয় এমন একটি স্ন্যাপশট যা কোডটি পরীক্ষা করার সময় সময়ে "কাজ করে"। এর পরে কীভাবে এটি বিকশিত হয় তা ভিন্ন গল্প।

এটি প্রয়োগের পূর্বে - ইউনিট লেখার ইউনিট পরীক্ষার প্রতিরোধ করে।

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

আমি এমনকি সুপারিশ করব যে এমনকি ইউনিট পরীক্ষায় ব্যর্থতার সাথে সফ্টওয়্যার প্রকাশ করাও খারাপ নয়। অন্ততপক্ষে আপনি জানেন যে সফ্টওয়্যারটির কিছু দিকের সীমাবদ্ধতা রয়েছে।

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

এটি কি স্বপ্নের জগতে বাস করে না?

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

এবং এটি আসলে কোডের সত্যিকারের বোঝাকে বাধা দেয় না?

সম্ভবত। পরীক্ষার জন্য কিছু লেখার জন্য আপনার প্রয়োজনীয়তা বোঝার প্রয়োজন নেই (এটি তাদের মূল অংশের অংশ)। পরীক্ষাগুলি প্রয়োগের আচরণ এবং সীমাবদ্ধতার সংজ্ঞা দেয় এবং নিশ্চিত করে যে আপনি সেগুলি ইচ্ছাকৃতভাবে পরিবর্তন না করলে সেগুলি একই থাকে।


7
@ টিবোস: একটি পরীক্ষা অক্ষম করা একটি ফাংশন মন্তব্য করার মতো। আপনার সংস্করণ নিয়ন্ত্রণ রয়েছে। এটা ব্যবহার করো.
কেভিন

6
@ কেভিন আমি আপনাকে এটি ব্যবহার করে বোঝাতে চাইনি know আমি একটি পরীক্ষাকে 'এড়িয়ে যাওয়া' বা 'মুলতুবি' বা আমার পরীক্ষার রানার যে কোনও কনভেনশন ব্যবহার করে তা চিহ্নিত করি এবং সেই স্কিপ ট্যাগটিকে সংস্করণ নিয়ন্ত্রণে প্রতিশ্রুতিবদ্ধ।
dcorking

4
@ ডকার্কিং: এর অর্থ কোডটি মন্তব্য করা উচিত নয়, এটি মুছুন। আপনি যদি পরে সিদ্ধান্ত নেন যে আপনার এটির দরকার হয়, তবে এটি সংস্করণ নিয়ন্ত্রণ থেকে পুনরুদ্ধার করুন। প্রতিবন্ধী পরীক্ষা করা আলাদা নয়।
কেভিন

4
"এটি সম্পূর্ণরূপে সম্ভব যে আপনার পরীক্ষাগুলি প্রতিটি ক্ষেত্রে জুড়ে না।" আমি এতদূর যেতে পারি যে পরীক্ষিত প্রতিটি অ-তুচ্ছ কোডের জন্য, আপনি অবশ্যই প্রতিটি কেস কভার করবেন না
কর্সিকা 22'18

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

32

ইউনিট পরীক্ষাগুলি কেন খারাপ হিসাবে দেখা হচ্ছে?

তারা হয় না - পরীক্ষামূলকভাবে চালিত বিকাশ ব্যর্থ পরীক্ষার ধারণার ভিত্তিতে নির্মিত। বিকাশের ড্রাইভিংয়ে ইউনিট পরীক্ষায় ব্যর্থ হওয়া, গল্প চালানোর জন্য গ্রহণযোগ্যতা পরীক্ষায় ব্যর্থ হওয়া ....

আপনি যা অনুপস্থিত তা প্রসঙ্গ ; ইউনিট পরীক্ষা কোথায় ব্যর্থ হতে দেওয়া হয়?

সাধারণ উত্তরটি হ'ল ইউনিট পরীক্ষাগুলি কেবলমাত্র ব্যক্তিগত স্যান্ডবক্সগুলিতে ব্যর্থ হওয়ার অনুমতি দেওয়া হয়।

প্রাথমিক ধারণাটি হ'ল: এমন পরিবেশে যেখানে ব্যর্থ পরীক্ষাগুলি ভাগ করা হয়, সেখানে প্রোডাকশন কোডে পরিবর্তন নতুন ত্রুটি প্রবর্তন করেছে কিনা তা বোঝার জন্য অতিরিক্ত প্রচেষ্টা দরকার takes শূন্য এবং শূন্য নয় পার্থক্যটি এন এবং এন এর পার্থক্যের চেয়ে সনাক্তকরণ এবং পরিচালনা করা অনেক সহজ

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

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

আরও সুনির্দিষ্টভাবে বলতে গেলে: শৃঙ্খলাটি হ'ল বিল্ড চলাকালীন যা পরীক্ষাগুলি পাস করা উচিত।

এখানে সেরা হিসাবে বলতে পারি, অক্ষম হওয়া পরীক্ষাগুলি ব্যর্থ করার সাথে কোনও ভুল নেই

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

সেই একই কৌশলগুলি ব্যর্থ পরীক্ষাগুলি অক্ষম করতেও ব্যবহার করা যেতে পারে।

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

সংক্ষেপে: ট্র্যাকিংয়ের কাজগুলির জন্য অন্যান্য কৌশল রয়েছে যা চলমান স্যুটটিতে ব্যর্থ পরীক্ষাগুলির একগুচ্ছ ছাড়াই সম্পন্ন হয় না


আমি বলেন না "নেই ... কিছুই না থাকার সঙ্গে ভুল ব্যর্থ পরীক্ষার যে হয় অক্ষম "।
সিজে ডেনিস

এই পরিবর্তন অবশ্যই অর্থ স্পষ্ট করে। ধন্যবাদ.
ভয়েসফুউনরেজন

26

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

আপনার কোডটি বাগ বিনামূল্যে আছে কিনা তা পরীক্ষা করার জন্য ইউনিট পরীক্ষাগুলি নেই।

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

ইউনিট পরীক্ষাগুলি পরীক্ষা করে যে আপনার কোড আপনাকে যা মনে করে তা করে।

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

এখন, উপরের সমস্তটি কেবলমাত্র সমস্ত পরীক্ষার সবুজ হলেই কার্যকর হয়, একটি শক্তিশালী ইতিবাচক ফলাফল দেয়: কোডটি ঠিক এভাবে কাজ করে। লাল পরীক্ষার সেই সম্পত্তি নেই। "এই কোডটি এটি করে না" খুব কমই কার্যকর তথ্য।

স্বীকৃতি পরীক্ষা আপনি যা খুঁজছেন তা হতে পারে।

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


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

24

আমি এটিকে ভাঙা উইন্ডো সিন্ড্রোমের সমতুল্য সফ্টওয়্যার হিসাবে দেখছি ।

কার্যকরী পরীক্ষাগুলি আমাকে বলে যে কোডটি একটি নির্দিষ্ট মানের এবং কোডের মালিকরা এটি সম্পর্কে যত্নশীল।

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

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

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


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

1
@ লুয়ান হ্যাঁ, এটি বরং ধরে নিচ্ছে যে সমস্ত ইউনিট পরীক্ষা সমানভাবে তৈরি করা হয়েছে created বিল্ড ম্যানেজারদের পরীক্ষাগুলি কতটা টুকরো টুকরো করে কাটা এবং কতক্ষণ চালানো যায়, কতটা খণ্ডন তা নির্ভর করে এবং অন্যান্য বিভিন্ন মানদণ্ডের উপর নির্ভর করে এটি অস্বাভাবিক কিছু নয়।
রবি ডি

এই উত্তরটি আমার খুব স্ব অভিজ্ঞতা দ্বারা দুর্দান্ত। কিছু লোক একবার ব্যর্থ পরীক্ষার একগুচ্ছ উপেক্ষা করার জন্য ব্যবহার করতে বা কিছু পয়েন্টের সেরা অনুশীলনগুলি ভাঙতে ব্যবহার করতে শুরু করে, কয়েক মাস কেটে যেতে পারে এবং আপনি দেখবেন% উপেক্ষা করা পরীক্ষাগুলি নাটকীয়ভাবে বৃদ্ধি পাচ্ছে, কোডের মান "হ্যাক-স্ক্রিপ্ট" স্তরে নেমে আসবে । এবং প্রক্রিয়াটিতে প্রত্যেককে প্রত্যাহার করা খুব কঠিন হবে।
usr- স্থানীয়-ΕΨΗΕΛΩΝ

11

এখানে অন্তর্নিহিত লজিকাল ভ্রান্তিটি রয়েছে:

সমস্ত পরীক্ষা পাস করার সময় যদি এটি ভাল হয়, তবে কোনও পরীক্ষা ব্যর্থ হলে এটি অবশ্যই খারাপ bad

ইউনিট পরীক্ষা সঙ্গে, এটা IS ভাল যখন সমস্ত পরীক্ষার পাস। যখন কোনও পরীক্ষা ব্যর্থ হয় তখন এটি খুব ভালদু'জনের বিরোধী হওয়ার দরকার নেই।

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


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

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

9

ফিল ডাব্লু এর উত্তর দুর্দান্ত। আমি এটি প্রতিস্থাপন করতে পারি না।

যাইহোক, আমি অন্য একটি অংশে ফোকাস করতে চাই যা বিভ্রান্তির অংশ হতে পারে।

কিছু সংস্থায়, স্পষ্টতই, সফ্টওয়্যার রিলিজ প্রক্রিয়াটির এককটি ইউনিট টেস্টিং ব্যবহার করা হয়, তবে যে কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষা পাস করতে হবে

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

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


এটি দলের বিধি হিসাবে বিরোধ তৈরি করতে পারে। আমি আসলে কয়েক সপ্তাহ আগে এটির মুখোমুখি হয়েছিলাম:

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

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

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


3
এক উপায় এই করতে কাজ শাখাবিন্যাস, যেমন যে devs কমিট এবং শাখা যে অসম্পূর্ণ পরিচ্ছন্নভাবে গড়ে তুলতে প্রয়োজন হবে না বৈশিষ্ট্য ধাক্কা ব্যবহার করতে হয়, কিন্তু কোর শাখায় করে একটি build, যা পরিচ্ছন্নভাবে গড়ে তুলতে চাই না আরম্ভ না।
Gwyn ইভান্স

1
অসম্পূর্ণ পরিবর্তনগুলি ঠেকানো কার্যকর নয়, আমি এটি করার কোনও যুক্তি দেখতে পাচ্ছি না। পরিবর্তনটি সম্পূর্ণ হলে কোড পর্যালোচনা কেন হবে না?
কলম ব্র্যাডবারি

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

1
বৈশিষ্ট্যযুক্ত পতাকাগুলি আপাত প্যারাডক্সটিকে ঠিক করে দেয়।
রাবারডাক

1
@ ফ্লাটার হ্যাঁ, বিদ্যমান যুক্তি পুনরায় কাজ করার জন্য।
রাবারডাক

6

আপনি যদি সমস্ত ইউনিট পরীক্ষা ঠিক না করেন আপনি দ্রুত সেই রাজ্যে প্রবেশ করতে পারবেন যেখানে কোনও ভাঙ্গা পরীক্ষা কেউ ঠিক করে না।

  1. পাসিং ইউনিট পরীক্ষাগুলি কোডটি নিখুঁত দেখাচ্ছে না বলে ভুল হয়

  2. কোডটি নিয়ে আসা একটি বিতর্কিত, যা পরীক্ষা করাও কঠিন, যা ডিজাইনের দৃষ্টিকোণ থেকে ভাল

  3. কোড কভারেজটি সেখানে সহায়তা করতে পারে (যদিও এটি কোনও চিকিত্সা নয়)। এছাড়াও ইউনিট পরীক্ষাগুলি পরীক্ষার কেবল একটি দিক - আপনি ইন্টিগ্রেশন / গ্রহণযোগ্যতা পরীক্ষাও চান।


6

ইতিমধ্যে ভাল উত্তরে কয়েকটি পয়েন্ট যুক্ত করতে ...

তবে সময়ে যে কোনও সময়ে সমস্ত ইউনিট পরীক্ষা পাস করতে হবে

এটি একটি মুক্তি প্রক্রিয়া বোঝার অভাব দেখায়। একটি পরীক্ষায় ব্যর্থতা টিডিডির অধীনে একটি পরিকল্পিত বৈশিষ্ট্যটি নির্দেশ করতে পারে যা এখনও প্রয়োগ করা হয়নি; বা এটি কোনও ज्ञিত সমস্যা নির্দেশ করতে পারে যা ভবিষ্যতের মুক্তির জন্য একটি স্থির পরিকল্পনা রয়েছে; বা এটি এমন কিছু হতে পারে যেখানে পরিচালনা সিদ্ধান্ত নিয়েছে যে এটি ঠিক করার পক্ষে এটি যথেষ্ট গুরুত্বপূর্ণ নয় কারণ গ্রাহকদের নজরে আসার সম্ভাবনা নেই। এই সমস্ত ভাগের মূল বিষয়টি হ'ল পরিচালনা ব্যর্থতা সম্পর্কে রায় দিয়েছে।

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

অন্যান্য উত্তরগুলি পরীক্ষার সীমাবদ্ধ করেছে।

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

যদি কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষাগুলি পাস করে তবে সময়ে কোনও সময়ে সফ্টওয়্যারটির অবস্থার কোনও বড় চিত্র নেই। কোনও রোডম্যাপ / লক্ষ্য নেই।

কেন অবশ্যই একটি রোডম্যাপ থাকতে হবে?

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

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


6

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

সত্য না. কেন আপনি অসম্ভব বলে মনে করেন? প্রোগ্রামের জন্য উদাহরণস্বরূপ যে এটি কাজ করে:

public class MyProgram {
  public boolean alwaysTrue() {
    return true;
  }

  @Test
  public void testAlwaysTrue() {
    assert(alwaysTrue() == true);
  }
}

এটি ব্যর্থ হবে এমন ইউনিট পরীক্ষাগুলি ভাবা একটি বিতর্ককারী। অথবা অবশ্যই ইউনিট পরীক্ষা নিয়ে আসুন যা ঠিক করা কঠিন।

সেক্ষেত্রে এটি ইউনিট পরীক্ষা নাও হতে পারে তবে জটিল হলে ইন্টিগ্রেশন টেস্ট

যদি কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষাগুলি পাস করে তবে সময়ে কোনও সময়ে সফ্টওয়্যারটির অবস্থার কোনও বড় চিত্র নেই। কোনও রোডম্যাপ / লক্ষ্য নেই।

সত্য, এটি একটি কারণে ইউনিট পরীক্ষা বলা হয় , এটি কোডের একটি ছোট ইউনিট পরীক্ষা করে।

এটি প্রয়োগের পূর্বে - ইউনিট লেখার ইউনিট পরীক্ষার প্রতিরোধ করে।

ডেভেলপারগণ ইচ্ছাশক্তিলেখার নিরস্ত কোনো পরীক্ষার যদি তারা তার সুফল বুঝতে পারছি নাতাদের প্রকৃতির দ্বারা (তারা QA থেকে আগত না হলে)


"ডেভেলপাররা তাদের প্রকৃতির দ্বারা কোনও পরীক্ষা লেখার জন্য [sic] নিবৃত্তি করবে" - এটি একেবারে বাজে কথা। আমি বিকাশকারীদের একটি সম্পূর্ণ সংস্থায় কাজ করি যারা টিডিডি এবং বিডিডি অনুশীলন করে।
রাবারডাক

@ রাবারডাক আমি প্রশ্নের মধ্যে একটি "সত্য" এর উত্তর দেওয়ার চেষ্টা করেছি এবং আমি অত্যুক্তি করেছিলাম। আমি আপডেট করব
user7294900

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

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

@ বেনভয়েগ আমি মনে করি না যে আমি উত্তর হিসাবে একটি "গুরুত্বপূর্ণ প্রোগ্রাম" দেব বলে আশা করি।
user7294900

4

কোডটি নিখুঁত হওয়া উচিত এবং কোনও বাগের অস্তিত্ব থাকা উচিত নয় এই ধারণার প্রচার করে

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

এটি ব্যর্থ হবে এমন ইউনিট পরীক্ষাগুলি ভাবা একটি বিতর্ককারী। অথবা অবশ্যই ইউনিট পরীক্ষা নিয়ে আসুন যা ঠিক করা কঠিন।

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

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

যদি কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষাগুলি পাস করে তবে সময়ে কোনও সময়ে সফ্টওয়্যারটির অবস্থার কোনও বড় চিত্র নেই। কোনও রোডম্যাপ / লক্ষ্য নেই।

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

কোডগুলি লেখার আগে পরীক্ষাগুলির কার্যকারিতা সম্পূর্ণতার মধ্যে নেই।

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

এটি প্রয়োগের পূর্বে - ইউনিট লেখার ইউনিট পরীক্ষার প্রতিরোধ করে।

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

আমি কি এখানে কিছু মিস করছি? সংস্থাগুলি কেন সব ইউনিট পরীক্ষা পাসের আশা করে?

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

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

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

এটি কি স্বপ্নের জগতে বাস করে না?

না। পরীক্ষা-চালিত অ্যাপ্লিকেশনটির সাথে কাজ করা খাঁটি আনন্দ - যদি না আপনি যে কারণেই ("আরও প্রচেষ্টা" ইত্যাদি) ইত্যাদির জন্য ধারণাটি পছন্দ না করেন যা আমরা অন্য একটি প্রশ্নে আলোচনা করতে পারি।

এবং এটি আসলে কোডের সত্যিকারের বোঝাকে বাধা দেয় না?

একেবারে না, কেন হবে?

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

স্পষ্টতই, খারাপ পরীক্ষা লেখা খারাপ। তবে সেটের সাথে পরীক্ষার ক্রিয়াকলাপের কোনও সম্পর্ক নেই।


3

(আমার মূল মন্তব্য থেকে)

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

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


2

স্বয়ংক্রিয় পরীক্ষার উদ্দেশ্য হ'ল আপনি যত তাড়াতাড়ি কিছু ভেঙেছেন তা আপনাকে বলা । কর্মপ্রবাহটি দেখতে কিছুটা এ জাতীয় দেখাচ্ছে:

  1. পরিবর্তন আনো
  2. আপনার পরিবর্তনটি তৈরি করুন এবং পরীক্ষা করুন (আদর্শভাবে স্বয়ংক্রিয়ভাবে)
  3. যদি পরীক্ষাগুলি ব্যর্থ হয় তবে এর অর্থ হ'ল আপনি আগে কাজ করা কিছু ভেঙে দিয়েছিলেন
  4. যদি পরীক্ষাগুলি পাস করে তবে আপনার আত্মবিশ্বাস থাকা উচিত যে আপনার পরিবর্তনটি কোনও নতুন প্রবণতা চালু করেনি (পরীক্ষার কভারেজের উপর নির্ভর করে)

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

যত তাড়াতাড়ি সম্ভব নতুন প্রবর্তিত বাগগুলি সন্ধানের জন্য ইউনিট পরীক্ষার সক্ষমতা হ'ল স্বয়ংক্রিয় পরীক্ষার বিষয়ে সর্বাধিক মূল্যবান জিনিস - ত্রুটিটি যত দীর্ঘায়িত হবে তত বেশি ব্যয় করা ঠিক হবে।

কোডটি নিখুঁত হওয়া উচিত এবং কোনও ত্রুটি থাকা উচিত নয় এই ধারণাটি প্রচার করে এটি
ইউনিট পরীক্ষাগুলি ব্যর্থ হবে বলে চিন্তা করা নিষিদ্ধ

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

এটি আপ-ফ্রন্টের ইউনিট পরীক্ষাগুলি রোধ করে

যদি এটি আপনার পক্ষে কাজ করে তবে সামনে পরীক্ষা লিখুন, তারা পাস না করা পর্যন্ত কেবল তাদের মাস্টার / ট্রাঙ্কে পরীক্ষা করবেন না।

যদি কোনও মুহুর্তে সমস্ত ইউনিট পরীক্ষাগুলি পাস করে তবে সময়ে কোনও সময়ে সফ্টওয়্যারটির অবস্থার কোনও বড় চিত্র নেই। কোনও রোডম্যাপ / লক্ষ্য নেই।

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


2

বিদ্যমান উত্তরগুলি অবশ্যই ভাল, তবে আমি এই প্রশ্নে কাউকে এই মূল ধারণাটির ভুল সমাধান করতে দেখিনি:

সময়ে যে কোনও সময়ে সমস্ত ইউনিট পরীক্ষা পাস করতে হবে

না। নিশ্চিতভাবেই, এটি সত্য হবে না। আমি যখন সফ্টওয়্যারটি বিকাশ করছি, এনক্রাঞ্চ প্রায়শই হয় বাদামী (বিল্ড ব্যর্থতা) বা লাল (ব্যর্থ পরীক্ষা)।

যেখানে এনক্রাঞ্চকে সবুজ হতে হবে (সমস্ত পরীক্ষার উত্তীর্ণ হওয়া) যখন আমি উত্স নিয়ন্ত্রণ সার্ভারে একটি প্রতিশ্রুতি দেওয়ার জন্য প্রস্তুত, কারণ তখন অন্যরা আমার কোডের উপর নির্ভরতা নিতে পারে।

এটি নতুন পরীক্ষা তৈরির বিষয়টিতেও ফিড দেয়: টেস্টগুলির কোডের যুক্তি এবং আচরণকে দৃ .় করা উচিত। সীমানা পরিস্থিতি, দোষের শর্ত ইত্যাদি etc. আমি যখন নতুন পরীক্ষা লিখি, কোডে এই "হট স্পট" সনাক্ত করার চেষ্টা করি।

ইউনিট পরীক্ষা করে নথিগুলি কীভাবে আমার কোডটি কল করার প্রত্যাশা করে - পূর্বশর্ত, প্রত্যাশিত আউটপুট ইত্যাদি,

যদি কোনও পরিবর্তন পরিবর্তনের পরে কোনও পরীক্ষা ভঙ্গ করে, কোড বা পরীক্ষাটি ত্রুটিযুক্ত কিনা তা আমাকে সিদ্ধান্ত নিতে হবে।


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

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

পরিবর্তে, আমার লাইব্রেরিটি এন্টলার এবং একটি ওরাকল 12 সি সিনট্যাক্স ব্যবহার করে ক্যোয়ারীটি পার্স করে এবং তারপরে সিনট্যাক্স ট্রিটিতে বিভিন্ন যুক্তি মোড়ানো। এর মতো বিষয়গুলি, এটি বৈধ (কোনও পার্স ত্রুটি উত্থাপিত হয়নি), এর সমস্ত পরামিতি প্যারামিটার সংগ্রহের দ্বারা সন্তুষ্ট, ডেটা পাঠক দ্বারা পড়া সমস্ত প্রত্যাশিত কলামগুলি ক্যোয়ারীতে উপস্থিত রয়েছে ইত্যাদি etc. এগুলি সমস্তই এমন আইটেম যা এতে পিছলে গেছে বিভিন্ন সময়ে উত্পাদন।

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

UPDATE my_table(
SET column_1 = 'MyValue'
WHERE id_column = 123;

আমি প্রকল্পটি লোড করেছি এবং একটি ইউনিট পরীক্ষা যুক্ত করেছি যা দৃ as়ভাবে জানিয়েছে যে এই কোয়েরিটি বৈধ হবে না। স্পষ্টতই, পরীক্ষাটি ব্যর্থ হয়েছিল।

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

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


0

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

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

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


আমি মনে করি আপনি "বাহ্যিক পরীক্ষা" হিসাবে যা বর্ণনা করছেন তা প্রায়শই অন্যত্র অন্যত্র "সংহতকরণ" পরীক্ষা হিসাবে বর্ণনা করা হয়।
গ্যালাকটিক

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

0

"তবে সময়ে যে কোনও সময়ে সমস্ত ইউনিট পরীক্ষা অবশ্যই পাস করতে হবে"

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

কোনও যুক্তিসঙ্গত ব্যক্তি কোনও প্রোগ্রামারকে প্রথমবারের মতো তার কাজটি নিখুঁত করার প্রত্যাশা করে না। আমরা যুক্তিসঙ্গতভাবে যা প্রত্যাশা করি তা হ'ল কোনও সমস্যা দেখা না দেওয়া পর্যন্ত তিনি এতে কাজ চালিয়ে যাবেন।

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

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

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


-7

এটি নিশ্চিতকরণ পক্ষপাতের একটি নির্দিষ্ট উদাহরণ , যেখানে লোকেরা তাদের বিদ্যমান বিশ্বাসের সত্যতা নিশ্চিত করার জন্য তথ্য খোঁজেন।

এই ঘটনার একটি বিখ্যাত উদাহরণ, 2,4,6 গেমটিতে।

  • আমার মাথায় নিয়ম আছে যে তিনটি সংখ্যার যে কোনও সিরিজ পাস বা ব্যর্থ হবে,
  • 2,4,6 একটি পাস
  • আপনি তিনটি সংখ্যার সেট তালিকাভুক্ত করতে পারেন এবং আমি আপনাকে জানাব যে তারা পাস বা ব্যর্থ হলে।

বেশিরভাগ লোকেরা একটি নিয়ম বাছুন, বলুন "" প্রথম এবং দ্বিতীয় সংখ্যার মধ্যে ব্যবধানটি ২ য় থেকে ২ য় ব্যবধানের সমান। "

তারা কিছু নম্বর পরীক্ষা করবে:

  • 4, 8, 12? পাস
  • 20, 40, 60? পাস
  • 2, 1004, 2006? পাস

তারা বলে "হ্যাঁ, প্রতিটি পর্যবেক্ষণ আমার অনুমানকে নিশ্চিত করে, এটি অবশ্যই সত্য হতে হবে।" ধাঁধা দেওয়ার লোকটিকে তাদের বিধি ঘোষণা করুন।

তবে তারা তিনটি সংখ্যার কোনও সংখ্যায় একটিও 'ব্যর্থ' পায় নি। নিয়মটি কেবল তাদের তিনটি তথ্যের জন্য 'তিনটি সংখ্যা হওয়া দরকার' হতে পারে।

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

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


2
এটি প্রশ্নের সাথে কীভাবে প্রাসঙ্গিক? ব্যর্থ ইউনিট পরীক্ষা হয় সংজ্ঞা দ্বারা, কোন সমস্যা হওয়ার প্রমাণ।
ফ্রেक्स

1
আপনার একেবারে ইউনিট পরীক্ষা থাকতে পারে যার জন্য পরীক্ষার অধীনে সিস্টেমটি একটি ব্যর্থতা মোডে প্রবেশ করে require এটি কখনই কোনও পরীক্ষায় ব্যর্থ হয় না as এটিও কেন
টিডিডিটিকে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.