ইউনিট টেস্ট ব্যবহার করে কোনও এনামের মান পরীক্ষা করা উচিত?


15

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

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

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

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


19
এনামের ইউনিট পরীক্ষাটি কী দেখতে হবে?
jonrsharpe


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

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

2
আইএমএইচও, মহাবিশ্ব ঠিক আছে কিনা তা পরীক্ষা করার জন্য 2 + 2 = 4 পরীক্ষা করার চেয়ে এটি বেশি কার্যকর নয়। আপনি সেই এনাম ব্যবহার করে কোডটি পরীক্ষা করেন, এনাম নিজেই নয়।
এজেন্ট_এল

উত্তর:


39

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

না, তারা কেবল রাষ্ট্র।

মূলত, আপনি যে এনাম ব্যবহার করছেন তা বাস্তবায়নের বিশদ ; এটি এমন এক ধরণের জিনিস যা আপনি অন্য ডিজাইনে রিফ্যাক্টর সক্ষম করতে সক্ষম হতে পারেন।

সম্পূর্ণতার জন্য পরীক্ষাগুলি পরীক্ষাগুলি উপস্থাপনযোগ্য পূর্ণসংখ্যার সমস্ত উপস্থিত রয়েছে তা পরীক্ষার সাথে সমতুল্য।

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


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

4
@ আইএস 1_সো - ভিওইউর বক্তব্য যে একটি পরীক্ষা হলেও এটি ব্যর্থ হওয়া উচিত: এটি হয়েছে? কোন ক্ষেত্রে, আপনার বিশেষভাবে এনাম পরীক্ষা করার দরকার নেই। তাই না? হয়তো একটি নিদর্শন এই যে আপনি আপনার কোড আরো সহজভাবে মডেল এবং ডেটাতে 'সত্যিকারের প্রকৃতি' বেশী বিমূর্ততা তৈরী করতে পারে যে - যেমন একটি ডেক কার্ড নির্বিশেষে আপনি কি সত্যিই একজন উপস্থাপনা থাকতে হবে না, [ Hearts, Spades, Diamonds, Clubs] যদি আপনি কেবল যখন কার্ড কার্ড লাল / কালো হয়?
আরেকটিডভে

1
@ আইএস 1_SO বলতে দেয় যে আপনার কাছে ত্রুটি কোড রয়েছে এবং আপনি একটি null_ptrত্রুটি ছুঁড়ে দিতে চান । এনামের মাধ্যমে এখন এটির একটি ত্রুটি কোড রয়েছে। একটি null_ptrত্রুটির জন্য কোড পরীক্ষা করা এনামের মাধ্যমেও কোডটি সন্ধান করে। সুতরাং এর মান 5(প্রাক্তন জন্য) থাকতে পারে। এখন আপনাকে অন্য একটি ত্রুটি কোড যুক্ত করতে হবে। এনামটি পরিবর্তন করা হয়েছে (আসুন আমরা এনামের শীর্ষে একটি নতুন যুক্ত করব) এর মান null_ptrএখন 6। এটা কি কোন সমস্যা? আপনি এখন একটি ত্রুটি কোড ফেরান 6এবং এর জন্য পরীক্ষা করুন 6। যতক্ষণ না সবকিছু যৌক্তিকভাবে সুসংগত হয় ততক্ষণ আপনি তাত্ত্বিক পরীক্ষা ভঙ্গ করে এই পরিবর্তন সত্ত্বেও আপনি ভাল আছেন।
বাল্ড্রিক 24

17

আপনি একটি এনাম ঘোষণার পরীক্ষা করেন না । ফাংশন ইনপুট / আউটপুটটির প্রত্যাশিত এনাম মান রয়েছে কিনা তা আপনি পরীক্ষা করতে পারেন। উদাহরণ:

enum Parity {
    Even,
    Odd
}

Parity GetParity(int x) { ... }

আপনি না তারপর যাচাই enum টেস্ট লিখবেন Parityনাম সংজ্ঞায়িত Evenএবং Odd। এই জাতীয় পরীক্ষাটি অর্থহীন হবে যেহেতু আপনি কেবল কোড দ্বারা ইতিমধ্যে বর্ণিত যা পুনরাবৃত্তি করবেন। দু'বার একই কথা বললে এটি আরও সঠিক হয় না।

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

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


আমি এই উত্তরটি সম্বোধন করার প্রয়াসে আমার প্রশ্ন আপডেট করেছি, এটি সাহায্য করে কিনা তা পরীক্ষা করে দেখুন।
IS1_SO

@ আইএস 1_SO: ঠিক আছে যা আমাকে বিভ্রান্ত করে - আপনি কি গতিময়ভাবে এনাম মানগুলি তৈরি করছেন, বা কী হচ্ছে?
জ্যাকবিবি

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

3
@ আইএস 1_SO: আপনি কোনও ফাংশন থেকে ফিরে আসা এনাম উদাহরণ পরীক্ষা করার কথা বলছেন যার একটি নির্দিষ্ট প্রত্যাশিত মান আছে? কারণ হ্যাঁ আপনি এটি পরীক্ষা করতে পারেন। আপনার কেবল এনাম ঘোষণা নিজেই পরীক্ষা করার দরকার নেই।
জ্যাকবিবি

11

যদি এনাম পরিবর্তন করা আপনার কোডটি ভেঙে দেয় এমন ঝুঁকি থাকে তবে নিশ্চিত হয়ে নিন যে, সি # তে [পতাকা] বৈশিষ্ট্যের সাথে যে কোনও কিছুই করা ভাল ক্ষেত্রে হবে কারণ 2 এবং 4 (3) এর মধ্যে একটি মান যুক্ত করা একটি বিস্তৃতের চেয়ে 1 এবং 2 হবে বিচক্ষণ আইটেম

