ইউনিট পরীক্ষায় চক্রীয় নির্ভরতাগুলির সাথে লড়াই করা

Question

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

আমার এমনটি BitVectorযা একটি structএকক সঞ্চয় করে UInt64এবং এটির উপরে একটি API উপস্থাপন করে যা আপনাকে এটি সংগ্রহের মতো আচরণ করতে দেয়। বিশদটি খুব বেশি গুরুত্ব দেয় না, তবে এটি বেশ সহজ। উচ্চ 57 বিটগুলি হ'ল স্টোরেজ বিট, এবং নীচের 6 টি বিটগুলি "গণনা" বিটস, যা আপনাকে বলবে যে স্টোরেজ বিটগুলির মধ্যে কতগুলি আসলে একটি বিদ্যমান মান সঞ্চয় করে।

এখনও অবধি আমার হাতে খুব সাধারণ ক্ষমতা রয়েছে:

1. একটি ইনিশিয়ালাইজার যা খালি বিট ভেক্টর তৈরি করে
2. countপ্রকারের একটি সম্পত্তিInt
3. isEmptyপ্রকারের একটি সম্পত্তিBool
4. একটি সমতা অপারেটর ( ==)। নোট: এটি Object.equals()জাভা -এর মতো একটি মান-সমতা অপারেটর , জাভা -র মতো কোনও রেফারেন্স সমতা অপারেটর নয় ==।

আমি একগুচ্ছ চক্রীয় নির্ভরতা মধ্যে চলেছি:

1. আমার ইনিশিয়ালাইজার পরীক্ষা করে এমন ইউনিট পরীক্ষা করে নতুন নির্মিত কিনা তা যাচাই করা দরকার BitVector। এটি 3 টির মধ্যে একটিতে এটি করতে পারে:

   1. চেক bv.count == 0
   2. চেক bv.isEmpty == true
   3. যে পরীক্ষা bv == knownEmptyBitVector

   পদ্ধতি 1 নির্ভর করে count, পদ্ধতি 2 নির্ভর করে isEmpty(যা নিজেই নির্ভর করে count, সুতরাং এটি ব্যবহার করার কোনও মানে নেই), পদ্ধতি 3 নির্ভর করে ==। যাই হোক না কেন, আমি আমার প্রারম্ভিকটিকে বিচ্ছিন্নভাবে পরীক্ষা করতে পারি না।

2. countকোনও কিছুর উপর পরিচালনা করার জন্য পরীক্ষার প্রয়োজন, যা অনিবার্যভাবে আমার আরম্ভকারীকে পরীক্ষা করে

3. বাস্তবায়ন isEmptyউপর নির্ভর করেcount

4. বাস্তবায়ন ==উপর নির্ভর করে count।

BitVectorবিদ্যমান বিট প্যাটার্ন (এ হিসাবে UInt64) থেকে একটি রচনা করে এমন একটি প্রাইভেট API প্রবর্তন করে আমি আংশিকভাবে এই সমস্যার সমাধান করতে সক্ষম হয়েছি । এটি আমাকে অন্য আরম্ভকারীদের পরীক্ষা না করে মানগুলি আরম্ভ করার অনুমতি দেয়, যাতে আমি "বুট স্ট্র্যাপ" চালিয়ে যেতে পারি।

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

আপনি এই ধরণের সমস্যাটি সম্পর্কে কীভাবে পেতে পারেন?

Comments

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

— বার্ট ভ্যান ইনজেন শেহেনো

আপনি বাস্তবায়নের অনেক বেশি বিবরণ জানেন। আপনার গঠন সত্যিই test- হয় চালিত ?

— হার্বি

@ হার্বি না, সেজন্য আমি অনুশীলন করছি। যদিও এটি দেখতে সত্যিই অপ্রদৃশ্য মান। আমি বাস্তবায়ন করি না এর বাস্তব সুন্দর কোনও মানসিক সান্নিধ্য ছাড়াই আমি কখনও কিছু প্রোগ্রাম করেছি বলে মনে হয় না।

— আলেকজান্ডার - মনিকা পুনরায় ইনস্টল করুন

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

— হার্বি

Answer 1

আপনি বাস্তবায়নের বিশদ সম্পর্কে খুব বেশি উদ্বেগ করছেন।

এটা কোন ব্যাপার না যে আপনার বর্তমান বাস্তবায়নের , isEmptyউপর নির্ভর করে count(অথবা যাই হোক না কেন অন্যান্য সম্পর্কের আপনি থাকতে পারে): সব বিষয়ে চিন্তা করা উচিত প্রকাশ্য ইন্টারফেস। উদাহরণস্বরূপ, আপনি তিনটি পরীক্ষা করতে পারেন:

• যে একটি নতুন আরম্ভ করা বস্তু আছে count == 0।
• যে একটি নতুন আরম্ভ করা বস্তু আছে isEmpty == true
• যে একটি নতুন আরম্ভ করা বস্তু পরিচিত খালি বস্তুর সমান।

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

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

Comments

@ আলেকজান্ডার আপনি ইউনিট পরীক্ষার একটি সুস্পষ্ট সংজ্ঞা প্রয়োজনের মতো একজন ব্যক্তির মতো শোনেন। আমার জানা

— মতে সবচেয়ে ভালটি

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

— আমন

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

— পিপীলিকা

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

— ঝোমিনাল

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

— গ্যালাকটিক

Answer 2

আপনি এই ধরণের সমস্যাটি সম্পর্কে কীভাবে পেতে পারেন?

"ইউনিট পরীক্ষা" কী তা নিয়ে আপনি আপনার চিন্তাভাবনাটি সংশোধন করুন।

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

অনুশীলনে, এটি প্রায়শই মনে হয়

// GIVEN
obj = new Object(...)

// THEN
assert object.read(...)

অথবা

// GIVEN
obj = new Object(...)

// WHEN
object.change(...)

// THEN
assert object.read(...)

"ইউনিট পরীক্ষা" পরিভাষা - ভাল, এটি খুব ভাল না হওয়ার দীর্ঘ ইতিহাস রয়েছে।

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

কেন্ট ১৯৯৪ সালে সুনিটের প্রথম সংস্করণ লিখেছিলেন , ১৯৯৯ সালে ইউনাইট বন্দরটি ছিল, টিডিডি বইয়ের প্রথম খসড়াটি ২০০২ সালের শুরুর দিকে। বিভ্রান্তি ছড়িয়ে দিতে অনেক সময় ছিল।

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

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

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

• পার্নাস: মডিউলগুলিতে সংক্ষেপণ ব্যবস্থায় ব্যবহৃত হওয়া মানদণ্ডে
• রেইনসবার্গার: সমন্বিত পরীক্ষাগুলি একটি কেলেঙ্কারী
• শোর: ঠাট্টা ছাড়া টেস্টিং: একটি প্যাটার্ন ভাষা

Answer 3

সাধারণভাবে (টিডিডি ব্যবহার না করেও) আপনার কীভাবে এটি প্রয়োগ করা হয় তা জানেন না এমন ভান করার সময় আপনার যতটা সম্ভব পরীক্ষাগুলি লেখার প্রচেষ্টা করা উচিত।

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

পরীক্ষাগুলির নীচে কল গ্রাফটি কীভাবে দেখায় তা অপ্রাসঙ্গিক, যতক্ষণ না পরীক্ষাগুলি নিজেরাই বুদ্ধিমান এবং ভালভাবে বজায় থাকে।

আমি মনে করি আপনার সমস্যা টিডিডি সম্পর্কে আপনার বোঝার।

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

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