কোডে যৌক্তিক ভুলগুলি কীভাবে এড়ানো যায়, যখন টিডিডি সাহায্য না করে?

Question

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

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

এখানে কোডের প্রাসঙ্গিক অংশটি দেওয়া হল:

now = datetime.datetime.utcnow()
today = now.date()
if event_date.date() == today:
    return "Today"

yesterday = today - datetime.timedelta(1)
if event_date.date() == yesterday:
    return "Yesterday"

delta = (now - event_date).days

if delta < 7:
    return _number_to_text(delta) + " days ago"

if delta < 30:
    weeks = math.floor(delta / 7)
    if weeks == 1:
        return "A week ago"

    return _number_to_text(weeks) + " weeks ago"

if delta < 365:
    ... # Handle months and years in similar manner.

পরীক্ষাগুলি আজ, গতকাল, চার দিন আগে, দু'সপ্তাহ আগে, এক সপ্তাহ আগে, ইত্যাদি ঘটনার ঘটনা যাচাই করছিল এবং কোডটি সেই অনুযায়ী তৈরি করা হয়েছিল।

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

if delta == 1:
    return "A day ago"

ঠিক গণনা করার পরে delta।

বাগের একমাত্র নেতিবাচক পরিণতি হ'ল আমি কীভাবে এই ঘটনাটি ঘটতে পারে তা ভেবে আধা ঘন্টা নষ্ট করেছিলাম (এবং বিশ্বাস করে যে কোডের ইউটিসির অভিন্ন ব্যবহার সত্ত্বেও এটি টাইম অঞ্চলগুলির সাথে সম্পর্কযুক্ত) তবে এর উপস্থিতি আমাকে বিরক্ত করছে। এটি ইঙ্গিত করে যে:

• এ জাতীয় সাধারণ উত্স কোডেও যৌক্তিক ভুল করা খুব সহজ।
• পরীক্ষা চালিত বিকাশ কোনও কাজে দেয়নি।

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

আমি কীভাবে এই বাগটি প্রথম স্থানে তৈরি করা এড়াতে পারি?

Comments

এটির জন্য একটি পরীক্ষার মামলা করে? দেখে মনে হচ্ছে আপনি পরে এটি কীভাবে আবিষ্কার করেছিলেন এবং টিডিডি দিয়ে মেশাচ্ছেন।

— 4urous

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

— লরেন পেচটেল

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

— jpmc26

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

— ডক ব্রাউন

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

— জারেড স্মিথ

Answer 1

এগুলি হ'ল ধরণের ত্রুটিগুলি যা আপনি সাধারণত লাল / সবুজ / রিফ্যাক্টরের রিফেক্টর ধাপে পান। সেই পদক্ষেপটি ভুলে যাবেন না! নিম্নলিখিতগুলির (অরীক্ষিত) মতো রিফ্যাক্টরটি বিবেচনা করুন:

def pluralize(num, unit):
    if num == 1:
        return unit
    else:
        return unit + "s"

def convert_to_unit(delta, unit):
    factor = 1
    if unit == "week":
        factor = 7 
    elif unit == "month":
        factor = 30
    elif unit == "year":
        factor = 365
    return delta // factor

def best_unit(delta):
    if delta < 7:
        return "day"
    elif delta < 30:
        return "week"
    elif delta < 365:
        return "month"
    else:
        return "year"

def human_friendly(event_date):
    date = event_date.date()
    today = now.date()
    yesterday = today - datetime.timedelta(1)
    if date == today:
        return "Today"
    elif date == yesterday:
        return "Yesterday"
    else:
        delta = (now - event_date).days
        unit = best_unit(delta)
        converted = convert_to_unit(delta, unit)
        pluralized = pluralize(converted, unit)
        return "{} {} ago".format(converted, pluralized)

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

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

অন্য কথায়, রিফ্যাক্টরিং কেবল এটি সুন্দর করার জন্য নয়। সংকলকটি যে ত্রুটিগুলি চিহ্নিত করতে পারে তা এটি মানুষের পক্ষে সহজ করে তোলে।

Comments

