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


13

মান দৃষ্টিকোণ থেকে আমি আমার অনুশীলনে ইউনিট পরীক্ষার দুটি গ্রুপ দেখতে পাচ্ছি:

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

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


3
আমি ইউনিট পরীক্ষাগুলি পরিচিত (নির্দিষ্ট) বাগগুলির জন্য যাচাই করে রাখি - যা একবারে মূল ইউনিট পরীক্ষার সেটগুলির মধ্যে পড়ে যায় - আলাদা গ্রুপ হিসাবে যার ভূমিকা রিগ্রেশন বাগগুলি রোধ করা।
কনরাড মোরাউস্কি

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

3
@ টেলাস্টিন - আপনার মন্তব্য সম্পর্কে সমস্ত কিছু আমার কাছে সম্পূর্ণ উন্মাদ বলে মনে হচ্ছে। কে ইচ্ছাকৃতভাবে কোড পরিবর্তন করা কঠিন করবে? কেন বিকাশকারীদের উপযুক্ত দেখায় কোড পরিবর্তন করা থেকে নিরুৎসাহিত করেন - আপনি কি তাদের বিশ্বাস করেন না? তারা কি খারাপ বিকাশকারী?
বেনিয়ামিন হজসন

2
যে কোনও ক্ষেত্রে, যদি কোড পরিবর্তন করে "রিপল ইফেক্টস" থাকে তবে আপনার কোডটির একটি ডিজাইনের সমস্যা রয়েছে - এই ক্ষেত্রে ডেভসকে রিফ্যাক্টর হিসাবে যথাসম্ভব উত্সাহ দেওয়া উচিত। নাজুক পরীক্ষাগুলি সক্রিয়ভাবে রিফ্যাক্টরিংকে নিরুৎসাহিত করে (একটি পরীক্ষা ব্যর্থ হয়; এই পরীক্ষাটি যে 80% পরীক্ষাগুলি সত্যই কিছুই করে না তার মধ্যে একটি ছিল কিনা তা খুঁজে বের করার জন্য কে বিরক্ত হতে পারে? এটি করার জন্য আপনি কেবল একটি আলাদা, আরও জটিল উপায় খুঁজে পান)। তবে আপনি এটিকে একটি আকাঙ্ক্ষিত বৈশিষ্ট্য হিসাবে দেখছেন বলে মনে হয় ... আমি এটি মোটেও পাই না।
বেঞ্জামিন হজসন

2
যাইহোক, ওএপি এই ব্লগ পোস্টটিকে রেলের স্রষ্টার কাছ থেকে আকর্ষণীয় মনে হতে পারে। তাঁর বক্তব্যকে অতি-সরল করার জন্য আপনার সম্ভবত সেই 80% পরীক্ষা ফেলে দেওয়ার চেষ্টা করা উচিত।
বেনিয়ামিন হজসন

উত্তর:


14

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

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

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

tl; dr এটি ভুল পরীক্ষা করা সহজ, এটি অবিশ্বাস্যরূপে মতামতযুক্ত এবং আমি বিশ্বাস করি না যে কোনও একটি পরীক্ষার পদ্ধতি যতক্ষণ তারা যথাযথভাবে প্রাসঙ্গিকতার মধ্যে নিখরচায় এবং পেশাগতভাবে ব্যবহার করা হয় ততক্ষণ অন্তর্নিহিতভাবে আরও ভাল Furthermore আমার মনে দৃser়তা বা স্যানিটি-টেস্টের একটি বর্ধিতাংশ যা উন্নয়নের ক্ষেত্রে একটি ব্যর্থ-দ্রুত অ্যাডহক পদ্ধতির নিশ্চিত করতে ব্যবহৃত হয়েছিল যা এখন অনেক বেশি সহজ।

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

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

[1] অ্যান্ড্রু বিনস্টক কর্তৃক দুর্নীতি অবধি

[2] পূর্ববর্তী নিবন্ধের প্রতিক্রিয়াগুলিতে প্রতিক্রিয়া

[3] চাচা বব দ্বারা দুর্নীতি দুর্নীতিতে প্রতিক্রিয়া

[৪] রব মাইয়ার্স দ্বারা দুর্নীতি দুর্নীতিতে প্রতিক্রিয়া

[]] শসা পরীক্ষা দিয়ে কেন বিরক্ত?

[]] আপনি এটি ভুল রান্না করছেন

[]] সরঞ্জাম থেকে দূরে যান

