ইউনিট পরীক্ষাগুলি আমার নিজস্ব পদ্ধতি ব্যবহার করা উচিত নয়?


83

আজ আমি একটি " JUnit বেসিক" ভিডিও দেখছিলাম এবং লেখক বলেছিলেন যে আপনার প্রোগ্রামে একটি প্রদত্ত পদ্ধতি পরীক্ষা করার সময়, আপনার প্রক্রিয়াতে আপনার নিজস্ব পদ্ধতি ব্যবহার করা উচিত নয়।

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

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

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

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

আপনি কি এই সম্পর্কে আপনার অন্তর্দৃষ্টি ভাগ করতে পারেন?


79
একটি ইউনিট পরীক্ষাটি দেখে মোটেও আশ্চর্যজনক যে ডেটাবেসটি
একেবারেই

4
আইএমও এটি অন্য ক্লাসগুলিকে আইএফএফ বলার জন্য ঠিক আছে যে তারা যথেষ্ট দ্রুত। ডিস্কে বা কোনও নেটওয়ার্কে যেতে হয় এমন যে কোনও কিছুই মক করুন। সরল অল 'শ্রেণির আইএমওকে উপহাস করার কোনও অর্থ নেই।
রাবারডাক

2
এই ভিডিওতে একটি লিঙ্ক আছে?
candied_orange

17
" ভিবিএর জন্য রুবারডাক্ককে সঠিকভাবে ইউনিট-পরীক্ষিত ধন্যবাদ " - আপনি স্যার, আমার দিনটি সবেমাত্র তৈরি করেছেন। আমি টাইপগুলি সংশোধন করে এটিকে "রাবারডাক" থেকে "রুবারডাক্কে" এডিট করতাম, তবে আমার মনে হয় কিছু স্প্যামার এটি করছে এবং রাবারডাকভ্ব.বা.কম এ একটি লিঙ্ক যুক্ত করছি (আমি ডোমেনের নামের মালিক এবং প্রকল্পটির সহ-মালিক @ রাবারডাক) - সুতরাং আমি এখানে পরিবর্তে এখানে মন্তব্য করব। যাইহোক, বিগত দুই বছরের ভাল অংশের জন্য আমার বেশিরভাগ নিদ্রাহীন রাতের জন্য দায়ী করা সেই সরঞ্জামটি লোকেরা আসলে ব্যবহার করছে তা দেখতে বিস্ময়কর! =)
ম্যাথিউ গুইনডন

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

উত্তর:


186

তাঁর দাবির চেতনা সত্যই সঠিক। ইউনিট পরীক্ষার বিষয় হ'ল কোড বিচ্ছিন্ন করা, নির্ভরতা ছাড়াই এটি পরীক্ষা করা, যাতে যে কোনও ভুল কাজটি যেখানে ঘটছে তা দ্রুত সনাক্ত করা যায়।

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

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


117
ব্যবহারিকতার জন্য হুরয়।
রবার্ট হার্ভে

6
আমি যোগ করব যে গতি হিসাবে নির্ভরযোগ্যতা আটকানো বাড়ে যে সমস্যা যে সমস্যা হিসাবে অনেক নির্ভরযোগ্যতা নয়। বিচ্ছিন্নতা মন্ত্রের পরীক্ষাটি এতটাই বাধ্যতামূলক যে এই যুক্তিটি প্রায়শই মিস হয়।
মাইকেল ডুরান্ট

4
"... ইউনিট পরীক্ষা করা একটি সরঞ্জাম, এবং এটি আপনার উদ্দেশ্যগুলি পরিবেশন করা বোঝানো হয়, এটি প্রার্থনা করা বেদী নয়" "- এটি!
ওয়েন কনরাড

15
"প্রার্থনা করার মতো বেদী নয়" - ক্ষুব্ধ টিডিডি কোচ আগত!
ডেন

5
@ jpmc26: এর চেয়েও খারাপ আপনি আপনার সমস্ত ইউনিট পরীক্ষা পাস করতে চান না কারণ তারা ওয়েব পরিষেবাটি সঠিকভাবে হ্যান্ডল করেছে যা একটি বৈধ এবং সঠিক আচরণ, তবে আসলে কখনই কোডটি ব্যবহারের সময় ব্যয় করা হয়নি! একবার স্ট্যাব করে ফেললে আপনি এটি "আপ" বা "ডাউন" কিনা তা চয়ন করতে পারেন এবং উভয়কেই পরীক্ষা করেন।
স্টিভ জেসপ

