টিডিডি কি ডিফেন্সিভ প্রোগ্রামিংকে অপ্রয়োজনীয় করে তোলে?

104

আজ আমার এক সহকর্মীর সাথে একটি আকর্ষণীয় আলোচনা হয়েছিল।

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

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

এটি কি সত্য যে টিডিডি প্রতিরক্ষা প্রোগ্রামিং প্রতিস্থাপন করতে সক্ষম? প্যারামিটারের বৈধতা (এবং আমি ব্যবহারকারীর ইনপুট বলতে চাই না) এর ফলে কি অপ্রয়োজনীয়? নাকি দুটি কৌশল একে অপরের পরিপূরক?

tdd defensive-programming

— user2180613
সূত্র

120

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

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

42

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

— উদ্যানক্ষেত্র

37

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

— ক্রেগ

16

"ইউনিট পরীক্ষাগুলিতে শ্রেণীর কোনও ভুল ব্যবহার ধরা উচিত" - আহ, কীভাবে? ইউনিট পরীক্ষাগুলি আপনাকে সঠিক যুক্তি প্রদত্ত আচরণ এবং যখন ভুল যুক্তি দেওয়া হয় তা দেখায়; এটি আপনাকে দেওয়া সমস্ত যুক্তি প্রদর্শন করতে পারে না show

— ওজেফোর্ড

34

আমি মনে করি না যে আমি সফ্টওয়্যার বিকাশ সম্পর্কে ধর্মান্ধ চিন্তাভাবনা কীভাবে ক্ষতিকারক সিদ্ধান্তে নিয়ে যেতে পারে তার একটি আরও ভাল উদাহরণ দেখেছি।

— এসডেনহ্যাম

196

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

কোনও পদ্ধতিই ব্যবহারকারীদের সঠিকভাবে কোড ব্যবহার করতে বাধ্য করতে পারে না।

সেখানে হয় আপনি চেক যোগ সম্ভবত দ্বারা - সামান্য যুক্তি তৈরি করা যে আপনি একটি পরীক্ষা ক্ষেত্রে আপনার> 0 চেক ধরা যদি আপনি পুরোপুরি TDD- এ করেনি যেত, পূর্বে এটি বাস্তবায়নে, এবং এই সম্বোধন। তবে আপনি যদি টিডিডি করেন, আপনার প্রয়োজনীয়তা (> কনস্ট্রাক্টরে 0 0) প্রথমে ব্যর্থ হওয়া টেস্টকেস হিসাবে উপস্থিত হবে ails এভাবে আপনি আপনার চেক যুক্ত করার পরে আপনাকে পরীক্ষা দিচ্ছেন।

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

নাকি দুটি কৌশল একে অপরের পরিপূরক?

টিডিডি পরীক্ষাগুলি বিকাশ করবে। প্যারামিটারের বৈধতা প্রয়োগ করে তাদের পাস করবে।

— enderland
সূত্র

7

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

— ব্যবহারকারী 2180613

20

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

— আরএম

4

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

— ক্রেগ

@ ইউজার 2180613 এটি দুর্দান্ত কিছু সমর্থনযোগ্যতা: ডি যদি সফ্টওয়্যার লেখার ক্ষেত্রে আপনার লক্ষ্যটি লেখক এবং চালনার জন্য আপনার প্রয়োজনীয় পরীক্ষাগুলির সংখ্যা হ্রাস করে তবে কোনও সফ্টওয়্যার লিখবেন না - শূন্য পরীক্ষা!

— গুসডোর

3

এই উত্তর এর শেষ বাক্য এটি নখ।

— রবার্ট গ্রান্ট

32

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

তথ্য সুরক্ষায়, এটিকে ডিফেন্স ইন ডিপথ বলে। একাধিক স্তর প্রতিরক্ষা থাকা নিশ্চিত করে যে যদি কেউ ব্যর্থ হয় তবে অন্যরা এখনও তা ধরতে পারে।

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

— কেভিন ফি
সূত্র

পরামিতি বৈধতা পূর্বশর্ত বৈধতার একটি ফর্ম এবং ইউনিট টেস্টগুলি পোস্টকন্ডিশন বৈধতা যা বলা একেবারেই সঠিক? কারণ তারা একে অপরের পরিপূরক?

— ব্যবহারকারী 2180613

1

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

— jpmc26

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

— পেরিটা ব্রেটা

1

