100% কোড কভারেজ একটি পাইপ স্বপ্ন?

28

ভারী jquery / backbonejs ওয়েব অ্যাপ্লিকেশনগুলিতে 100% কোড কভারেজ আশা করা কি সম্ভব? যখন জাভাস্ক্রিপ্ট / জকোয়ারিতে প্রকৃত কোড কভারেজ 92% -95% এর আশেপাশে থাকে তখন 100% কভারেজ পূরণ না হওয়ার কারণে স্প্রিন্টে ব্যর্থ হওয়া কি যুক্তিসঙ্গত?

code-quality tdd bdd

— willz
সূত্র

7

"একটি স্প্রিন্টে ব্যর্থ" অদ্ভুতভাবে অশুভ শোনায় ...

— ডোনাল ফেলো

5

এটি একটি অ্যাসিম্পটোট।

— রবার্ট হার্ভে

12

আপনার পুরো কভারেজ থাকলেও কিছু বাগ পাওয়া যাবে না তাই সমস্ত কিছু ঠিক করার জন্য সেই সংখ্যার উপর নির্ভর করবেন না

— রাচেট ফ্রিক

11

সবকিছুই সম্ভব. আসল প্রশ্নটি হচ্ছে 100% কোড কভারেজের মান সময় এবং সংস্থানগুলিতে ব্যয় করা উচিত কিনা।

— জনএফএক্স

5

আপনি কেন এটি নিয়ে চিন্তিত হচ্ছেন, যখন অন্তর্নিহিত অনুমান - যে 100% (বা অন্য কোনও সংখ্যা) স্বয়ংক্রিয় পরীক্ষার কভারেজটি আপনার কোডটিকে যাদুকরীভাবে আরও ভাল করে তুলবে - নিজেই কি পাইপ স্বপ্ন?

— ম্যাসন হুইলারের

30

অবাস্তব হওয়ায় এটিও সমান বাস্তববাদী।

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

অবাস্তববাদী
আপনি 0% কভারেজ থেকে শুরু করছেন ...
প্রকল্পটি অনেকগুলি, অনেকগুলি ত্রুটিযুক্ত পথ যা আবার পুনরায় তৈরি করা বা ট্রিগার করা শক্ত তা নিয়ে সন্ত্রস্ত।
কভারেজ রয়েছে তা নিশ্চিত করতে ম্যানেজমেন্ট কমিটমেন্ট / বিনিয়োগ করতে রাজি নয়।

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

আমরা আপনার প্রকল্পের ব্যর্থতার প্রভাব জানি না, সুতরাং 92% বা 95% যথেষ্ট, বা যদি 100% সত্যই প্রয়োজন হয় তা আমরা বলতে পারি না। বা এই ক্ষেত্রে, 100% আপনি যা আশা করেন তা পুরোপুরি পরীক্ষা করে।

30

... এবং আপনার 100% কোড কভারেজ থাকার অর্থ এই নয় যে আপনার 100% শাখা কভারেজ রয়েছে, সুতরাং 100% কোডের কভারেজ সহ আপনিও খুব বেশি অনুপস্থিত হতে পারেন।

— ব্রায়ান ওকলে

3

প্রকল্পের আকারের জন্য +1। আরও ছোট, পুনরায় ব্যবহারযোগ্য এবং টেস্টযোগ্য উপাদানগুলিতে ভাঙ্গার ফলে আমরা আমাদের ~ 95% কভারেজ অর্জন করতে পেরেছি। 100% কভারেজ প্রয়োজন হয় না। সংহতকরণ পরীক্ষার ইউনিট পরীক্ষার ফাঁকগুলি আবরণ করা উচিত।

— অপুরভ খুরসিয়া

5

@ ব্রায়ানওকলে ... এবং আপনার পরীক্ষাগুলি অর্থহীন হতে পারে, এমনকি কোনও কিছুর

— পরীক্ষাও করা যায়

5

@ ব্রায়ানওকলে এবং এমনকি ১০০% শাখার কভারেজ থাকা সত্ত্বেও, সম্ভবত কিছু নির্দিষ্ট শাখার সমন্বয় সমস্যা তৈরি করতে পারে cause (দুই অনুক্রমিক বিবৃতি, উদাহরণস্বরূপ, মধ্যে এবং পৃথক পরীক্ষায় প্রায় শাখা যদি দিতে পারে, তবে একটা পরীক্ষা যে প্রবেশ অনুপস্থিত উভয় ফুল শাখা কভারেজ, এখনো এক মৃত্যুদন্ড পথ মিস হয়।)