[8] 'ভাষ্য সহ রোমান সংখ্যা কাটা' সম্পর্কে মন্তব্য

[9] ভাষ্য সহ রোমান সংখ্যা কাটা


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

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

5

আমি বিশ্বাস করি উভয় প্রকারের পরীক্ষা করা এবং যেখানে উপযুক্ত সেখানে সেগুলি ব্যবহার করা জরুরী।

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

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

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

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


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

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

4

এখানে আমি এটি গ্রহণ করি: সমস্ত পরীক্ষার জন্য ব্যয় হয়:

  • প্রাথমিক সময় এবং প্রচেষ্টা:
    • কী পরীক্ষা করতে হবে এবং কীভাবে এটি পরীক্ষা করতে হবে তা ভেবে দেখুন
    • পরীক্ষাটি বাস্তবায়ন করুন এবং এটি যা পরীক্ষা করা উচিত তা পরীক্ষা করে নিন
  • চলমান রক্ষণাবেক্ষণ
    • কোডটি প্রাকৃতিকভাবে বিকশিত হওয়ায় পরীক্ষাটি এখনও তার যা করা উচিত তা করছে তা নিশ্চিত করে
  • পরীক্ষা চলছে
    • সঞ্চালনের সময়
    • ফলাফল বিশ্লেষণ

আমরা সমস্ত পরীক্ষার সুবিধাগুলি সরবরাহ করার জন্যও পরিকল্পনা করি (এবং আমার অভিজ্ঞতায় প্রায় সমস্ত পরীক্ষাগুলিই বেনিফিট সরবরাহ করে):

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

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

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

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

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


2

কি হল একটি ইউনিট পরীক্ষা, তাই? এবং সত্যিই এখানে খেলতে এত বড় দ্বিধাবিজ্ঞান আছে?

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

এই সিস্টেমগুলি থেকে সমস্ত জটিলতা দূর করা অসম্ভব। তবে আমাদের কাজ হ'ল সম্ভাব্যতা পর্যন্ত, সেই জটিলতা হ্রাস এবং পরিচালনা করা।

একটি ইউনিট পরীক্ষা কি এমন একটি পরীক্ষা যা নিশ্চিত করে, উদাহরণস্বরূপ, তিনটি ভিন্ন সিস্টেমে কোনও রিজার্ভেশন সফলভাবে পোস্ট করা হয়, একটি লগ এন্ট্রি তৈরি হয় এবং একটি ইমেল নিশ্চিতকরণ পাঠানো হয়?

আমি বলতে যাচ্ছি কোন । এটি একটি ইন্টিগ্রেশন টেস্ট। এবং এগুলির স্পষ্টতই তাদের জায়গা আছে তবে তারা একটি আলাদা বিষয়ও।

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

সুতরাং একটি ইউনিট পরীক্ষার খুব সীমিত সুযোগ থাকা উচিত।

যা বোঝায় যে ইউনিট পরীক্ষার দ্বারা পরীক্ষিত কোডটির খুব সীমিত সুযোগ থাকা উচিত।

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

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

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

"ইউনিট পরীক্ষা" পরীক্ষা-নিরীক্ষার ধারণাটি তুচ্ছ, বিস্তৃত, জটিল যুক্তি হিসাবে মনে হয়, কিছুটা অক্সিমোরন।

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

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

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

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

তবে স্বতন্ত্র ইউনিট পরীক্ষার যুক্তি যথাসম্ভব সহজ থেকে যায়।


1

এটি অবশ্যই আমার প্রতিপক্ষ, তবে গত কয়েক মাস fsharp (একটি সি # ব্যাকগ্রাউন্ড থেকে আসা) এ ফাংশনাল প্রোগ্রামিং শিখার ফলে আমি কয়েকটি জিনিস উপলব্ধি করতে পেরেছি।

ওপি যেমন বলেছে, সেখানে সাধারণত 2 প্রকারের "ইউনিট পরীক্ষা" রয়েছে যা আমরা প্রতিদিন দেখি। পরীক্ষাগুলি যে কোনও পদ্ধতির ইন এবং আউটকে অন্তর্ভুক্ত করে, যা সাধারণত সবচেয়ে মূল্যবান হয়, তবে সিস্টেমের ৮০% যা "আলগোরিদিম" সম্পর্কে কম এবং "বিমূর্ততা" সম্পর্কে আরও কম, তার পক্ষে করা শক্ত।

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

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

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

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