@ jpmc26 হ্যাঁ, ব্যর্থতা হচ্ছে পরীক্ষার "প্রত্যাশিত ফলাফল"। আপনি নিখুঁতভাবে কিছু অপরিজ্ঞাত (অপ্রত্যাশিত) আচরণ প্রদর্শন না করে এটি ব্যর্থ হওয়ার তা পরীক্ষা করে দেখেন।

— কেআরিয়ান

6

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

— জেগে উঠছেন

30

টিডিডি একেবারে ডিফেন্সিভ প্রোগ্রামিং প্রতিস্থাপন করে না। পরিবর্তে, আপনি সমস্ত প্রতিরক্ষা স্থানে রয়েছেন এবং আশানুরূপভাবে কাজ করে তা নিশ্চিত করতে আপনি টিডিডি ব্যবহার করতে পারেন।

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

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

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

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

— আমন
সূত্র

16

প্রতিরক্ষামূলক প্রোগ্রামিং সমর্থন এবং নিশ্চিত করার জন্য টেস্ট রয়েছে

ডিফেন্সিভ প্রোগ্রামিং রানটাইমের সময় সিস্টেমের অখণ্ডতা রক্ষা করে।

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

সম্পাদনা: একটি সাদৃশ্য

কোডে মন্তব্যে সাদৃশ্য সম্পর্কে কী?

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

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

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

পরীক্ষাগুলি সিস্টেমের আচরণ যাচাই করে। প্রকৃত আচরণটি সিস্টেমের মধ্যেই অন্তর্নিহিত, পরীক্ষাগুলির সাথে অন্তর্নিহিত নয় ।

সম্ভাব্য ভুল গুলো কী কী হতে পারতো?

পরীক্ষাগুলি সংক্রান্ত লক্ষ্যটি হ'ল যা ভুল হতে পারে তার সমস্ত চিন্তাভাবনা করা, এর জন্য একটি পরীক্ষা লিখুন যা সঠিক আচরণের জন্য পরীক্ষা করে, তারপরে রানটাইম কোডটি তৈরি করে যাতে এটি সমস্ত পরীক্ষায় পাস করে।

যার অর্থ প্রতিরক্ষামূলক প্রোগ্রামিং হ'ল মূল বিষয় ।

পরীক্ষাগুলি বিস্তৃত হলে টিডিডি ডিফেন্সিভ প্রোগ্রামিং চালায় ।

আরও পরীক্ষা, আরও প্রতিরক্ষামূলক প্রোগ্রামিং ড্রাইভিং

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

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

সাধারণভাবে বলতে ...

উদাহরণস্বরূপ, যদি কোনও নির্দিষ্ট পদ্ধতির নাল যুক্তি অবৈধ হয়, তবে কমপক্ষে একটি পরীক্ষা শূন্য হতে চলেছে এবং এটি কোনও "অবৈধ নাল যুক্তি" ব্যতিক্রম / ত্রুটিটি প্রত্যাশা করে চলেছে।

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

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

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

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

বিশেষত যদি সেই অন্যান্য সিস্টেমের প্রোগ্রামাররা রক্ষণাত্মকভাবে কোড না করে থাকে।

— ক্রেইগ
সূত্র

2

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

— ক্রেগ

1

:-) আমি প্রথম অনুচ্ছেদের বাইরে না পড়েই আপ-ভোট দিয়েছি, তাই আশা করি এটি সুষম হবে ...

— সুসানডাব্লু

1

অন্তত আমি :-) করতে পারে করলো (আসলে, আমি না ঠিক নিশ্চিত করার জন্য বাকি পড়তে পঙ্কিল না হওয়া আবশ্যক -। বিশেষ করে এই মত একটি বিষয়ে)

— SusanW

1

আমি ভেবেছিলাম আপনার সম্ভবত ছিল। :)

— ক্রেগ

কোড কনট্রাক্টসের মতো সরঞ্জামগুলি সংকলন সময়ে ডিফেন্সিভ চেকগুলি করা যেতে পারে।

— ম্যাথু হোয়াইট

9

টিডিডি এর পরিবর্তে আসুন সাধারণভাবে "সফ্টওয়্যার টেস্টিং", এবং সাধারণভাবে "ডিফেন্সিভ প্রোগ্রামিং" এর পরিবর্তে, আসুন প্রতিরক্ষামূলক প্রোগ্রামিংয়ের আমার প্রিয় পদ্ধতি সম্পর্কে কথা বলা যাক, যা দৃ as়তার সাথে ব্যবহার করে।

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

