অভ্যন্তরীণ উপাদানগুলির ইউনিট পরীক্ষা করা


14

আপনি কতটা শ্রেণি / মডিউল / প্যাকেজ / ইত্যাদির অভ্যন্তরীণ / ব্যক্তিগত উপাদানগুলি পরীক্ষা করে থাকেন? আপনি কি এগুলি পরীক্ষা করেন না আপনি কেবল বাইরের বিশ্বের ইন্টারফেসটি পরীক্ষা করেন? এই অভ্যন্তরীণ একটি উদাহরণ ব্যক্তিগত পদ্ধতি।

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

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

আমি কয়েকটি যুক্তি চিন্তা করতে পারি:

পেশাদাররা :

  1. আরও পরীক্ষা করা সর্বদা ভাল এবং এটি কোড কভারেজ বাড়াতে সহায়তা করতে পারে
  2. কিছু অভ্যন্তরীণ উপাদানগুলি বাইরের ইন্টারফেসে ইনপুট দিয়ে নির্দিষ্ট ইনপুটগুলি (উদাহরণস্বরূপ প্রান্তের কেসগুলি) দেওয়া শক্ত হতে পারে
  3. পরিষ্কার পরীক্ষা। যদি কোনও অভ্যন্তরীণ উপাদানটিতে একটি (স্থির) ত্রুটি থাকে, তবে সেই উপাদানটির জন্য একটি পরীক্ষার ক্ষেত্রে এটি স্পষ্ট করে দেয় যে বাগটি সেই নির্দিষ্ট উপাদানটিতে ছিল was

কনস :

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

আপনার মতামত কি?


এর সাথে সম্ভাব্য সদৃশ বা উল্লেখযোগ্য ওভারল্যাপ: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার.কম
সেকশনস 10832/…

উত্তর:


8

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

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

বিঃদ্রঃ:

  • মডিউলটির চুক্তি পরিবর্তন করার সময় মডিউলটির (প্রাক্তন) "সাব-মডিউলগুলি" পরীক্ষায় কোনও পরিবর্তন করার দরকার পড়বে না, যদি না "সাব-মডিউল" এর নতুন / পরিবর্তিত চুক্তি পূরণের জন্য পর্যাপ্ত অফার পরিষেবা না থাকে।

  • কিছুই অযথা তৈরি করা হবে পাবলিক অর্থাত মডিউল চুক্তির রাখা হবে এবং এনক্যাপস্যুলেশন বজায় রেখেছিল।

[হালনাগাদ]

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

  • বন্ধুর সাথে কিছু পরীক্ষামূলক কোড রয়েছে (সি ++ পদে) বা প্যাকেজ (জাভা) আভ্যন্তরীণ অঞ্চলে অ্যাক্সেসটি আসলে ভিতরে থেকে রাষ্ট্রটি সেট করে এবং আপনার পছন্দ হিসাবে আচরণটি পরীক্ষা করে।

    • এটি পরীক্ষার উদ্দেশ্যে ইন্টার্নালগুলিতে সরাসরি সরাসরি অ্যাক্সেস সরবরাহ করার সময় পুনরায় এনক্যাপসুলেশনটি ভেঙে ফেলবে না - কেবল "ব্ল্যাক বক্স" হিসাবে পরীক্ষা চালান এবং রিলিজ বিল্ডগুলিতে তাদের সংকলন করুন।

(; এবং তালিকা বিন্যাস একটু ভাঙ্গা বলে মনে হয়
mlvljr

1
ভাল উত্তর. .NET এ আপনি ইন্টার্নালগুলি পরীক্ষা করতে [assembly: InternalsVisibleTo("MyUnitTestAssembly")]আপনার এট্রিবিউটটি ব্যবহার করতে পারেন AssemblyInfo.cs। যদিও ঠকানো মনে হচ্ছে।
কেউ

@ আরএমএক্স একবার সমস্ত প্রয়োজনীয় মানদণ্ডকে সন্তুষ্ট করার পরে সত্যিকারের প্রতারণার সাথে কিছু মিল থাকলেও তা প্রতারণা নয়। তবে আন্তঃ / আন্তঃ-মডিউল অ্যাক্সেসের বিষয়টি আধুনিক মূলধারার ভাষাগুলিতে সত্যিই কিছুটা স্বীকৃত।
mlvljr

2

Sতিহ্যগতভাবে ব্যবহৃত এফএসএম-ভিত্তিক কোডের দিকে কিছুটা আলাদা। এটি এখানে হার্ডওয়্যার পরীক্ষার জন্য যা বর্ণিত হয়েছে তার সাথে খুব মিল (যা সাধারণত একটি এফএসএমও হয়)।

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

এই ধরণের টেস্টিং "ফাংশনাল টেস্টস" বলা হয় এর কাছাকাছি তবে প্রতিবার আপনি যখন কিছুটা প্রয়োগের দিকে কিছুটা স্পর্শ করেন তখন পরীক্ষাগুলি পরিবর্তন করার প্রয়োজনীয়তা হ্রাস করে।


2

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

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

সবকিছুর মতোই, ওয়াইএমএমভি


1

একটি কার্মিক অর্থ সঙ্গে একাধিক অংশের সেটিকে বিভক্ত, যেমন ParseQuotedString(), ParseExpression(), ParseStatement(), ParseFile()এবং তাদের সব সর্বজনীন করে তুলুন। আপনার সিনট্যাক্সটি এতটাই পরিবর্তিত হয়ে যায় যে এগুলি অপ্রাসঙ্গিক হয়ে যায়?


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