পরবর্তী পদক্ষেপটি আন্তর্জাতিকীকরণ করা এবং সেখানে pluralizeকেবলমাত্র ইংরেজী শব্দের একটি উপসেটের জন্য কাজ করা দায়বদ্ধ হয়ে থাকবে।

— উত্সাহক

@ ডিডুকিপ্লেটর নিশ্চিত, তবে আপনি কোন ভাষা / সংস্কৃতি লক্ষ্য করে তার উপর নির্ভর করে আপনি কেবল টেবিল / রিসোর্স ফাইল থেকে ফর্ম্যাট স্ট্রিং টানতে কোনও pluralizeব্যবহারের পরিবর্তন numএবং unitকোনও ধরণের চাবি তৈরির মাধ্যমে পালিয়ে যেতে পারেন । অথবা আপনার পক্ষে যুক্তিটির সম্পূর্ণ পুনর্লিখনের প্রয়োজন হতে পারে, কারণ আপনার বিভিন্ন ইউনিট প্রয়োজন ;-)

— হাল্ক

এই রিফ্যাক্টরাইজেশনের পরেও একটি সমস্যা রয়ে গেছে, যা হ'ল "গতকাল" খুব ভোরের ঘন্টা খুব সকালে (12:01 AM এর পরে) বোঝায় না in মানব বন্ধুত্বপূর্ণ ভাষায়, 11:59 অপরাহ্নের মধ্যে ঘটে যাওয়া কিছু হঠাৎ "আজ" থেকে "গতকাল" তে পরিবর্তিত হয় না যখন ঘড়ির মধ্যরাত পিছলে যায়। এটি পরিবর্তে "1 মিনিট আগে" থেকে "2 মিনিট আগে" পরিবর্তিত হয়। "টুডে" এমন কিছু ঘটনার তুলনায় খুব মোটা, যা কয়েক মিনিট আগে ঘটেছিল এবং "গতকাল" রাতের পেঁচার সমস্যায় ভরা।

— ডেভিড হামেন

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

— ব্র্যান্ডিন

Answer 2

পরীক্ষা চালিত বিকাশ কোনও কাজে দেয়নি।

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

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

Comments

যে কোনও বিষয় তৈরি করা যেতে পারে যে বিকাশকারী যদি টিডিডি ব্যবহার না করে থাকেন তবে তারা অন্যান্য ক্ষেত্রেও মিস করার সম্ভাবনা বেশি ছিল।

— কালেব

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

— কালেব

টিডিডি পরীক্ষাগুলির মতোই ভাল।

— মাইন্ডউইন

আরেকটি পর্যবেক্ষণ: এই কেসটির জন্য পরীক্ষা যুক্ত করা আমাদের ডিজাইনের উন্নতি করবে, আমাদের datetime.utcnow()কাজটি বাইরে নিয়ে যেতে বাধ্য করে এবং পরিবর্তে nowএকটি (পুনরুত্পাদনযোগ্য) যুক্তি হিসাবে পাস করার জন্য।

— টবি স্পিড 12

Answer 3

ছয় ঘন্টা আগে ঘটে যাওয়া একটি ঘটনা একদিন আগে হবে

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

Comments

এটি একটি দুর্দান্ত পয়েন্ট। প্রয়োজন অনুপস্থিতির অর্থ এই নয় যে বাস্তবায়নের জন্য আপনার প্রক্রিয়া ব্যর্থ হয়েছে। এটির অর্থ কেবলমাত্র প্রয়োজনটি সঠিকভাবে সংজ্ঞায়িত হয়নি। (অথবা আপনি কেবল একটি মানুষের ত্রুটি করেছেন, যা সময়ে সময়ে ঘটবে)

— কালেব

এই আমি উত্তর করতে চেয়েছিলেন। আমি অনুচ্ছেদটি সংজ্ঞায়িত করলাম "যদি ইভেন্টটি এই ক্যালেন্ডারের দিন ছিল, কয়েক ঘন্টার মধ্যে উপস্থিত ডেল্টা se

— বাল্ড্রিক

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

— পিটার বি

Answer 4

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