জোর দেওয়া optionচ্ছিক, সুতরাং যদি আপনি সেগুলি পছন্দ না করেন তবে কেবলমাত্র আপনার সিস্টেমটি অক্ষম অক্ষরে অক্ষরে চালিত করুন।
পরীক্ষাগুলি পরীক্ষা করে না এমন জিনিসগুলি পরীক্ষা করে (এবং করা উচিত নয়)) কারণ পরীক্ষার মাধ্যমে আপনার সিস্টেমের একটি ব্ল্যাক-বক্স ভিউ রয়েছে বলে মনে করা হচ্ছে, যখন জোর দিয়ে শ্বেত-বাক্সের ভিউ রয়েছে। (অবশ্যই, যেহেতু তারা এতে বাস করে))
জোর দেওয়া একটি দুর্দান্ত ডকুমেন্টেশন সরঞ্জাম। কোনও মন্তব্যই কখনও একই বিষয়টিকে দৃser়ভাবে প্রমাণ করার মতো কোডের টুকরো হিসাবে পরিষ্কার বা কখনও হবে না। এছাড়াও, কোডটি বিকশিত হওয়ার সাথে সাথে ডকুমেন্টেশনগুলি পুরানো হয়ে যায় এবং এটি কোনওভাবেই সংকলক দ্বারা প্রয়োগযোগ্য নয়।
যুক্তিগুলি পরীক্ষার কোডে ত্রুটিগুলি ধরতে পারে। আপনি কি কখনও এমন পরিস্থিতিতে পড়েছেন যেখানে কোনও পরীক্ষা ব্যর্থ হয় এবং আপনি জানেন না কে ভুল - প্রডাকশন কোড, বা পরীক্ষা?
জোর দেওয়া পরীক্ষার চেয়ে প্রাসঙ্গিক হতে পারে। পরীক্ষাগুলি কার্যকরী প্রয়োজনীয়তাগুলির দ্বারা নির্ধারিত যা তা পরীক্ষা করে দেখবে, তবে কোডটি প্রায়শই এমন কিছু ধারণা অনুমান করতে হয় যা তার চেয়ে অনেক বেশি প্রযুক্তিগত। ফাংশনাল প্রয়োজনীয় ডকুমেন্টগুলি লেখেন এমন লোকেরা খুব কমই শূন্য দ্বারা বিভাগের কথা ভাবেন।
জোর পয়েন্টপয়েন্ট ত্রুটিগুলি যা পরীক্ষাগুলি কেবলমাত্র বিস্তৃতভাবে ইঙ্গিত করে। সুতরাং, আপনার পরীক্ষাটি কিছু বিস্তৃত পূর্বশর্ত সেট আপ করে, কোডের দীর্ঘতর টুকরো আহ্বান করে, ফলাফলগুলি সংগ্রহ করে এবং আবিষ্কার করে যে সেগুলি প্রত্যাশার মতো নয়। পর্যাপ্ত সমস্যা সমাধানের ফলে আপনি অবশেষে ঠিক কোথায় আবিষ্কার করবেন তা আবিষ্কার করতে পারেন, তবে জোর দেওয়া সাধারণত সাধারণত এটি খুঁজে পাবেন।
জোর দিয়ে প্রোগ্রামের জটিলতা হ্রাস করে। আপনার লেখা প্রতিটি কোডের লাইনের ফলে প্রোগ্রামের জটিলতা বাড়ে। সংক্ষেপে এবং final( readonly) কীওয়ার্ডটি কেবলমাত্র দুটি নির্মাণ যা আমি জানি যে এটি আসলে প্রোগ্রামের জটিলতা হ্রাস করে। অমূল্য।
সংস্থাগুলি আপনার কোডটির আরও ভাল ধারণা তৈরি করতে সহায়তা করে। দয়া করে বাড়িতে এটি ব্যবহার করে দেখুন: void foo( Object x ) { assert x != null; if( x == null ) { } }আপনার সংকলকটি একটি সতর্কতা জারি করা উচিত যা আপনাকে জানায় যে শর্তটি x == nullসর্বদা মিথ্যা। এটি খুব দরকারী হতে পারে।

উপরের অংশটি ছিল আমার ব্লগের একটি পোস্টের সংক্ষিপ্তসার, 2014-09-21 "দাবি ও পরীক্ষার"

— মাইক নকিস
সূত্র

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

— আমন

5