— Izkata

4

এমনকি সকল কার্যকরকরণের পাথ সহ 100% শাখা কভারেজ যথেষ্ট নয়। সম্ভবত কিছু ত্রুটি তখনই ঘটে যখন আপনি কিছু শাখা সংমিশ্রণ গ্রহণ করেন এবং আপনার কিছু বাহ্যিক ইনপুট থাকে, একটি ত্রুটিযুক্ত তারিখ বলুন। সব ক্ষেত্রেই কভার হওয়ার সম্ভাবনা নেই। একই সময়ে, একজনের 100% এরও কম কভারেজের সাথে একটি ভাল আত্মবিশ্বাস থাকতে পারে তবে উপযুক্তভাবে ইনপুট হিসাবে প্রান্তের কেস বেছে নেওয়া হয়।

— Andrea

32

কে পরীক্ষা দেয়?

এটা খুবই হল সরল শ্রেষ্ঠ সময়ে এবং অবাস্তব এমনকি তাত্ত্বিক অর্থে এবং অকার্যকর একটি ব্যবসা অর্থে।

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

কোডের প্রতিটি লাইন পরীক্ষা করা ভাল লক্ষ্য নয়

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

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

বিলম্ব সমস্যা:

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

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

যেহেতু আপনি প্রমাণ করতে পারবেন না যে কোনও কিছু 100% কাজ করে কেন এটি আপনার লক্ষ্য?

সাধারণ এবং সরল, বেশিরভাগ ক্ষেত্রে এটি কোনও ব্যবসায়িক ধারণা তৈরি করে না।

7

এটি সত্যই গ্রহণযোগ্য উত্তর হওয়া প্রয়োজন। 100% কোড কভারেজ প্রায় 0% এর মতো খারাপ।

— রায়থাল

1

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

— এখনও_ড্রিমিং_1

2

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

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

— প্রেড্রাগ স্টোজাদিনোভিও

17

বেশিরভাগ ক্ষেত্রে, 100% কোডের কভারেজের অর্থ হল আপনি কিছুটা "প্রতারণা" করেছেন:

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

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

— ড্যান মোনেগো
সূত্র

কীভাবে জিনিসগুলি ডিএসএলে প্রতারণা করছে?

— back2dos

2

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

— ড্যান মোনেগো

12

100% শাখা কভারেজের একটি চিত্তাকর্ষক, বাস্তব বিশ্বের উদাহরণের জন্য , দেখুন এসকিউএলাইট কীভাবে পরীক্ষিত হয় ।

আমি বুঝতে পারি যে আপনার প্রশ্নটি জাভাস্ক্রিপ্ট সম্পর্কে বিশেষভাবে জিজ্ঞাসা করেছে যা সম্পূর্ণ ভিন্ন ধরণের সফ্টওয়্যার পণ্য, তবে আমি যথেষ্ট প্রেরণা দিয়ে কী করা যায় সে সম্পর্কে সচেতনতা আনতে চাই।

— ব্রায়ান ওকলে
সূত্র

9

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

থাম্বের একটি ভাল নিয়ম আপনার ব্যবসায়ের সমস্ত যুক্তির 100% কোড কভারেজ হওয়া উচিত। তবে যে টুকরোগুলি বাহ্যিক উপাদানগুলি চালিত করতে হবে, তার যতটা সম্ভব 100% কোড কভারেজ হওয়া উচিত। আপনি যদি না পৌঁছতে পারেন তবে আমি এটি খুব বেশি ঘামও না।

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

— bwalk2895
সূত্র

1

আপনি যখন ত্রুটিযুক্ত মামলার বিস্ময়কর সংমিশ্রণ এবং সাড়া-ব্যর্থতার প্রতিক্রিয়াগুলি পান তখন কী হয় তা পরীক্ষা করা ব্যতিক্রমী জটিল হতে পারে।

— ডোনাল ফেলো

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

— পিটার স্মিথ

এটি আপনার unit testingসাথে integration testingলিখিত নয়, যা আপনি লেখেন নি সেই পরীক্ষার কোডটি integrationপরীক্ষা করছে। টিসিপি স্ট্যাকটি ওএসে রয়েছে আপনার এটি পরীক্ষা করা উচিত নয়, আপনি ধরে নিতে পারেন এটি ইতিমধ্যে কার দ্বারা লিখেছিল তা এটি ইতিমধ্যে পরীক্ষা করা হয়েছে।

