একজন পেশাদার বিকাশকারী হিসাবে, ইউনিট পরীক্ষা না লেখার পক্ষে এটি কি গ্রহণযোগ্য? [বন্ধ]

Question

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

Comments

আপনি চেষ্টা করেছেন, না আপনি অজুহাত খুঁজছেন?

তারপরে উত্তরটি হ'ল "এটি নির্ভর করে যাঁরা আপনাকে অর্থ প্রদান করেন তারা কী চান আপনি"।

@ ফ্লাওয়ারেন্টস "এর" আছে - ভাল, না, অগত্যা নয়। কেমন JWZ 1994 সালে নেটস্কেপ ব্রাউজার থেকে বেরিয়ে এলাম একটি পাল্টা উদাহরণ টি দেখতে jwz.org/blog/2009/09/that-duct-tape-silliness । তাদের পক্ষে এটির জন্য সময় ছিল না এবং ইউনিট পরীক্ষাগুলি সাধারণত রক্ষণাবেক্ষণের মোডে না পৌঁছানো অবধি পরিশোধ করে না।

থাকুক বা না থাকুক এটা তথাপি গ্রহণযোগ্য , আমার পেশাগত অভিজ্ঞতা হয়েছে এটি করা হয় গৃহীত ।

— কারসন 63000

আমি আশা করি আমি পেশাদার (20+ বছরের অভিজ্ঞতা)। আমি আমার বেশিরভাগ কোডের জন্য ইউনিট পরীক্ষা লিখছি না (তুচ্ছ রানটাইম লাইব্রেরি ছাড়াও)। আমি পরিবর্তে চুক্তি এবং ইন্টিগ্রেশন পরীক্ষা লিখি। এবং আমি অবশ্যই কোনও রূপে OOD / OOP ব্যবহার করছি না।

— এসকে-যুক্তি

Answer 1

কি পরীক্ষা?

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

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

Answer 2

তত্ত্ব

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

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

আবারও, এটি পুরো সিস্টেমটি কাজ করবে কিনা তার গ্যারান্টি দেয় না, তবে এটি পরীক্ষার বিষয়টি সহজ করে দেয়।

টিডিডি নিজেই প্রয়োজন হয় না। এটি কোনও বিকাশকারীকে প্রথমে উত্তর দেওয়ার জন্য জোর করে কোডিংকে সহজতর করে, "আমি আসলে কোডটিতে যাচ্ছি?"

খরচ

অনেকেই মনে করেন পরীক্ষা না লিখে তারা তাদের সময় বাঁচায়। ভুল। কৌশলগতভাবে চিন্তাভাবনা করে, একটি ত্রুটির ব্যয় ততক্ষণে প্রদর্শিত হওয়ার পরে সনাক্তকরণ অবধি ততক্ষণে বৃদ্ধি পায় ।

বলুন যে আপনি আপনার কোডটিতে একটি ত্রুটি করেছেন এবং একই দিন এটি সনাক্ত এবং ঠিক করেছেন। ব্যয় $ এক্স ।
ধরা যাক ত্রুটিটি সনাক্ত করা যায় না এবং সাপ্তাহিক অভ্যন্তরীণ বিল্ডে যায়। ভাগ্যক্রমে, কিউএ এটি সনাক্ত করেছে, বাগ ট্র্যাকারে একটি বাগ উত্থাপন করেছে, বিষয়টি 5 জনের মিটিং ইত্যাদিতে 5 মিনিটের আলোচনার বিষয় ছিল Finally ব্যয়টি প্রত্যেকের দ্বারা ব্যয় করা জনশক্তির যোগফল এবং এই ক্ষেত্রে এটি $ 3 * এক্স হতে পারে ।
যদি ত্রুটিটি বিটা পরীক্ষায় চলে যায় এবং আরও বেশি লোককে জড়িত করে? ধরা যাক, * 10 * এক্স ।
যদি এটি দীর্ঘ সময়ের জন্য সনাক্ত না থাকে, এক হাজার গ্রাহকের কাছে গিয়েছিলেন (আশা করি, এক মিলিয়ন নয়!), তাদের মধ্যে 10 এটি সনাক্ত করেছেন, তারা আপনার সমর্থন কর্মীদের সাথে একটি আলোচনা উত্থাপন করেছেন, কেউ আপনার বসকে ডেকে থাকতে পারে, আপনার সতীর্থরা এটি পুনরুত্পাদন করার চেষ্টা করছে , ইত্যাদি ইত্যাদি। অবশেষে, বাগটি আপনার কাছে ফিরে আসে এবং আপনি এটি ঠিক করেন। মোট কত? ওয়েল । 50 * এক্স এর বেশি ।

আপনি দেখতে পাচ্ছেন, খুব শীঘ্রই বা আপনার কাছে ফিরে আসা বাগ (বা আপনার সহকর্মী) আসবে । পার্থক্য হ'ল এটি কখন ঘটে এবং এর জন্য কত ব্যয় হত।
ইউনিট পরীক্ষাগুলি বাগের একটি জীবনকালকে সংক্ষিপ্ত করে এবং এর ফলে ব্যয় হ্রাস করে।

