তাই কি? হতে পারে. আমার মতামতটি হ'ল এটি সাধারণত বিনোদন সফ্টওয়্যারগুলির জন্য খুব খারাপ ফিট করে তোলে যদিও এটি নিম্ন স্তরের গ্রন্থাগারগুলির জন্য ভাল কাজ করতে পারে।
সম্পাদনা: আমার মতের জন্য এখানে কিছু ন্যায়সঙ্গততা রয়েছে।
উইকিপিডিয়া বিডিডিকে এমন একটি প্রযুক্তি হিসাবে সংজ্ঞায়িত করে যা "সফ্টওয়্যার প্রকল্পের বিকাশকারী, কিউএ এবং নন-টেকনিক্যাল বা ব্যবসায় অংশগ্রহণকারীদের মধ্যে সহযোগিতা উত্সাহ দেয়।" এটি ইতিমধ্যে একটি খারাপ ধারণা বলে মনে হচ্ছে কারণ বেশিরভাগ সফ্টওয়্যার থেকে গেমগুলি পৃথক হয় কারণ তারা 'অ-প্রযুক্তিগত বা ব্যবসায়িক অংশগ্রহণকারী' এর নির্দিষ্ট প্রয়োজন মেটাতে সরঞ্জাম হিসাবে নকশাকৃত নয়, তবে বিনোদনের জন্য নকশাকৃত সমন্বিত কাজ are "কাঙ্ক্ষিত সফ্টওয়্যার আচরণ" এর উপর জোর দেওয়া হয় তবে গেমগুলির প্রযুক্তিগত স্তর ব্যতীত খুব কমই 'কাঙ্ক্ষিত সফ্টওয়্যার আচরণ' থাকে। কোডটির সেই অংশটি যাচাই করার ক্ষেত্রে অবশ্যই যোগ্যতা রয়েছে তবে শেষ ব্যবহারকারীর সাথে নয়, কারণ তারা এটি কখনই দেখবে না।
তবে ধরে নেওয়া যাক যে আপনি সেই মানব স্টেকহোল্ডার স্টাফ ফেলে দিতে চান এবং বিভিন্ন কোড মডিউলগুলির মধ্যে চুক্তি প্রয়োগ করতে কেবল বিডিডি ব্যবহার করেন, যা আমি দেখতে পাচ্ছি সাধারণ পরীক্ষা-চালিত বিকাশের চেয়ে অনেক বেশি আলাদা নয়, যা আমি দুর্বল বিবেচনাও করি- নিম্নলিখিত কারণে গেমগুলির জন্য উপযুক্ত।
টেস্টগুলি প্রত্যাশিত হওয়ার পরে বিচ্ছিন্ন ঘটনাগুলি যাচাই করার জন্য দরকারী। এটি ইভেন্ট-চালিত প্রোগ্রামিংয়ে, যেমন ভাল কাজ করে। বেশিরভাগ সফ্টওয়্যার ওয়ার্ল্ড, যেখানে কোনও ক্রিয়া সঞ্চালিত হয়, কিছু আউটপুট উত্পন্ন হয় এবং তারপরে আপনি কেবল যাচাই করে নিন যে ক্রিয়া এবং ফলাফলের মিল রয়েছে। যাইহোক, গেম সফ্টওয়্যারটি সাধারণত একটি সিমুলেশন, যেখানে কোনও ক্রিয়াটির আলাদা ফলাফল হয় না তবে বিশ্বরাজ্যে ধারাবাহিক পরিবর্তন হয়। যদি আমার লুকানো খেলোয়াড় শব্দ করে তবে আমি এটি যাচাই করতে চাই যে এআই আমাকে শিকার করছে। সুতরাং, আমি গোলমাল তৈরি হওয়ার পরে এআই 'শিকার' অবস্থায় রয়েছে তা নিশ্চিত করার জন্য একটি পরীক্ষা তৈরি করতে পারি এবং এটি দুর্দান্ত। তবে কীভাবে আমি শিকারটি কাজ করে তা কীভাবে জানব? আপনি এটি তাত্ক্ষণিকভাবে চেক করতে পারবেন না - আপনি কেবল এটি সময়ের সাথে সাথে পর্যবেক্ষণ করতে পারেন।
অধিকন্তু, একটি পরীক্ষার প্রথম পদ্ধতির সুরক্ষার একটি ভ্রান্ত ধারণা তৈরি করতে পারে এবং লোকেরা বিশ্বাস করতে পারে যে কোডটি তার চেয়ে বেশি ভাল।
def check_dice_roll_in_range():
d = new Dice()
assert(d.roll() between 1 and 6)
class Dice:
def roll():
return 4
যেহেতু একটি পরীক্ষার ফলাফল একটি মিথ্যা ইতিবাচক দিতে পারে, তাই কোডটি নিজেই পরীক্ষা করে দেখার প্রাথমিক প্রয়োজনটি আপনি কখনই এড়াতে পারবেন না। তবে কোডটি যদি পর্যাপ্ত পরিমাণে চেক করা হয় তবে পরীক্ষাটি গৌণ গুরুত্ব দেয়। এ কারণেই, আমার মতে, বাগের সংশোধনগুলি পরীক্ষা করার জন্য, ইভেন্টগুলির পরে পরীক্ষাগুলি সর্বোত্তমভাবে ব্যবহৃত হয়।
আমি তর্ক করব না যে পরীক্ষায় কোনও লাভ হয় না, যখন এক্স এবং ওয়াইজ অবজেক্টগুলি একসাথে কাজ করে, আপনি প্রাপ্ত ফলাফলটি প্রত্যাশার মতো হয়। সমস্যাটি হ'ল আপনি এটি যাচাই করার সবচেয়ে কার্যকর উপায় ব্যবহার করছেন কিনা। পদ্ধতিগুলির মধ্যে আনুষ্ঠানিক যাচাইকরণ, একটি কোড পর্যালোচনা, পরীক্ষার প্রথম পদ্ধতি, পরীক্ষার শেষ পদ্ধতি, traditionalতিহ্যবাহী কিউএ ব্ল্যাক-বাক্স পরীক্ষা বা কেবল প্রত্যাশা অনুযায়ী কোডটি ব্যবহার করা এবং ফলাফল পর্যবেক্ষণের অন্তর্ভুক্ত থাকতে পারে। শেষ দুটি বিকল্প বেশিরভাগ সময়ই আশ্চর্যজনকভাবে কার্যকর, কারণ তাদের অনমনীয়তার মতো শোনার পরেও বেশিরভাগ বাগগুলি সাধারণত ব্যবহারের সময় পাওয়া যায় এবং একটি প্রাকৃতিক প্রসঙ্গে একটি বাগ বোঝা অনেক সময় কৃত্রিম পরীক্ষায় এটি বোঝার চেয়ে সহজ হতে পারে কাজে লাগান. এটার উপরে,
সুতরাং, সংক্ষেপে, আমি মনে করি যে পরীক্ষিত চালিত বিকাশ অগত্যা সফ্টওয়্যারটির জন্য একটি দুর্দান্ত পছন্দ নয়, কেবলমাত্র পরীক্ষাগুলিই সফ্টওয়্যারটির মান নিশ্চিত করতে পর্যাপ্ত হয় না (এবং এইভাবে তাদের লেখার সময়টিকে সেই বিকাশকারী সময়ের বিকল্প ব্যবহারের সাথে তুলনা করতে হবে), গেমগুলি স্বয়ংক্রিয় পরীক্ষার কেসগুলির জন্য বিশেষত দুর্বল ম্যাচ এবং গেমগুলি 'ব্যবসায়ের মূল্য' এবং 'গ্রহণযোগ্যতা পরীক্ষার' উপর জোর দেওয়ার জন্য উন্নয়নের পদ্ধতিগুলির জন্য বিশেষত একটি দুর্বল ম্যাচ।
(আশা করি এটি আমার উত্তরগুলির সাথে একমত না হলেও, এটি একটি উত্তরের উত্তর))