4

আমি বলব যে যদি 100% পরীক্ষার কভারেজের অনুমতি দেওয়ার নির্দিষ্ট লক্ষ্য নিয়ে কোডটি তৈরি না করা হয়, তবে 100% অর্জনযোগ্য হতে পারে না। এর অন্যতম কারণ হ'ল আপনি যদি ডিফেন্সিভালি কোড করেন - যা আপনার হওয়া উচিত - আপনার মাঝে মাঝে এমন কোড থাকা উচিত যা পরিস্থিতি পরিচালনা করে যা আপনি নিশ্চিত হন যে সিস্টেমটি আপনার জ্ঞানের ভিত্তিতে ঘটবে না বা ঘটবে না। পরীক্ষার সাথে এই জাতীয় কোডটি কভার করা সংজ্ঞা অনুসারে খুব শক্ত হবে। এই জাতীয় কোড না রাখা বিপজ্জনক হতে পারে - যদি আপনি ভুল হয়ে থাকেন এবং 256 এর মধ্যে একবারে এই পরিস্থিতি ঘটে? অসম্পূর্ণ জায়গায় এমন কোনও পরিবর্তন ঘটে যা অসম্ভবকে সম্ভব করে তোলে? ইত্যাদি। সুতরাং "প্রাকৃতিক" অর্থের মাধ্যমে 100% পৌঁছনো বরং কঠিন হতে পারে - যেমন, আপনার যদি মেমরি বরাদ্দকারী কোড থাকে এবং আপনার কোড রয়েছে যা এটি ব্যর্থ হয়েছে কিনা তা পরীক্ষা করে থাকে, যদি না আপনি মেমোরি ম্যানেজারকে উপহাস না করেন (যা সহজ নাও হতে পারে) এবং এমন একটি পরীক্ষা লিখুন যা "মেমোরি থেকে সরে যায়", সেই কোডটি আচ্ছাদন করা কঠিন হতে পারে। জেএস অ্যাপ্লিকেশনের জন্য, এটি বিভিন্ন ব্রাউজারগুলিতে সম্ভাব্য ডিওএম কিরকস, বাহ্যিক পরিষেবাদির সম্ভাব্য ব্যর্থতা ইত্যাদির আশেপাশে প্রতিরক্ষামূলক কোডিং হতে পারে etc.

সুতরাং আমি বলব যে একজনের যতটা সম্ভব 100% এর কাছাকাছি থাকার জন্য প্রচেষ্টা করা উচিত এবং ব-দ্বীপের একটি ভাল কারণ থাকতে হবে তবে আমি অবশ্যই ব্যর্থতা হিসাবে সঠিকভাবে 100% পাচ্ছি না। ৫% কী হয় তার উপর নির্ভর করে একটি বড় প্রকল্পে 95% জরিমানা হতে পারে।

— StasM
সূত্র

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

— এখনও_ড্রিমিং_1

2

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

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

আপনি যদি কোনও বিদ্যমান প্রকল্পে পরীক্ষা চালিয়ে যাচ্ছেন যেখানে পরীক্ষা চালিয়ে যাওয়া বা এর আগে অন্তর্ভুক্ত করা হয়নি তবে অনুশীলনের ব্যয় ছাড়াই 100% কোড কভারেজ পাওয়া অসম্ভব। আপনি যে সর্বোত্তম আশা করতে পারেন তা হ'ল কোডের সমালোচনামূলক বিভাগগুলির জন্য পরীক্ষা কভারেজ সরবরাহ করা যা সর্বাধিক বলা হয়।

যখন জাভাস্ক্রিপ্ট / জকোয়ারিতে প্রকৃত কোড কভারেজ 92% -95% এর আশেপাশে থাকে তখন 100% কভারেজ পূরণ না হওয়ার কারণে স্প্রিন্টে ব্যর্থ হওয়া কি যুক্তিসঙ্গত?

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

— S.Robins
সূত্র

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

— এখনও_ড্রিমিং_1

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

— এসরোবিনস

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

— এখনও_ড্রিমিং_1

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

— এখনও_ড্রিমিং_1

1

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

এমন কোনও বাধা আছে যার মুখোমুখি হচ্ছেন যা আপনাকে সেই শেষ কয়েকটি লাইনে আঘাত করতে বাধা দিচ্ছে? যদি তা না হয়, যদি 95% থেকে 100% কভারেজটি পাওয়া সোজা হয়, তাই আপনিও এটি করতে পারেন। আপনি এখানে বলছি সাল থেকে আমি অনুমান করা যে যাচ্ছি হয় কিছু। এটা কি কিছু?