"টিডিডিতে টেস্ট স্যুটটি হ'ল স্পেসিফিকেশন You're পরীক্ষাগুলি পাস করার জন্য আপনার সবচেয়ে সহজ কোডটি লেখার কথা ছিল, এর চেয়ে বেশি কিছুই নয়" ": আমি মনে করি না এটি সর্বদা একটি ভাল ধারণা: উত্তরে যেমন উল্লেখ করা হয়েছে, সেখানে রয়েছে কোডটিতে অতিরিক্ত অভ্যন্তরীণ অনুমান যা একজন যাচাই করতে চাইতে পারে। একে অপরকে বাতিল করে এমন অভ্যন্তরীণ বাগগুলি সম্পর্কে কী? আপনার পরীক্ষাগুলি পাস হয়েছে তবে আপনার কোডের ভিতরে কয়েকটি অনুমান ভুল রয়েছে, যা পরে कपटी বাগগুলি নিয়ে যেতে পারে।

— জর্জিও

5

আমি বিশ্বাস করি বেশিরভাগ উত্তর একটি গুরুত্বপূর্ণ পার্থক্য হারিয়েছে: এটি আপনার কোড কীভাবে ব্যবহৃত হবে তার উপর নির্ভর করে।

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

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

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

— JacquesB
সূত্র

4

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

— পিটারিস

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

— জ্যাকবিবি

3

এটি কেবলমাত্র ক্ষুদ্রতম দোকানে কাজ করবে। আপনার দলটি অতিক্রম করার পরে, ছয় জনকে বলুন, আপনাকে যাইহোক বৈধতা যাচাই করতে হবে।

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

1

@ রবার্টহারভে: সেক্ষেত্রে সিস্টেমটি উপ-সিস্টেমে সু-সংজ্ঞায়িত ইন্টারফেস, এবং ইন্টারফেসে ইনপুট বৈধতা সহ পার্টিশন করা উচিত।

— জ্যাকবিবি

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

— আলেকসান্দার ফুলার

3

এই যুক্তি সাজানোর ধরণটি আমাকে বিভ্রান্ত করে, কারণ যখন আমি টিডিডি অনুশীলন শুরু করেছি তখন আমার ফর্মের "ইউনিট পরীক্ষাগুলি <নির্দিষ্ট উপায়> যখন <অবৈধ ইনপুট>" 2 বা 3 বার বৃদ্ধি পেয়ে সাড়া দেয়। আমি ভাবছি যে কীভাবে আপনার সহকর্মী তার কার্যকারিতা যাচাই না করে সফলভাবে এই জাতীয় ইউনিট পরীক্ষায় সফলভাবে পরিচালনার জন্য পরিচালনা করছেন।

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

অন্য কথায়, কি TDD- এ থেকে আপনাকে আটকাবে না যায় কেমনে প্রয়োজন যতটা বৈধতা কোড সাহায্যের আপনি এড়াতে যেমন বিস্মরণ করুন।

— কার্ল বিলেফেল্ট
সূত্র

2

আমি মনে করি আমি আপনার সহকর্মীর মন্তব্যের বাকী উত্তরগুলির বেশিরভাগের চেয়ে আলাদাভাবে ব্যাখ্যা করি।

আমার কাছে মনে হয় যুক্তিটি হ'ল:

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

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

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

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

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

— স্টিভ জেসোপ
সূত্র

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

— ক্রেগ

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

— স্টিভ জেসপ

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

— ক্রেগ

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

— ক্রেগ

1

পাবলিক ইন্টারফেসগুলি অপব্যবহার করতে পারে এবং হবে

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

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

— পিটার হচ্ছে
সূত্র

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

— ক্রেগ

1

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

বৈশিষ্ট্যটির পরীক্ষা করা দরকার: অপব্যবহারের বিরুদ্ধে প্রতিরক্ষা কি আসলে কাজ করে? এই বৈশিষ্ট্যটি পরীক্ষা করার লক্ষ্যটি এটি দেখানোর চেষ্টা করা হয়: এটি মডিউলটির কিছু ভুল-ব্যবহারের জন্য যা এটির পরীক্ষায় ধরা পড়ে না।

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

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

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

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

যদি এটির চুক্তি লঙ্ঘন করা হয়, তবে এটি ব্যতিক্রম বা যা কিছু নিক্ষেপ করে নিম্ন-স্তরের ফাংশনগুলির কিছু অপব্যবহারে অনুবাদ করবে।

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

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

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

— Kaz
সূত্র

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

— সুপারক্যাট

1

পরীক্ষাগুলি আপনার শ্রেণির চুক্তিটি সংজ্ঞায়িত করে।