এটি সুরক্ষার একটি স্তর।

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

আমি লোককে এনাম এন্ট্রিগুলির মূলধনকে "সঠিক" দেখেছি, তাদের বর্ণমালা অনুসারে বা অন্য কোনও যৌক্তিক গোষ্ঠীবদ্ধ করে বাজেটের অন্য কোডগুলি ভেঙে ফেলেছি।


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

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

11

না, একটি এনামে সমস্ত বৈধ মান রয়েছে এবং এটি এনামের ঘোষণাপত্রের পুনরাবৃত্তি করছে তা পরীক্ষা করে। আপনি কেবল পরীক্ষা করছিলেন যে ভাষাটি এনাম কনস্ট্রাক্টকে যথাযথভাবে প্রয়োগ করে যা একটি মূর্খতা পরীক্ষা।

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


3

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

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


1

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

আমি একবার কেস করেছি যে একটি মডিউল দুটি অন্যান্য মডিউল থেকে এনামের ধরন ব্যবহার করেছিল এবং তাদের মধ্যে ম্যাপ করেছে। (এনামগুলির মধ্যে একটিতে এটির সাথে অতিরিক্ত যুক্তি ছিল, অন্যটি ডিবি অ্যাক্সেসের জন্য ছিল, উভয়েরই নির্ভরতা ছিল একে অপরের থেকে বিচ্ছিন্ন করা উচিত should)

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

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


1

কাস্টম (আশাবাদী অর্থপূর্ণ) নাম সহ এনামগুলি কেবল সীমাবদ্ধ প্রকার। একটি enum শুধুমাত্র একটি মান, মত থাকতে পারে voidযা শুধুমাত্র রয়েছে null(কিছু কিছু ভাষায় এই কল unit, এবং নাম ব্যবহার voidসঙ্গে একটি enum জন্য কোন উপাদান!)। এটা দুই মূল্যবোধ, মত থাকতে পারে boolযা হয়েছে falseএবং true। এটি তিনটি মত থাকতে পারে, colourChannelসঙ্গে red, greenএবং blue। ইত্যাদি।

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

উদাহরণস্বরূপ, resultধারণকারী win/ lose/ drawউপরোক্ত isomorphic হয় colourChannel, যেহেতু আমরা যেমন প্রতিস্থাপন করতে পারেন colourChannelসঙ্গে result, redসঙ্গে win, greenসঙ্গে loseএবং blueসঙ্গে draw, এবং যতদিন আমরা কি হিসাবে সর্বত্র (উত্পাদক ও ভোক্তাদের, পারজার এবং serialisers, ডাটাবেজ এন্ট্রি, লগ ফাইল, ইত্যাদি ) তাহলে আমাদের প্রোগ্রামে কোনও পরিবর্তন হবে না। colourChannelআমাদের লেখা কোনও " পরীক্ষা" এখনও পাস করবে, যদিও এর পরে আর কিছু নেই colourChannel!

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

এর অর্থ কী, মেশিনটি যতটা উদ্বিগ্ন, এনামগুলি হ'ল "স্বতন্ত্র নাম" এবং অন্য কিছু নয় । একটি এনামের সাথে আমরা কেবলমাত্র যা করতে পারি তা হ'ল দুটি মান একই (যেমন red/ red) বা পৃথক (যেমন red/ blue) পৃথক কিনা on সুতরাং এটিই কেবল 'ইউনিট পরীক্ষা' করতে পারে, যেমন

(  red == red  ) || throw TestFailure;
(green == green) || throw TestFailure;
( blue == blue ) || throw TestFailure;
(  red != green) || throw TestFailure;
(  red != blue ) || throw TestFailure;
...

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

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

তবুও এ জাতীয় জিনিসগুলি এনামের নিজের দায়বদ্ধতা নয়: এনাম পরিবর্তন করা দূরবর্তী সিস্টেমের সাথে যোগাযোগকে ভেঙে দিতে পারে, তবে বিপরীতভাবে আমরা এনাম পরিবর্তন করে এ জাতীয় সমস্যা সমাধান করতে পারি !

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

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

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

1

নং ইউনিট পরীক্ষাগুলি ইউনিট পরীক্ষার জন্য।

অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ে, ইউনিট প্রায়শই একটি সম্পূর্ণ ইন্টারফেস, যেমন একটি শ্রেণি, তবে এটি একটি পৃথক পদ্ধতি হতে পারে।

https://en.wikipedia.org/wiki/Unit_testing

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


0

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

কোনও এনাম টাইপের আপনার প্রত্যাশিত এন্ট্রি রয়েছে তা আপনাকে স্পষ্টভাবে দৃsert়ভাবে বলার দরকার নেই, যেমন আপনি স্পষ্টভাবে দৃ or়ভাবে দাবি করেন না যে কোনও শ্রেণি আসলেই বিদ্যমান বা এটির যে পদ্ধতি এবং বৈশিষ্ট্য আপনি প্রত্যাশা করেন তা রয়েছে।

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

মনে রাখবেন যে আপনার কোডটি সঠিকভাবে করার জন্য অর্থপূর্ণ নামের প্রয়োজন নেই, এটি আপনার কোড পড়ার লোকদের পক্ষে কেবল একটি সুবিধের বিষয়। আপনি আপনার কোডটি এনাম মানগুলি foo, bar... এবং এর মতো পদ্ধতিগুলির সাথে কাজ করতে পারেন frobnicate()

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.