36

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

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

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

আমি সন্দেহ করি যে আপনি "ইউনিট পরীক্ষা" শব্দের আলগা সংস্করণটি ব্যবহার করছেন এবং বাস্তবে একটি "ইন্টিগ্রেশন টেস্ট" উল্লেখ করছেন।

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

আপনার একীকরণ পরীক্ষা বা ইউনিট পরীক্ষার উপর নির্ভর করা উচিত বা উভয়ই আলোচনার অনেক বড় বিষয়।


আপনি আপনার সন্দেহ সঠিক। আমি শর্তগুলির অপব্যবহার করছি এবং আমি এখন দেখতে পাচ্ছি যে প্রতিটি ধরণের পরীক্ষা আরও কীভাবে সঠিকভাবে পরিচালনা করা যায়। ধন্যবাদ!
carlossierra

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

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

1
আপনার প্রথম শ্রেণীতে যারা খুব বড় অংশ থেকে, অবশ্যই @EricKing, খুব ধারণা ডাটাবেসের জড়িত এ সব ইউনিট পরীক্ষা অভিশাপ হয়, কিনা আপনি আপনার DAOs ব্যবহার করুন অথবা ডাটাবেসের সরাসরি আঘাত।
পেরিটা ব্রেটাটা

1
@ আমানীকিলুমঙ্গা প্রশ্নটি মূলত "কেউ বলেছে ইউনিট টেস্টে আমার এই জিনিসটি করা উচিত নয় তবে আমি ইউনিট পরীক্ষায় এটি করি এবং আমার মনে হয় এটি ঠিক আছে। কি ঠিক আছে?" এবং আমার উত্তর ছিল "হ্যাঁ, তবে বেশিরভাগ লোক একে ইউনিট পরীক্ষার পরিবর্তে একটি ইন্টিগ্রেশন টেস্ট বলে।" আপনার প্রশ্ন হিসাবে আমি জানি না আপনি "ইন্টিগ্রেশন টেস্টগুলি উত্পাদন কোড পদ্ধতি ব্যবহার করতে পারে?" বলতে কী বোঝায়?
এরিক কিং

7

উত্তরটি হ্যা এবং না...

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

এই ক্রস-ইউনিট পরীক্ষাগুলি কোড কভারেজের জন্য ভাল এবং শেষ কার্যকারিতাটির পরীক্ষা করার সময় তবে এটি কয়েকটি ঘাটতি নিয়ে আসে যা সম্পর্কে আপনার সচেতন হওয়া উচিত:

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

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

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


4

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

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


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

1

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

ডাটাবেসে কোনও রেকর্ড তৈরি হয়েছে কিনা তা পরীক্ষা করে দেখা যায় যে সিস্টেমের বাকী অংশের সাথে প্রকাশিত কার্যকারিতার ইউনিটটি পরীক্ষা করার পরিবর্তে স্টোরেজ প্রক্রিয়াটির বাস্তবায়ন বিশদের সাথে সম্পর্কিত।

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

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


1

স্পিরিট ঠিক আছে।

আদর্শভাবে, একটি ইউনিট পরীক্ষায় , আপনি একটি ইউনিট (একটি পৃথক পদ্ধতি বা ছোট শ্রেণি) পরীক্ষা করছেন।

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

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

অবশ্যই, এটি কোনও সফ্টওয়্যার প্রকল্পের একটি উচ্চ লক্ষ্য যা গেট-গো থেকে এই কাজটি করে না। তবে এটি ইউনিট পরীক্ষার চেতনা ।

মনে রাখবেন যে অন্যান্য পরীক্ষা আছে যেমন বৈশিষ্ট্য পরীক্ষা, আচরণ পরীক্ষা ইত্যাদি যা এই পদ্ধতির থেকে পৃথক - "ইউনিট টেস্টিং" দিয়ে "পরীক্ষা" বিভ্রান্ত করবেন না।


