ইউনিট পরীক্ষাগুলির কোনও বিন্দু কি এমন সব কিছুর উপরে স্টাব ও বিদ্রূপ করে?

Question

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

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

Comments

আমার দুটি সেন্ট: উপহাসকে

— জুয়ান মেন্ডেস

আরও দেখুন "বিদ্রূপকারী একটি কোড গন্ধ"

— user949300

Answer 1

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

এটিকে মনে হচ্ছে আপনি যে পদ্ধতিটি পরীক্ষা করছেন তার জন্য অন্যান্য কয়েকটি শ্রেণীর উদাহরণ প্রয়োজন (যা আপনাকে উপহাস করতে হবে) এবং এটি নিজে নিজে বেশ কয়েকটি পদ্ধতিকে কল করে।

এই ধরণের কোডটি ইউনিট-টেস্ট করা সত্যিই কঠিন কারণগুলির কারণে আপনার বাহ্যরেখায়।

যা আমি সহায়ক পেয়েছি তা হ'ল এই ধরণের ক্লাসগুলি বিভক্ত করা:

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

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

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

---

একটি উদাহরণ

এক শ্রেণি

বলুন যে আপনার কাছে এমন একটি শ্রেণি রয়েছে যা একটি ডাটাবেস থেকে মূল্য পুনরুদ্ধার করে, কিছু ছাড় প্রয়োগ করে এবং তারপর ডাটাবেস আপডেট করে।

আপনার যদি এই সমস্ত কিছু এক শ্রেণিতে থাকে তবে আপনাকে ডিবি ফাংশনগুলি কল করতে হবে, যা উপহাস করা শক্ত। সিউডোকোডে:

1 select price from database
2 perform price calculation, possibly fetching parameters from database
3 update price in database

তিনটি ধাপে ডিবি অ্যাক্সেসের প্রয়োজন হবে, তাই প্রচুর পরিমাণে (জটিল) মশকরা, যা কোড বা ডিবি কাঠামো পরিবর্তিত হলে ভেঙে যাওয়ার সম্ভাবনা রয়েছে।

ভাগ করা

আপনি তিনটি শ্রেণিতে বিভক্ত হয়েছেন: প্রাইসক্যালকুলেশন, প্রাইস রিপোসিটোরি, অ্যাপ্লিকেশন।

প্রাইসক্যালকুলেশন কেবল আসল গণনা করে এবং এটি প্রয়োজনীয় মান সরবরাহ করে। অ্যাপ্লিকেশন সবকিছু একসাথে বাঁধে:

App:
fetch price data from PriceRepository
call PriceCalculation with input values
call PriceRepository to update prices

ঐ দিকে:

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

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

Comments

আমি ভেবেছিলাম যে আমি একা সমস্ত কিছু পরীক্ষার একক পয়েন্টটি দেখছি না, ধন্যবাদ

— শে

আমি কেবল তখন অসম্মতি জানাই যখন আপনি টাইপ 3 শ্রেণীর ক্লাসগুলি খুব কম বলে মনে হয়, আমার বেশিরভাগ কোডটি 3 ধরণের হয় এবং ব্যবসায়ের কোনও যুক্তি নেই বলে মনে হয়। এটি আমার অর্থ: স্ট্যাকওভারফ্লো.com

— রদ্রিগো রুইজ

Answer 2

ইউনিট টেস্ট বনাম ইন্টিগ্রেশন টেস্টিংয়ের নির্ধারিত সুবিধা কী?

এটি একটি মিথ্যা দ্বৈতত্ত্ব

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

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

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

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

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

---

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

আপনি যদি তুচ্ছ কোডের জন্য ইউনিট পরীক্ষা লেখার জন্য অনেক সময় ব্যয় করেন

public string SomeProperty { get; set; }

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

public string SomeMethod(string someProperty);

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

Comments

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

— 29

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

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

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

— 17:33

সুতরাং আমি অনুমান করি ইউনিট পরীক্ষাগুলি বেশিরভাগ বিচ্ছিন্ন স্টাফের জন্য যা এই ধরণের 'ইনপুটগুলির সেট -> প্রত্যাশিত ফলাফলের সেট' - এ নিশ্চিত করে?

