জোর দেওয়া বা ইউনিট পরীক্ষা আরও গুরুত্বপূর্ণ?


51

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


4
আমি এই ধারণাটি অনেক পছন্দ করি ... তাই আমি বিষয়টিকে আমার সফ্টওয়্যার টেস্টিং এবং মানের নিশ্চয়তা কোর্সের জন্য একটি কার্যনির্বাহী করে তুলছি। :-)
ম্যাকনিল

আর একটি প্রশ্ন হ'ল: আপনার জমিগুলি কি ইউনিট-টেস্ট করা উচিত? ;)
মোজুবা

উত্তর:


43

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

  • পূর্ব শর্তাদি, যা আশ্বাস দেয় যে কলার তার চুক্তি রাখে,

  • পোস্টকন্ডিশনস, যা আশ্বাস দেয় যে কলি তার চুক্তিটি রাখে, এবং

  • আক্রমণকারীরা, যা নিশ্চিত করে যে ফাংশন ফিরে আসার পরে ডেটা কাঠামো সবসময় কিছু সম্পত্তি রাখে। আক্রমণকারী হ'ল একটি শর্ত যা পূর্ব শর্ত এবং পোস্টকন্ডিশন।

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

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

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

উভয়ের জন্যই লক্ষ্যটি মান বাড়ানো increase ইউনিট পরীক্ষার জন্য, বাগগুলি খুঁজে পাওয়া লক্ষ্য। দৃser়তার জন্য, লক্ষ্যটি হ'ল অবৈধ প্রোগ্রামের অবস্থাগুলি দেখা মাত্রই পর্যবেক্ষণ করে ডিবাগিংটিকে আরও সহজ করা।

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

উভয়ই গুরুত্বপূর্ণ এবং তাদের নিজস্ব উদ্দেশ্য রয়েছে।

[জরিমানা সম্পর্কে একটি চূড়ান্ত নোট হিসাবে: সর্বাধিক মান পেতে, আপনাকে এগুলি আপনার প্রোগ্রামের সমস্ত গুরুত্বপূর্ণ পয়েন্টে ব্যবহার করতে হবে, এবং কয়েকটি মূল ফাংশন নয়। অন্যথায়, সমস্যার মূল উত্সটি মাস্ক করা হয়েছে এবং কয়েক ঘন্টা ডিবাগিং ছাড়াই সনাক্ত করা শক্ত]


7

দৃ about়তার বিষয়ে কথা বলার সময়, মনে রাখবেন যে সেগুলি একটি স্যুইচ এর ফ্লিক এ বন্ধ করা যেতে পারে।

খুব খারাপ দৃser়তার উদাহরণ:

char *c = malloc(1024);
assert(c != NULL);

কেন এই খারাপ? কারণ NDEBUG- এর মতো সংজ্ঞায়িত হওয়ার কারণে যদি এই দাবিটি এড়িয়ে যায় তবে কোনও ত্রুটি পরীক্ষা করা হয় না।

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

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

অন্য অনেকগুলি ক্ষেত্রে রয়েছে যেগুলি ভুল হতে পারে এমন পর্যাপ্ত পরিমাণে পরিচালনার পরিবর্তে দৃser়তার সাথে ব্যবহৃত হয়। এ কারণেই দৃser় সংজ্ঞাগুলি একটি খারাপ খ্যাতি পায় এবং কেন গো-এর মতো ভাষা তাদের অন্তর্ভুক্ত করে না।

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

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


3
এ কারণেই দৃ .়তাগুলি সর্বদা সত্য বক্তব্য বলে মনে করা হয়, ত্রুটি পরীক্ষায় নয়।
ডোমিনিক ম্যাকডোনেল

@ ডোমিনিক এমসিডনেল ওয়েল, 'সত্য হওয়া উচিত' বিবৃতি। আমি কখনও কখনও এই ধরনের একটি বগী ABS () সালে নির্মিত আছে জিসিসি এর নির্দিষ্ট কিছু সংস্করণে যেমন কম্পাইলার quirks, কাছাকাছি পেতে জাহির। গুরুত্বপূর্ণ বিষয় মনে রাখা উৎপাদন তৈরী করে তাদের বন্ধ পরিণত হয়েছে উচিত যাহাই হউক না কেন
টিম পোস্ট

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

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

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

5

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

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

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

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

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

http://en.wikipedia.org/wiki/Design_by_contract#Languages_with_native_support

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