সম্পর্কিত পঠন: বৃহত আকারের সফ্টওয়্যারগুলির জন্য নিখুঁত শূন্য বাগ বাগের স্থানে পৌঁছানো কি সম্ভব?

Comments

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

— মাইকেল কে

Answer 5

আমি সাধারণত দুটি উপায় গ্রহণ করি যা আমি খুঁজে পেতে পারি।

প্রথমত, আমি প্রান্তের মামলাগুলি সন্ধান করি। এই জায়গাগুলি যেখানে আচরণ পরিবর্তন হয়। আপনার ক্ষেত্রে, ইতিবাচক পূর্ণসংখ্যার দিনের ক্রম সহ বেশ কয়েকটি পয়েন্টে আচরণ পরিবর্তন হয়। শূন্যের এক প্রান্তের কেস আছে, এক সময়ে, সাত-এ, ইত্যাদি I আমি তারপরে প্রান্তের ক্ষেত্রে এবং তার আশেপাশে পরীক্ষার কেসগুলি লিখতে পারি write আমি -1 দিন, 0 দিন, 1 ঘন্টা, 23 ঘন্টা, 24 ঘন্টা, 25 ঘন্টা, 6 দিন, 7 দিন, 8 দিন, ইত্যাদিতে পরীক্ষার কেসগুলি করতাম

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

Comments

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

— GoatInTheMachine

@ গোয়াতইনম্যাচাইন - এবং এই 90% বাগগুলির মধ্যে 90% দিবালোক সঞ্চয় সময় ট্রানজিশনের কাছাকাছি ..... হাহাহা

— কালেব

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

— পিটার এ স্নাইডার

এটা সঠিক উত্তর. প্রচুর বিসেসের নিয়মগুলির জন্য আপনাকে অন্তরগুলিতে বিভিন্ন মানের মান বিভাজন করতে হবে যেখানে এগুলি বিভিন্ন উপায়ে পরিচালিত হবে।

— আবুজিটিন গিলিফিরকা

Answer 6

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

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

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

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

তারপরে আপনি নিয়মিতভাবে অন্যান্য সমস্ত ক্লাসে এজ কেস যুক্ত করবেন। আপনার আজকের জন্য পরীক্ষা আছে। সুতরাং আচরণের স্যুইচ হওয়ার ঠিক আগে এবং পরে একটি সময় যুক্ত করুন। গতকালের জন্য একই। এক সপ্তাহ আগের জন্য একই।

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

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

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

Answer 7

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

কেন না? এটি বেশ ভাল ধারণা মত শোনাচ্ছে!

কোডে চুক্তি (দৃ as়তা) যুক্ত করা এটির যথার্থতার উন্নতির একটি দুর্দান্ত উপায়। সাধারণত আমরা ফাংশন এন্ট্রি এবং ফাংশন রিটার্নে পোস্টকন্ডিশনে পূর্ব শর্ত হিসাবে তাদের যুক্ত করি । উদাহরণস্বরূপ, আমরা একটি পোস্টকন্ডিশন যুক্ত করতে পারি যে সমস্ত ফিরে আসা মানগুলি হয় "এ [ইউনিট] আগে" বা "[সংখ্যা] [ইউনিট] এর আগের" ফর্মের। সুশৃঙ্খল উপায়ে সম্পন্ন করার পরে এটি চুক্তি অনুসারে ডিজাইনের দিকে পরিচালিত করে এবং উচ্চ-আশ্বাসের কোডটি লেখার অন্যতম সাধারণ উপায়।

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

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

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

Comments

এই ধরণের সমস্যার সঠিক সমাধান এটি। বৈধ আউটপুটগুলির সেটটি নির্ধারণ করা সহজ (আপনি খুব সহজেই কিছু নিয়মিত প্রকাশ করতে পারেন, এরকম কিছু /(today)|(yesterday)|([2-6] days ago)|...) এবং তারপরে আপনি এলোমেলোভাবে নির্বাচিত ইনপুটগুলি দিয়ে প্রক্রিয়াটি চালাতে পারেন যতক্ষণ না আপনি এমন কোনও সন্ধান করেন যা প্রত্যাশিত আউটপুটগুলির সেটে নেই isn't এই পদ্ধতির গ্রহণ করবে এই বাগ ধরা হয়েছে, এবং না নিরূপক যে বাগ পূর্বেই বিদ্যমান পারে প্রয়োজন।