প্রো এর

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

কন এর

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

Comments

টিডিডি হ'ল এপিআই-র অধিকার পাওয়ার জন্য।

আপনি নিম্নলিখিতটি বলছেন যেন এটি একটি বৈপরীত্য, তবে এটি নয়: There's a common misconception that unit tests are for testing "units". Unit tests, likewise all other tests, test functionality.ইউনিট পরীক্ষাটি অবশ্যই ইউনিট পরীক্ষা করার জন্য ; নামটি এখান থেকেই এসেছে।

— আন্দ্রেস এফ।

@AndresF। আইএমএইচও, ইউনিটগুলিকে কোড সাজানোর পদ্ধতি হিসাবে বিবেচনা করা উচিত, তবে পরীক্ষার বিষয় নয়। তেমনি "এক কাপ কফি পান করা" মানে কাপে সাজানো কফি পান করা, এক কাপ পান না করা। :)

— বাইটবাস্টার

Answer 3

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

Answer 4

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

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

Comments

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

— অ্যান্ড্রেস এফ।

Answer 5

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

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

Answer 6

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

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

Comments

ইউনিট টেস্টিং কোনও নির্দিষ্টকরণের আনুগত্যের একমাত্র উপায় নয়। এটা এমনকি সবচেয়ে কঠোর নয়।

— স্টেফ

@ কে.স্টেফ আপনি সম্পূর্ণরূপে সঠিক। আমি আশা করি "আপনার যা যা প্রয়োজন তা ইউনিট টেস্টিং" হিসাবে আমার উত্তরটি পড়া শক্ত।

— ভ্যাটাইন

Answer 7

আমি এখানে একটি অঙ্গ নিয়ে যেতে যাচ্ছি এবং বলব যে এটি বেশিরভাগ বিষয়ভিত্তিক এবং আপনার লক্ষ্যগুলির উপর নির্ভর করে। tl; dnr: এটি করা ভাল, তবে এটি সম্পর্কে কৌতূহলবাদী হওয়া আরও সমস্যা তৈরি করতে চলেছে।

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

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

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

সুতরাং এটি সম্ভবত কিছু ফাংশন হতে চলেছে

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

অনেকগুলি পরিস্থিতি রয়েছে যেখানে ইউনিট পরীক্ষা না লিখে গ্রহণযোগ্য হবে। টিডিডি এখনই 'ইন' রয়েছে, তবে এটি কোনও রূপালী বুলেট নয়।

Answer 8

এটি রক্ষণাবেক্ষণ ইউনিট টেস্টগুলি লেখার জন্য পেশাদার যা আপনার সময় এবং অশ্রু বাঁচায়!

একটি আছে misconception that Unit test finds bugs। ওয়েল যে সব ক্ষেত্রে কেবল সত্য নয়। ইউনিট টেস্টিং ত্রুটিগুলি খুঁজে পাওয়া বা সম্পর্কিতগুলি সনাক্তকরণ সম্পর্কিত নয়। এটি সংজ্ঞা দ্বারা examine each unit of your code separately,। কিন্তু যখন আপনার অ্যাপ্লিকেশন বাস্তবের জন্য চলে তখন those সমস্ত ইউনিটকে একসাথে কাজ করতে হবে এবং সম্পূর্ণরূপে এর স্বতঃ-পরীক্ষিত অংশগুলির যোগফলের চেয়ে জটিল এবং সূক্ষ্ম।

সুতরাং, ইউনিট পরীক্ষার লক্ষ্য (টিডিডি প্রক্রিয়াটির মধ্যে) শক্তিশালীভাবে সফ্টওয়্যার উপাদানগুলি ডিজাইন করার বিষয়ে।

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

Answer 9

একজন পেশাদার বিকাশকারী হিসাবে, ইউনিট পরীক্ষা না লেখার পক্ষে এটি কি গ্রহণযোগ্য?

না।

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

এই ইউনিট পরীক্ষাগুলি কতটা বিশদ হওয়া উচিত?

লিটমাস পরীক্ষাটি এখানে: কিউএ যদি আপনার কোডটিতে একটি বাগ আবিষ্কার করে তবে আপনি কি আপনার মনিবকে আপনার যথাযথ পরিশ্রম প্রমাণের জন্য ইউনিট পরীক্ষা (গুলি) ব্যবহার করে স্বাচ্ছন্দ্য বোধ করবেন?

যদি আপনার উত্তরটি 'না' হয় তবে আপনার আরও ভাল ইউনিট পরীক্ষা (বা পরীক্ষাগুলি) তৈরি করা উচিত।
যদি আপনার উত্তরটি 'হ্যাঁ' হয় তবে আপনার কোড যাচাইকরণের জন্য প্রস্তুত।

একজন পেশাদার বিকাশকারী হিসাবে, স্বয়ংক্রিয় ইউনিট পরীক্ষা না লেখার পক্ষে এটি কি গ্রহণযোগ্য ?

হ্যাঁ.

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

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