আমার যদি ইতোমধ্যে ইন্টিগ্রেশন টেস্ট থাকে তবে ইউনিট টেস্টের দরকার কি?

Question

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

ইন্টিগ্রেশন টেস্টের ওপরে ইউনিট পরীক্ষার সুবিধাটি আমি কী জানি

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

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

Comments

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

— সিভান

এই প্রশ্নটি অস্পষ্ট বলে মনে হচ্ছে। ধরা যাক আমার কাছে একটি রেলস নিয়ন্ত্রক পদ্ধতি রয়েছে যা একটি ইন্টারঅ্যাক্টরকে ( github.com/collectiveidea/interactor ) কল করে । আমি আমার কন্ট্রোলার পদ্ধতির জন্য ইন্টিগ্রেশন টেস্টগুলি লেখার সিদ্ধান্ত নিয়েছি (কারণ এগুলি ছাড়া আমি বিশ্বাস করতে পারি না যে আমার এপিআই এন্ডপয়েন্টটি কাজ করে)। এখানে কমপক্ষে দুটি প্রশ্ন রয়েছে: (1) আমি কি আমার নিয়ামক পদ্ধতিগুলির জন্য ইউনিট টেস্টগুলিও লিখি (উদাহরণস্বরূপ, আমার ইউনিট পরীক্ষাগুলি যা আমার সংহতকরণ পরীক্ষার মতো একই আচরণের পরীক্ষা করে সেগুলি লিখতে হবে), এবং (2) আমি ইউনিট পরীক্ষাও লিখতে পারি? আমার ইন্টারেক্টর জন্য? আমি নির্দিষ্ট দুটি ব্যবসায়ের ক্ষেত্রে এই দুটি প্রশ্নের উত্তর দেব।

— ড্যানিয়েল

Answer 1

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

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

আমার বইয়ে, উপকারগুলি দ্বিধাদ্বন্দ্বের চেয়ে বেশি।

Comments

রিয়েল-ওয়ার্ল্ড ক্ষেত্রে মশকরা কি সস্তা নয় ? আপনি কেবল মক কী বার্তাগুলি প্রাপ্ত হবে তার প্রত্যাশা সেট করে রেখেছেন এবং এটি কী ফিরে আসবে তা উল্লেখ করে।

— ডগওয়েদার

@ ডগওয়েদার মকস প্রথমবার তৈরি করার সময় ভাল কাজ করে। সময় অতিক্রম করার সাথে সাথে আসল বস্তুটি পরিবর্তিত হওয়ার সাথে সাথে এর সাথে মকগুলিও পরিবর্তন করতে হবে। রাস্তায় 10 বছর এবং 6,000 ইউনিট পরীক্ষা করা, আপনার "সফল" পরীক্ষাগুলি সত্যই সফল কিনা তা জানা খুব কঠিন difficult

— রস প্যাটারসন

একদিকে যেমন, "10 বছর এবং 6,000 ইউনিট পরীক্ষা" ব্যক্তিগত অভিজ্ঞতা থেকে সংখ্যা, হাইপারবোল নয়।

— রস প্যাটারসন

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

— রোগারিও

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

— ড্যানিয়েল

Answer 2

আমি বিদ্যমান ইউনিট-টেস্টকেসকে ইউনিটেস্ট হিসাবে পুনর্নির্মাণের খুব বেশি মূল্য দেখছি না।

নন টিডিডি লেগ্যাসি অ্যাপ্লিকেশনগুলির জন্য ইন্টিগ্রেশন টেস্টগুলি প্রায়শই লেখার পক্ষে অনেক সহজ হয় কারণ সাধারণত কার্যকরীকরণের সাথে পরীক্ষা-নিরীক্ষাটি শক্তভাবে মিলিত হয় তাই বিচ্ছিন্নকরণের (= ইউনিটেস্টিং) টেস্টিং ইউনিটগুলি কঠিন / ব্যয়বহুল / অসম্ভব হতে পারে।

> Then what are the reasons to write/add unit tests?

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

কোডটি ইউনিট পরীক্ষা ছাড়াই ইতিমধ্যে উপস্থিত থাকলে ইউনিট পরীক্ষাগুলি লেখার পরে সাধারণত অনেক অতিরিক্ত কাজ হয় কারণ কোডটি সহজ পরীক্ষার জন্য লেখা হয়নি।

আপনি টিডিডি করলে কোডটি স্বয়ংক্রিয়ভাবে পরীক্ষাযোগ্য।

Comments

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

— alpha_989

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

— ব্রিট ওয়েসকট

Answer 3

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

Answer 4

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

এছাড়াও, আপনি যে বড় ভুলটি করতে পারেন তা বিশ্বাস করা

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

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

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

http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1

যদি আপনি এগুলি ইতিমধ্যে না পড়ে থাকেন।

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

Comments

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

— কেসি

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

— কেসি

Answer 5

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

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

Comments

আমি মনে করি না আপনি মামলা করেছেন। ইন্টিগ্রেশন টেস্টগুলি কোডে বাগগুলি প্রকাশ করতে পারে এবং প্রকৃতপক্ষে ইউনিট পরীক্ষাগুলি যেগুলি ত্রুটিগুলি খুঁজে পাবে না সেগুলি ধরতে সক্ষম।

— কেসী