— জুলে

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

— ওয়ারবো

আপনি যদি পরীক্ষাগুলিতে এতগুলি লুপিং করেন, যদি খুব দীর্ঘ সময় লাগে, যা ইউনিট পরীক্ষার অন্যতম প্রধান লক্ষ্যকে পরাজিত করে: দ্রুত পরীক্ষা চালান !

— সিজে ডেনিস

Answer 8

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

def time_ago(delta, unit):
    delta_str = _number_to_text(delta) + " " + unit;
    if delta == 1:
        return delta_str + " ago"
    else:
        return delta_str = "s ago"

now = datetime.datetime.utcnow()
today = now.date()
if event_date.date() == today:
    return "Today"

yesterday = today - datetime.timedelta(1)
if event_date.date() == yesterday:
    return "Yesterday"

delta = (now - event_date).days

if delta < 7:
    return time_ago(delta, "day")

if delta < 30:
    weeks = math.floor(delta / 7)
    return time_ago(weeks, "week")

if delta < 365:
    months = math.floor(delta / 31)
    return time_ago(months, "month")

Answer 9

পরীক্ষা চালিত বিকাশ কোনও কাজে দেয়নি।

টেডিটি লেখার ব্যক্তি যদি প্রতিকূল হয় তবে টিডিডি একটি কৌশল হিসাবে সবচেয়ে ভাল কাজ করে। আপনি যদি জুটি-প্রোগ্রামিং না করেন তবে এটি কঠিন, সুতরাং এটির বিষয়ে চিন্তা করার আর একটি উপায় হ'ল:

• পরীক্ষার অধীনে ফাংশনটি নিশ্চিত করার জন্য পরীক্ষাগুলি লিখবেন না যেমন আপনি এটি তৈরি করেছিলেন। পরীক্ষাগুলি লিখুন যা ইচ্ছাকৃতভাবে এটি ভঙ্গ করে।

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

শক্তিশালী সফ্টওয়্যার লেখার মূল কৌশলটি কীভাবে কার্যকর পরীক্ষাগুলি লিখতে হয় তা বোঝার মূল কৌশল:

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

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

---

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

Answer 10

এটি সফ্টওয়্যার বিকাশ সম্পর্কে সর্বাধিক গুরুত্বপূর্ণ তথ্যগুলির মধ্যে: বাগ-মুক্ত কোডটি লেখা একেবারে অসম্ভব।

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

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

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

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

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

Answer 11

আপনি কেবল আগে এই কেসটি সম্পর্কে ভাবেননি এবং এজন্য এটির জন্য কোনও পরীক্ষার কেস নেই।

এটি সর্বদা ঘটে এবং ঠিক স্বাভাবিক। সমস্ত সম্ভাব্য পরীক্ষার কেস তৈরি করতে আপনি কতটা প্রচেষ্টা চালিয়েছেন এটি সর্বদা একটি বাণিজ্য। সমস্ত পরীক্ষার কেস বিবেচনা করার জন্য আপনি অসীম সময় ব্যয় করতে পারেন।

একটি বিমানের অটোপাইলটের জন্য আপনি একটি সাধারণ সরঞ্জামের চেয়ে অনেক বেশি সময় ব্যয় করবেন।

এটি প্রায়শই আপনার ইনপুট ভেরিয়েবলের বৈধ ব্যাপ্তিগুলি সম্পর্কে চিন্তা করতে এবং এই সীমানাগুলি পরীক্ষা করতে সহায়তা করে।

এছাড়াও, পরীক্ষক যদি বিকাশকারী থেকে আলাদা ব্যক্তি হন, তবে প্রায়শই আরও উল্লেখযোগ্য কেস পাওয়া যায়।

Answer 12