— mjfgates
সূত্র

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

— এখনও_ড্রিমিং_1

0

92% ঠিক আছে। আমি অনুভব করি যে আসল প্রশ্নগুলি হ'ল:

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

— মাইকেল ডুরান্ট
সূত্র

"সফটওয়্যারটি কাজ করা এবং বাগগুলি না থাকা কতটা গুরুত্বপূর্ণ"? ভাল প্রশ্ন. বাগের সংজ্ঞা কী? উদ্দেশ্য মতো কাজ করে না এমন কিছু। যদি কিছু কোড সঠিকভাবে কাজ না করে তবে এটি লিখবেন না। কোডের পুরো পয়েন্টটি এটির কাজ করার জন্য।

— এখনও_ড্রিমিং_1

0

মার্টিন ফোলার তার ব্লগে লিখেছেন :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

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

পাঠের কয়েকটি:

100% কভারেজ অস্বাভাবিক তবে অর্জনযোগ্য
100% কভারেজ কখনও কখনও প্রয়োজন হয়
100% কভারেজ নতুন ঝুঁকি নিয়ে আসে
100% মেট্রিকের জন্য অনুকূলিত হন না
কভারেজ সর্বাধিকতর করার জন্য একটি সঠিক কৌশল বিকাশ করুন
100% কভারেজ ভাল মানের জন্য পর্যাপ্ত শর্ত নয়

— user6681109
সূত্র

0

সম্ভবত জিজ্ঞাসা করা সম্ভব এবং যুক্তিযুক্ত কিনা জিজ্ঞাসা করা সবচেয়ে সহায়ক প্রশ্ন নয়। সম্ভবত সবচেয়ে ব্যবহারিক উত্তর হ'ল গৃহীত উত্তর। আমি এটি আরও দার্শনিক স্তরে বিশ্লেষণ করব।

100% কভারেজ আদর্শ হবে, তবে আদর্শভাবে এটির প্রয়োজন হবে না বা এটি অর্জন করা আরও সহজ হবে। আমি এটি সম্ভাব্য বা যুক্তিসঙ্গত চেয়ে প্রাকৃতিক এবং মানব কিনা তা নিয়ে ভাবতে পছন্দ করি।

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

100% কোড কভারেজ অর্জন করা একটি অপ্রাকৃত কাজ। বেশিরভাগ লোকের জন্য, তাদের এ অর্জন করতে বাধ্য করা নির্যাতনের এক প্রকার হবে।

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

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

কোডিংকে আরও প্রাকৃতিক করার জন্য এখানে কয়েকটি চেষ্টা করা হয়েছে:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

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

— still_dreaming_1
সূত্র

-2

নতুন কোডে 100% পৌঁছানো খুব সহজ হবে এবং আপনি যদি টিডিডি অনুশীলন করেন তবে আপনি সম্ভবত ডিফল্টরূপে আঘাত হবেন কারণ আপনি খুব ইচ্ছাকৃতভাবে প্রোডাকশন কোডের প্রতিটি লাইনের জন্য পরীক্ষা লিখছেন।

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

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

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

— রিচার্ড ওয়েলস
সূত্র

-3

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

— veryfoolish
সূত্র

উহু! তাই কেউ বিরক্ত হয়েছেন যে আমি এর ধারণার প্লেনে সমস্যার উত্তর দিলাম না; পরীক্ষা নিরর্থক ... আমি জনপ্রিয় না এটি যত্নশীল না। এটি কখনই কাজ করবে না। এটা হতে পারে না. বুদ্ধিমান কম্পিউটার বিজ্ঞানীরা এটি জানেন (ডিজকস্ট্রা, নুথ, হোয়ার এট আল।) আমি অনুমান করি আপনি যদি কোনও জাভাস্ক্রিপ্ট প্রোগ্রামার হফিং এক্সট্রিম প্রোগ্রামিং হন তবে আপনি সেই ক্র্যাঙ্কগুলির বিষয়ে চিন্তা করবেন না। বেলা, যাই হোক না কেন, কে পাত্তা দেয় ... ক্রিপি কোড লিখুন। আপনার পরীক্ষা চালাচ্ছে বর্জ্য CO ^ 2। - মানে, বসে বসে ভাববার আর কে আছে? আমরা এটি কম্পিউটারে রফতানি করেছি।

— বোকা

3

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

— লুনিভোর