বাস্তব হিসাবে, পরীক্ষার অনুপস্থিতি একটি চুক্তি সংজ্ঞায়িত করে যার মধ্যে অপরিজ্ঞাত আচরণ অন্তর্ভুক্ত । সুতরাং আপনি যখন অতিক্রম nullকরবেন Foo::Frobnicate(Widget widget)এবং অকালীন রান-টাইম বিপর্যয় অনুভূত হবে, আপনি এখনও আপনার শ্রেণির চুক্তির মধ্যে রয়েছেন।

পরে আপনি সিদ্ধান্ত নিন, "আমরা অপরিজ্ঞাত আচরণের সম্ভাবনা চাই না", এটি একটি বোধগম্য পছন্দ। তার মানে আপনার কাছে যাওয়ার জন্য একটি প্রত্যাশিত আচরণ nullথাকতে হবে Foo::Frobnicate(Widget widget)।

এবং আপনি এই সিদ্ধান্তটি নথিভুক্ত করে একটি

[Test]
void Foo_FrobnicatesANullWidget_ThrowsInvalidArgument() 
{
    Given(Foo foo);
    When(foo.Frobnicate(null));
    Then(Expect_Exception(InvalidArgument));
}

— Caleth
সূত্র

1

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

সম্পূর্ণরূপে ইউনিট-পরীক্ষিত পদ্ধতির মাধ্যমে যে ধরণের ডিফেন্সিভ প্রোগ্রামিং অপসারণ করা যায় তা হ'ল অভ্যন্তরীণ আক্রমণকারীদের অপ্রয়োজনীয় বৈধতা যা বাহ্যিক কোড দ্বারা লঙ্ঘন করা যায় না।

একটি দরকারী ধারণা যা আমি মাঝে মাঝে নিযুক্ত করি তা হ'ল একটি পদ্ধতি সরবরাহ করা যা বস্তুর আক্রমণকারীদের পরীক্ষা করে; আপনার টিয়ার-ডাউন পদ্ধতিটি যাচাই করার জন্য এটি কল করতে পারে যে বস্তুর উপর আপনার বাহ্যিক ক্রিয়াগুলি কখনই আক্রমণকারীদের বিরতি দেয় না।

— টবির গতি
সূত্র

0

টিডিডি পরীক্ষাগুলি কোডের বিকাশের সময় ভুলগুলি ধরবে ।

প্রতিরক্ষামূলক প্রোগ্রামিংয়ের অংশ হিসাবে আপনি যে সীমানা পরীক্ষা করছেন তা কোড ব্যবহারের সময় ভুলগুলি ধরবে ।

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

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

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

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

— কালো বাজপাখি
সূত্র

1

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

— ক্রেগ

@ ক্রেইগ আমি যুক্ত করা সুনির্দিষ্ট উদাহরণে আপনার মতামত জানতে আগ্রহী।

— ব্ল্যাকহক

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

— ক্রেগ

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

— ক্রেগ

1

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

— ক্রেগ

0

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

এম্বেড ইঞ্জিনিয়ার হিসাবে, আমি কেবল দুটি বাইট একসাথে যুক্ত করতে এবং ফাংশনটি লেখার উদাহরণটি ব্যবহার করতে চাই:

uint8_t AddTwoBytes(uint8_t a, uint8_t b, uint8_t *sum);

এখন আপনি যদি কেবল এটি করেন তবে *(sum) = a + bএটি কাজ করবে তবে কেবল কিছু ইনপুট দিয়ে। a = 1এবং b = 2করতে হবে sum = 3; তবে কারণ সমষ্টি আকার একটি বাইট, a = 100এবং b = 200হবে sum = 44ওপর দিয়ে বইয়ে কারণে। সি, আপনি এই ক্ষেত্রে ত্রুটি ফিরিয়ে ফাংশন ব্যর্থ চিহ্নিত করতে হবে; একটি ব্যতিক্রম ছোঁড়া আপনার কোড একই জিনিস। ব্যর্থতা বিবেচনা না করা বা কীভাবে এগুলি পরিচালনা করতে হবে তা পরীক্ষা করা দীর্ঘমেয়াদী কাজ করবে না, কারণ যদি এই শর্তগুলি ঘটে থাকে তবে সেগুলি পরিচালনা করা হবে না এবং এতে অনেকগুলি সমস্যা দেখা দিতে পারে।

— ডোম
সূত্র

এটি দেখতে একটি ভাল সাক্ষাত্কার-প্রশ্নের উদাহরণের মতো (কেন এটির ফেরতের মান এবং "আউট" পরামিতি থাকে - এবং sumনাল পয়েন্টার হলে কী ঘটে ?)।

— টবি স্পিড