(এবং কোডটিতে ইউটিসির অভিন্ন ব্যবহার সত্ত্বেও, এটি টাইম জোনের সাথে সম্পর্কিত বলে বিশ্বাস করে)

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

উদাহরণ: অস্ট্রেলিয়ায় স্থানীয় সময় সকাল ৯ টায় একটি ইভেন্ট ঘটে। সকাল ১১ টায় এটি "গতকাল" হিসাবে প্রদর্শিত হবে কারণ ইউটিসির তারিখ পরিবর্তিত হয়েছে।

Answer 13

• অন্য কাউকে পরীক্ষা লিখতে দিন। আপনার বাস্তবায়নের সাথে অপরিচিত কেউ এমন কোনও বিরল পরিস্থিতি যা আপনি ভেবেও দেখেন নি তা পরীক্ষা করতে পারে।

• সম্ভব হলে সংগ্রহ হিসাবে পরীক্ষার কেস ইনজেক্ট করুন। এটি অন্য পরীক্ষার যুক্ত করা যেমন অন্য লাইনের সাথে যুক্ত করা সহজ করে তোলে yield return new TestCase(...)। এটি পরীক্ষার কেসগুলি তৈরির কাজটি স্বয়ংক্রিয় করে পরীক্ষামূলক পরীক্ষার দিকে যেতে পারে: "আসুন এক সপ্তাহের আগে সমস্ত সেকেন্ডের জন্য কোডটি কী ফিরিয়ে দেয় তা দেখি"।

Answer 14

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

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

এর অর্থ এখনও এই নয় যে আপনার কোডটি বাগ-মুক্ত, কেবল এটি আগের চেয়ে ভাল এবং আবারও সমস্ত জ্ঞাত আচরণ সঠিক!

টিডিডি সঠিকভাবে ব্যবহার করার অর্থ এই নয় যে আপনি বাগ ফ্রি কোড লিখবেন, এর অর্থ আপনি কম বাগ লিখবেন। তুমি বলো:

প্রয়োজনীয়তা তুলনামূলকভাবে পরিষ্কার ছিল

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

Answer 15

এ জাতীয় সাধারণ উত্স কোডেও যৌক্তিক ভুল করা খুব সহজ।

হ্যাঁ. টেস্ট চালিত বিকাশ এটি পরিবর্তন করে না। আপনি এখনও আসল কোডে এবং পরীক্ষার কোডেও বাগ তৈরি করতে পারেন।

পরীক্ষা চালিত বিকাশ কোনও কাজে দেয়নি।

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

উদ্বেগজনক বিষয় হ'ল আমি দেখতে পাচ্ছি না যে এই জাতীয় বাগগুলি কীভাবে এড়ানো যায়।

আপনি পারবেন না। এমনকি নাসা বাগগুলি এড়ানোর কোনও উপায় খুঁজে পায়নি; আমরা কম মানুষ অবশ্যই হয় না।

কোড লেখার আগে আরও চিন্তা করা,

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

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

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

মিশন-সমালোচনামূলক কোডের জন্য, আপনি যা বলেছেন তা বাস্তবে করতে পারতেন, তবে আপনার দৈনন্দিন মানক কোডের জন্য নয়।

আমি কীভাবে এই বাগটি প্রথম স্থানে তৈরি করা এড়াতে পারি?

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

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

Answer 16

আপনি সবেমাত্র আবিষ্কার করেছেন যে আপনি যতই চেষ্টা করুন না কেন আপনি নিজের কোডে সমস্ত সম্ভাব্য বাগগুলি ধরতে পারবেন না।

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

এর পরিবর্তে এর অর্থ হল যে এই কৌশলগুলি ব্যবহার করে আপনার কম সময় ব্যয় করা উচিত এবং সেই সাশ্রয়ী সময় ব্যয় করা উচিত যা বিকাশ জালের মধ্য দিয়ে পিছলে যায় alternative

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

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

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

Comments

এটি অত্যন্ত পরাজিত। That in turn means you should spend less time using these techniques- তবে আপনি কেবল বলেছেন যে এটি কম বাগের সাথে সহায়তা করবে ?!

— JᴀʏMᴇᴇ

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

— gbjbaanb