সরল (স্বনির্ভর) ফাংশনগুলির জন্য পরীক্ষা করার দরকার আছে কি?


36

এই বিবেচনা:

public function polynominal($a, $b, $c, $d)
{
    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;
}

মনে করুন আপনি উপরের ফাংশনটির জন্য বিভিন্ন পরীক্ষা লেখেন এবং নিজের এবং অন্যদের কাছে প্রমাণ করুন যে এটি "এটি কাজ করে"।

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


32
প্রতিটি ফাংশনের ক্ষেত্রে কি এটি সত্য নয় যে আপনি যদি নিজের কোডটি পরিবর্তন না করেন, যদি এটি গতকাল কাজ করে, তবে এটি কালও কাজ করবে? পয়েন্ট যে সফটওয়্যার হয় পরিবর্তন করেছেন।
5gon12eder

3
কারণ কেউ কখনও override_function('pow', '$a,$b', 'return $a * $b;');তাদের সঠিক মনে লিখবে না ... বা জটিল সংখ্যাগুলি পরিচালনা করতে পুনরায় লেখার চেষ্টা করবে না।

8
সুতরাং ... ওম ... এটি "বাগ ফ্রি কোড হিসাবে প্রমাণিত হয়েছে" ... এতে একটি বাগ রয়েছে

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

6
এছাড়াও সেই ফাংশন হর্নার ফর্মের পরিবর্তনের জন্য দুর্দান্ত প্রার্থী (($a*$x + $b)*$x + $c)*$x + $dযা ভুল হওয়া সহজ, তবে প্রায়শই যথেষ্ট দ্রুত হয়। আপনি যেহেতু ভাবেন যে এটি পরিবর্তিত হবে তার অর্থ এটি নয়।
মাইকেল অ্যান্ডারসন

উত্তর:


78

রিগ্রেশন টেস্টিং

এটা তোলে সম্পর্কে সব রিগ্রেশন পরীক্ষণ

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

বিক্ষিপ্ত হয়ে, সে দুটি ধ্রুবককে উল্টে দেয়।

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

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

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

একটি পার্শ্ব প্রতিক্রিয়া...

প্রকৃতপক্ষে, বেশিরভাগ রিফ্যাক্টরিং ভারীভাবে রিগ্রেশন টেস্টের উপর ভিত্তি করে। একটি ছোট পরিবর্তন করুন। পরীক্ষা করুন। যদি এটি পাস হয়, সবকিছু ঠিক আছে।

পার্শ্ব প্রতিক্রিয়াটি হ'ল যদি আপনার পরীক্ষা না হয় তবে কার্যত কোনও রিফ্যাক্টরিং কোড ভাঙার বিশাল ঝুঁকিতে পরিণত হয়। এটি বেশ কয়েকটি ক্ষেত্রে দেওয়া হলেও, পরিচালনাটিকে বোঝানো যে রিফ্যাক্টরিং করা উচিত এটি ইতিমধ্যে কঠিন , আপনার পূর্ববর্তী রিফ্যাক্টরিংয়ের একাধিক বাগ প্রবর্তনের পরে তা করা আরও কঠিন হবে।

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

প্রয়োজনীয়তা পরিবর্তন

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

এত ঝামেলা কেন? পরে সেগুলি যুক্ত করার জন্য কেন পরীক্ষাগুলি অপসারণ করছেন? আপনি তাদের প্রথম স্থানে রাখতে পারতেন।


পেডেন্টিক নোট: কিছুই ঝুঁকি মুক্ত নয়। ;)
jpmc26

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

অন্য পেডেন্টিক নোট: কিছু "যাদু" সংখ্যা আসলে ঠিক আছে, এবং ধ্রুবকগুলির সাথে তাদের প্রতিস্থাপন করা একটি খারাপ ধারণা।
উত্সাহক

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

@ জওয়েন্টিং: স্রেফ সেই নোটটি যুক্ত করেছেন কারণ মাইনমা ​​লিখেছেন "এই পরিবর্তনটি করার ক্ষেত্রে কোনও ভুল নেই" "
উত্সাহক

45

কারণ কিছুই এত সহজ যে কোনও বাগ থাকতে পারে না।

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

এটির একটি বাগ বাদে ...

public function polynominal($a, $b, $c, $d)
{
    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;
}

$xআপনার কোডে একটি ইনপুট হিসাবে সংজ্ঞায়িত করা হয়নি, এবং ভাষা বা রানটাইম বা স্কোপিংয়ের উপর নির্ভর করে আপনার ফাংশনটি কাজ নাও করতে পারে, অবৈধ ফলাফলের কারণ হতে পারে বা স্পেসশিপ ক্র্যাশ করতে পারে


সংযোজন:

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

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

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


একটি বিকল্প সমাধান রয়েছে: অ-গতিশীল অ-দুর্বল ভাষাগুলিতে স্যুইচ করা। ইউনিট টেস্টগুলি সাধারণত অপর্যাপ্ত শক্তিশালী সংকলন-সময় যাচাইকরণের জন্য কার্যকর হয় এবং কিছু কিছু ভাষা এই এন.ইউইকিপিডিয়া.র.উইকি / আগদা_জেপ্রগ্রামিং_এলংয়েজে
ডেন

21