"কেবল নিশ্চিত করুন যে এটি সঠিক ডিবিতে সঠিক ডিবি এপিআইগুলি কল করে" - হ্যাঁ, নিশ্চিত। যতক্ষণ না এটি প্রমাণিত হয় আপনি ডকুমেন্টেশনগুলি ভুলভাবে পড়েছেন এবং আপনার ব্যবহার করা উচিত ছিল প্রকৃত সঠিক ক্রমটি সম্পূর্ণ আলাদা। আপনার নিয়ন্ত্রণের বাইরে সিস্টেমগুলি উপহাস করবেন না।
জোকার_ভিডি

4
@ জোকার_ভিডি এটিই ইন্টিগ্রেশন পরীক্ষার জন্য। ইউনিট পরীক্ষায়, বাহ্যিক সিস্টেমগুলি একেবারে উপহাস করা উচিত।
বেন অ্যারনসন

1

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

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

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


1

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

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

@Test
public void canSaveData() {
    writeDataToDatabase();
    // what can you assert - the only expectation you can have here is that an exception was not thrown.
}

@Test
public void canReadData() {
    // how do I even get data in there to read if I cannot call the method which writes it?
}

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

@Test
public void widgetsCanBeStored() {
    Widget widget = new Widget();
    widget.setXXX.....
    // blah

    widgetDao.storeWidget(widget);
    Widget stored = widgetDao.getWidget(widget.getWidgetId());
    assertEquals(widget, stored);
}

এটি একটি যৌক্তিক, সংহত, নির্ভরযোগ্য এবং আমার মতে, অর্থপূর্ণ পরীক্ষা।

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

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


খুব অন্তর্দৃষ্টিযুক্ত পদ্ধতির, এবং আপনি যেমন বলেছিলেন, আমার মনে হয় আপনি আমার কাছে যে মূল সন্দেহ পোষণ করেছিলেন তা সত্যিই আঘাত করেছিলেন। ধন্যবাদ!
carlossierra

0

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

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

যদি তাদের মধ্যে কেউ তার যা করা উচিত তা না করে তবে তার নিজের পরীক্ষার কেস ব্যর্থ হবে এবং আমরা এটি ঠিক করতে পারি এবং আবার পরীক্ষার ব্যাটারি চালাতে পারি।

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

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

যদি আপনার কোডটি ইউনিট পরীক্ষার জন্য ভালভাবে ডিজাইন করা হয়েছে, তবে কমপক্ষে দুটি উপায় রয়েছে যা আপনি টেস্টের অধীনে থাকা পদ্ধতিতে ডেটাটি সঠিকভাবে বজায় রেখেছেন কিনা তা পরীক্ষা করে দেখতে পারেন:

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

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

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

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


0

এইভাবে আমি এটি করতে পছন্দ করি। এটি কেবলমাত্র একটি ব্যক্তিগত পছন্দ কারণ এটি পণ্যের ফলাফলকে প্রভাবিত করবে না, কেবল এটি উত্পাদন করার উপায়।

আপনি যে অ্যাপ্লিকেশনটি পরীক্ষা করছেন এটি ছাড়াই আপনার ডাটাবেসে মক মান যুক্ত করতে সক্ষম হওয়ার সম্ভাবনাগুলির উপর এটি নির্ভর করে।

ধরা যাক আপনার দুটি পরীক্ষা রয়েছে: ক - ডাটাবেস বি পড়া - ডাটাবেসে সন্নিবেশ করান (এ এর উপর নির্ভর করে)

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

আমি ইউনিট-পরীক্ষায় কিছু প্রশ্ন লেখার চেষ্টা করব না যেহেতু আপনি অ্যাপ্লিকেশনটির পিছনে ডিবি কাঠামোটি জানতে সক্ষম হবেন না (বা এটি পরিবর্তন হতে পারে)। অর্থাত আপনার কোডের কারণে নিজের পরীক্ষার কেস ব্যর্থ হতে পারে। আপনি যদি পরীক্ষার জন্য পরীক্ষা না লিখে থাকেন তবে পরীক্ষার জন্য পরীক্ষাটি কে পরীক্ষা করবে ...


-1

শেষ পর্যন্ত, আপনি যা পরীক্ষা করতে চান তা নেমে আসে।

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

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

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

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


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