— enthrops

প্রচুর ইউনিট এবং ইন্টিগ্রেশন টেস্ট তৈরির আমার অভিজ্ঞতা (সেই পরীক্ষাগুলি দ্বারা ব্যবহৃত উন্নত উপহাস, ইন্টিগ্রেশন টেস্টিং এবং কোড কভারেজ সরঞ্জামগুলির উল্লেখ না করা) আপনার বেশিরভাগ দাবির বিরোধিতা করে এখানে: 1) "ইউনিট পরীক্ষার উদ্দেশ্যটি নিশ্চিত করা আপনার কোড যা অনুমান করা হয় তা করে ": এটিই সংহতকরণ পরীক্ষার ক্ষেত্রে প্রযোজ্য (আরও বেশি); 2) "ইউনিট পরীক্ষাগুলি সেটআপ করা অনেক সহজ": না, সেগুলি হয় না (প্রায়শই এটি ইন্টিগ্রেশন টেস্টগুলি যে সহজ); 3) "যখন সঠিকভাবে ব্যবহৃত হয়, ইউনিট পরীক্ষাগুলি" টেস্টেবল "কোডের বিকাশকে উত্সাহ দেয়: ইন্টিগ্রেশন পরীক্ষার সাথে একই; (অবিরত)

— 22:52

Answer 3

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

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

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

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

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

হালনাগাদ

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

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

Comments

এবং যদি কোনও পদ্ধতি ব্যক্তিগত কোনও কিছু না বলে, তবে ইউনিট এটির পরীক্ষা করার কোনও মানে নেই, তাই না?

— enthrops

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

— শ্লেইস

না, আমার অর্থ যদি কোনও পাবলিক পদ্ধতি কোনও কিছুকে ব্যক্তিগত বলে না, সেই পাবলিক পদ্ধতিটি পরীক্ষা করা কি বোধগম্য?

— এনট্রপস

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

— শ্লেইস

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

— h

Answer 4

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

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

আসলে, অতিরিক্ত মশকরা একটি অ্যান্টি-প্যাটার্ন: টিডিডি অ্যান্টি-প্যাটার্নস এবং মকস অশুভ ।

Answer 5

যদিও বিকল্পটি ইতিমধ্যে একটি উত্তর চিহ্নিত করেছে, আমি এখানে আমার 2 সেন্ট যুক্ত করছি।

ইউনিট টেস্টিং বনাম ইন্টিগ্রেশন পরীক্ষার (সময় ওভারহেড বাদ দিয়ে) এর সিদ্ধান্ত নেওয়া সুবিধা কী?

এবং প্রতিক্রিয়া হিসাবে

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

একটি সহায়ক আছে তবে ঠিক ওপি যা বলেছে তা নয়:

ইউনিট টেস্টগুলি কাজ করে তবে কি বাগগুলি রয়েছে?

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

1. ব্যক্তিগত পদ্ধতির জন্য ইউনিট পরীক্ষা (গুলি) তৈরি করবেন না।
2. একটি ব্যক্তিগত পদ্ধতির জন্য ইউনিট টেস্ট (গুলি) তৈরি করুন।

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

---

কেস বিবেচনা করার সময় যখন অন্যান্য অনেকগুলি সরকারী পদ্ধতি দ্বারা ব্যক্তিগত পদ্ধতি পুনরায় ব্যবহার করা হয়।

সুতরাং, যদি আমি পন্থা 1 বেছে নিয়েছিলাম: আমি ইউনিট পরীক্ষার সদৃশ করতাম এবং সেগুলি জটিল হত, কারণ আপনার পাবলিক পদ্ধতির প্রতিটি শাখার জন্য ইউনিট টেস্টের পাশাপাশি ব্যক্তিগত পদ্ধতিও ছিল You

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

---

ব্যক্তিগত পদ্ধতি পুনরায় ব্যবহার না করা হলে কেসটি বিবেচনা করে সেই পদ্ধতির জন্য পৃথক ইউনিট পরীক্ষা লেখার কোনও মানে হয় না।

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