হ্যাঁ। যদি আমরা নিশ্চিতভাবে 100% আত্মবিশ্বাসের সাথে বলতে পারি: এই ফাংশনটি কখনও সম্পাদিত হবে না এবং এমন প্রসঙ্গে কখনও চলবে না যা এটি ব্যর্থ হতে পারে - যদি আমরা এটি বলতে পারি, আমরা পরীক্ষাগুলি ফেলে দিতে পারি এবং প্রতিটিতে কয়েক মিলিসেকেন্ড সংরক্ষণ করতে পারি সিআই বিল্ড।

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

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


আমি মনে করি এটি খুব ভাল পয়েন্ট আপনি এখানে আনছেন। আমি ইতিমধ্যে দুজন ছেলের কিছু ছোট কার্যকারিতার জন্য পরীক্ষা রাখার বিষয়ে বিতর্ক চালিয়ে ঘন্টার মধ্যে দেখতে পাচ্ছি ।
কাপল

@ ক্যাপল: কোন যুক্তি নয়, কোনটি যেতে পারে এবং কোনটি থাকতে পারে তা নির্ধারণ করার জন্য একটি সভা, এবং কোন মানদণ্ডটি সিদ্ধান্ত নিতে ব্যবহার করা উচিত, সেই সাথে মানদণ্ডটি কোথায় ডকুমেন্ট করা যায়, এবং কে চূড়ান্ত সিদ্ধান্তে স্বাক্ষর করে ...
জোমোরনো

12

অন্যান্য উত্তরে যা বলা হয়েছে তা সবই সঠিক তবে আমি আরও একটি যুক্ত করব।

নথিপত্র

ইউনিট পরীক্ষাগুলি, যদি ভালভাবে লিখিত হয় তবে কোনও বিকাশকারীকে কোনও ফাংশনটি ঠিক কীভাবে করতে পারে, এর ইনপুট / আউটপুট প্রত্যাশাগুলি কী, এবং আরও গুরুত্বপূর্ণ এটির দ্বারা আচরণ কী আশা করা যায় তা ব্যাখ্যা করতে পারে।

এটি কোনও বাগ চিহ্নিত করা সহজ এবং কম বিভ্রান্তি তৈরি করতে পারে।

বহুবর্ষ, জ্যামিতি বা এমনকি বীজগণিতের প্রত্যেকেই মনে রাখে না :) তবে সংস্করণ নিয়ন্ত্রণের জন্য পরীক্ষা করা ভাল ইউনিট পরীক্ষাটি আমার মনে থাকবে।

ডকুমেন্টেশন হিসাবে এটি কতটা কার্যকর হতে পারে তার উদাহরণের জন্য, জেসমিনের ভূমিকাটি দেখুন: http://jasmine.github.io/edge/introduction.html লোড করতে কয়েক সেকেন্ড দিন, তারপরে নীচে স্ক্রোল করুন। আপনি ইউনিট পরীক্ষার আউটপুট হিসাবে ডকুমেন্টেড পুরো জেসমিন এপিআই দেখতে পাবেন।

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


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

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

2

বাস্তবতা পরীক্ষা

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

আপনার বাজেট আছে। আপনার কাজটি সেই বাজেটে আপনার সেরা পণ্যটি অর্জন করা, "সেরা" এর যে কোনও সংজ্ঞা আপনি একসাথে স্ক্র্যাপ করতে পারেন (এটি সংজ্ঞায়িত করা সহজ শব্দ নয়)। গল্পের শেষে.

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

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

সফটওয়্যার বিকাশ একটি ভারসাম্য। আপনার সময় ব্যয় করার ভাল উপায় আর ছিল না তা নিশ্চিত করার জন্য আপনি যে কোনও কাজের সুযোগ ব্যয়টি সর্বদা গণনা করুন।


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

0

হ্যাঁ, পরীক্ষা চালিয়ে যান, চালিয়ে যান এবং তাদের উত্তীর্ণ রাখুন।

ইউনিট টেস্টগুলি আপনাকে (এবং অন্যদের) নিজেকে (এবং নিজেরাই) থেকে রক্ষা করার জন্য রয়েছে।

কেন পরীক্ষাগুলি রাখা একটি ভাল ধারণা;

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

2
এটি অন্য যে উত্তর সরবরাহ করা হয়েছে তার চেয়ে বেশি কিছু দেওয়ার প্রস্তাব দিচ্ছে না।

1
এটি পোস্ট করার আগে সমস্যা ছিল, কিন্তু পূর্ববর্তী ক্ষেত্রে এটি একটি দুর্দান্ত সংক্ষিপ্তসার। আমি এটি সরিয়ে ফেলব।
নিলাল

-1

বিকাশকারী ডকুমেন্টেশন

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

ব্যবহারকারী ডকুমেন্টেশন

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

1
এটি পূর্বের উত্তরগুলিতে তৈরি এবং ব্যাখ্যা করা পয়েন্টগুলির চেয়ে বেশি কিছু দেওয়ার প্রস্তাব দিচ্ছে না। এমনকি "দুর্দান্ত সারাংশ" ইতিমধ্যে পোস্ট করা হয়েছে (আমার স্বাদ তাই না এত সুন্দর কিন্তু ওহ ভাল)
মশা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.