ইউনিট টেস্টিং কি অকাল সাধারণীকরণের দিকে পরিচালিত করে (বিশেষত সি ++ এর প্রসঙ্গে)?


20

প্রাথমিক নোট

আমি বিভিন্ন ধরণের পরীক্ষার পার্থক্যে যাব না, ইতিমধ্যে সে সম্পর্কে এই সাইটগুলিতে কয়েকটি প্রশ্ন রয়েছে।

আমি যা আছে তা নিয়ে যাচ্ছি এবং যা বলেছে: "কোনও প্রয়োগের ক্ষুদ্রতম বিচ্ছিন্ন ইউনিটটি পরীক্ষা করার" অর্থে ইউনিট টেস্টিং যা থেকে এই প্রশ্নটি আসলে উত্পন্ন

বিচ্ছিন্নতা সমস্যা

কোনও প্রোগ্রামের ক্ষুদ্রতম বিচ্ছিন্ন ইউনিট কী । ঠিক আছে, আমি এটি দেখতে পাচ্ছি, এটি (অত্যন্ত?) আপনি কোন ভাষায় কোড দিচ্ছেন তার উপর নির্ভর করে।

মিশেল পালকরা একটি সিমের ধারণা সম্পর্কে কথা বলেছেন : [WEwLC, p31]

একটি সিম এমন একটি জায়গা যেখানে আপনি সেই জায়গায় না সম্পাদনা করেই আপনার প্রোগ্রামে আচরণ পরিবর্তন করতে পারেন।

এবং বিশদটিতে না গিয়ে আমি বুঝতে পারছি একটি ইউনিট - ইউনিট টেস্টিংয়ের প্রসঙ্গে - এমন একটি প্রোগ্রামে এমন একটি স্থান হতে যেখানে আপনার "পরীক্ষা" আপনার "ইউনিট" এর সাথে ইন্টারফেস করতে পারে।

উদাহরণ

ইউনিট পরীক্ষা - বিশেষত সি ++ - এর অধীনে পরীক্ষার অধীনে থাকা কোড থেকে আরও সীম যুক্ত করতে প্রয়োজন যা কোনও নির্দিষ্ট সমস্যার জন্য কঠোরভাবে ডাকা হবে।

উদাহরণ:

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

প্রশ্নটি

আমি কয়েকটি সংস্করণ চেষ্টা করব যা আশা করে একই পয়েন্টটি সম্পর্কে জিজ্ঞাসা করবে:

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

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


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

@ হটপাউ 2 ব্লাসফেমি! :)
ম্যাপেল_শ্যাফ্ট

উত্তর:


23

ইউনিট পরীক্ষা - বিশেষত সি ++ - এর অধীনে পরীক্ষার অধীনে থাকা কোড থেকে আরও সীম যুক্ত করতে প্রয়োজন যা কোনও নির্দিষ্ট সমস্যার জন্য কঠোরভাবে ডাকা হবে।

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

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

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

যেভাবে ইউনিট টেস্টগুলির মধ্যে একটির জন্য একটি অ্যাপ্লিকেশন কোড "কেবল" ইউনিট পরীক্ষার জন্য উপকারী বা কাঠামোগুলি প্রয়োগ করা প্রয়োজন সেগুলি আসলে অ্যাপ্লিকেশন কাঠামোর পক্ষে উপকারী?

আমার অভিজ্ঞতায় একটি পরীক্ষামূলক নকশা সামগ্রিকভাবে উপকারী, ইউনিট নিজেরাই পরীক্ষার জন্য "কেবল" নয়। এই সুবিধাগুলি বিভিন্ন স্তরে আসে:

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

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

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

বিটিডব্লু আমি "জেনারালাইজেশন" দ্বারা ধরে নিয়েছি যার অর্থ একটি একক কংক্রিটের পরিবর্তে ইন্টারফেস (অ্যাবস্ট্রাক্ট ক্লাস) এবং পলিমারফিজম প্রবর্তনের মতো জিনিস - যদি তা না হয় তবে দয়া করে স্পষ্ট করুন।


স্যার, আমি আপনাকে সালাম জানাই।
গর্ডনএম

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

4

আমি আপনার দিকে টেস্টিয়াসের রাস্তা ফেলতে যাচ্ছি , তবে সংক্ষেপে:

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

সহজতম গাইডটি হ'ল: আপনি যা পরীক্ষা করছেন তা হ'ল আপনার কোডটির সার্বজনীন ইন্টারফেসটি সিস্টেমের অন্যান্য অংশগুলির দ্বারা এটি ব্যবহার করার উদ্দেশ্যে।

যদি আপনার পরীক্ষাগুলি দীর্ঘ এবং জটিল হয়ে উঠছে তবে এটি একটি ইঙ্গিত দেয় যে পাবলিক ইন্টারফেস ব্যবহার করা কঠিন হতে চলেছে।

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

তবে ইউনিট-টেস্টিং ডগমা থেকে সাবধান থাকুন। পরীক্ষাটি লিখুন যা আপনাকে সমস্যাটি সনাক্ত করতে দেয় যা ক্লায়েন্ট আপনাকে ডেকে আনবে


আমি একই যুক্ত করতে যাচ্ছিলাম: এপি তৈরি করুন, এপিআই পরীক্ষা করুন, বাইরে থেকে।
ক্রিস্টোফার মাহান

2

টিডিডি এবং ইউনিট টেস্টিং পুরো ইউনিট প্রোগ্রামের পক্ষে ভাল, কেবল ইউনিট পরীক্ষার জন্য নয়। এর কারণ হ'ল এটি মস্তিষ্কের পক্ষে ভাল।

এটি রোবটলেগস নামে একটি নির্দিষ্ট অ্যাকশনস্ক্রিপ্ট কাঠামো সম্পর্কে একটি উপস্থাপনা । তবে আপনি যদি প্রথম 10 টি স্লাইড বা তারপরে সরে যান তবে এটি মস্তিষ্কের ভাল অংশগুলিতে পেতে শুরু করে।

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


1

একটি অ্যাপ্লিকেশন ক্ষুদ্রতম বিচ্ছিন্ন ইউনিট পরীক্ষা

এটি সত্য, তবে আপনি যদি এটি খুব বেশি দূরে নিয়ে যান তবে এটি আপনাকে বেশি দেয় না, এবং এটির জন্য অনেক ব্যয়ও হয় এবং আমি বিশ্বাস করি যে এই দিকটিই বিডিডি শব্দটি ব্যবহারের প্রচার করে যা টিডিডি সব হওয়া উচিত ছিল বরাবর - ক্ষুদ্রতম বিচ্ছিন্ন এককটি আপনি এটি হতে চান।

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

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

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

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


0

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

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

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

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