ইউনিট পরীক্ষা কি আসলেই দরকারী? [বন্ধ]


98

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

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

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

সুতরাং প্রশ্ন নম্বর 1: এএসপি.নেট ওয়েবের জন্য ইউনিট পরীক্ষাগুলি লিখতে এমন কিছু তৈরি হয় যা প্রায়শই করা হয় এবং যদি এটি হয়: "গতিশীল পরিবেশ" সমস্যাটি কীভাবে সমাধান করব?

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

সুতরাং, প্রশ্ন নম্বর 2: আপনি ছেলেরা আমাকে ইউনিট পরীক্ষা লিখতে শুরু করার পরামর্শ দিবেন? আমি মনে করি এটি প্রকৃত বাস্তবায়নে আমাকে সহায়তা করতে পারে তবে তারপরে আবার আমার মনে হয় এটি আমাকে ধীর করে দিতে পারে।


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

9
কোনও ইউনিট পরীক্ষা না লিখে আপনি কীভাবে ইউনিট টেস্টিংটি কভার করেছিলেন? এটি কি এই "গ্রেড নিজেই" বা "আপনার নিজস্ব পাঠ্যক্রমের নকশা" স্কুলগুলির মধ্যে একজন ছিল?
জেফো

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

13
-1 দুঃখিত, আমি সবই ভাল যুক্তির পক্ষে, যদিও আমি রাজি নাও, তবে এটি কেবল ভুল। কেউ দাবি করেন না যে "ইউনিট টেস্টগুলি নতুন কোডে বাগ ধরার জন্য", সুতরাং এটি স্ট্রো ম্যান - ইউনিট টেস্টগুলি রিগ্রেশনগুলি ধরার জন্য । এবং ডিজকস্ট্রের উদ্ধৃতিটি প্রসঙ্গের বাইরে নেওয়া হয়েছে - প্রসঙ্গটি হ'ল যদি আপনার সমস্যাটির একটি আনুষ্ঠানিক বিবরণ থাকে তবে পরীক্ষা করা অর্থহীন ।
10:25 এ sleske

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

উত্তর:


124

আমার মতে: হ্যাঁ তারা, এবং হ্যাঁ আপনার উচিত।

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

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

  3. আপনার কোড কীভাবে কাজ করে এবং কীভাবে এটি ব্যবহার করবে সে সম্পর্কে তারা অন্যান্য বিকাশকারীদের ডকুমেন্টেশন হিসাবে পরিবেশন করে।

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

তা ছাড়া আপনার কেবল ইউনিট পরীক্ষা লেখার ক্ষেত্রে দক্ষ হতে হবে। আপনি যদি টিডিডি অনুশীলন করেন তবে আপনার কোডটি পরীক্ষামূলকভাবে তৈরি করা হয়েছে other অন্য কথায়, দুর্দান্ত এবং পরিষ্কার।

আমি আপনাকে অনুশীলন করতে এবং প্রোগ্রামটি যুক্ত করার পরামর্শ দেব। একঘণ্টা পরে:

বা, প্রথম পর্যালোচনার জন্য:


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

21
ইউনিট-পরীক্ষাগুলি যদি ডকুমেন্টেশন হিসাবে কাজ করে তবে কিছু ভুল আছে। 5 টি লাইনের কোড কাজ কীভাবে পিছনের দিকে তা বোঝার জন্য 500 লাইন কোডের পঠন।
কোডার

4
@ কোডার: আপনি যখন উচ্চ স্তরের পদ্ধতি পরীক্ষা করেন তখন এতে 5 টি লাইনের কোডের বেশি থাকে।

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

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

95

না।

ইউনিট পরীক্ষার পিছনে ধারণাটি এমন এক ভিত্তির উপর ভিত্তি করে তৈরি করা হয়েছে যা ইউনিট পরীক্ষার আগে আবিষ্কার হওয়ার আগে থেকেই এটি মিথ্যা বলে পরিচিত ছিল: পরীক্ষাগুলির দ্বারা আপনার কোডটি সঠিক কিনা তা প্রমাণ করতে পারে the এই ধারণাটি।

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

জিক্সদ্র 1988 সালে পরীক্ষার-হিসাবে-প্রুফ-অফ- প্রুফেন্সের ধারণাটি ট্র্যাশ করেছিলেন এবং তিনি যা লিখেছেন তা আজও ঠিক ততটাই বৈধ:

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

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

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

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


69
এটি প্রমাণিত করে যে আপনার কোডগুলি সেই পরীক্ষাগুলির জন্য সঠিকভাবে আচরণ করে । আপনি যদি আমাকে জিজ্ঞাসা করেন তবে এটি একটি প্রচুর পরিমাণে।
স্টেফানো বোরিনি

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

40
> but if the test itself is buggy, then you have false confidenceএবং যদি ম্যানুয়াল পরীক্ষক এর কাজটি সঠিকভাবে সম্পাদন না করে তবে আপনারও ভ্রান্ত আস্থা রয়েছে।
স্টেফানো বোরিনি

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

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

60

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

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

এখানেও একটি মজাদার চিত্র ... এখানে চিত্র বর্ণনা লিখুন

আমি এই চিত্রটি এখানে পেয়েছি:
http://www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/


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

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

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

15
@ ম্যাসনহিলার আপনি জেনোর প্যারাডক্সের প্রথমটিতে ব্যর্থ হন । আপনি যদি এই চিত্রটি এসকিউএলাইটের পরীক্ষার পর্যায়ে বাড়িয়ে তুলতে চান তবে এক্স-অক্ষকে তার বর্তমান দৈর্ঘ্যের 100 গুনের মতো কিছু প্রসারিত করতে হবে।
ইজকাটা

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

49

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

তারা বিন্দু মিস করছি।

ইউনিট টেস্টিং এর উত্তর নয়। পরীক্ষা হচ্ছে।

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

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

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

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

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

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

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

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

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

টিএল; ডিআর: ইউনিট পরীক্ষার বিষয়ে এখনও চিন্তা করবেন না । প্রথমে আপনার সফ্টওয়্যারটি পরীক্ষা করার বিষয়ে চিন্তা করুন ।


ইউনিট টেস্টগুলি মানুষের দ্বারাও লিখিত হয়, এবং ভুল হতে পারে।
Seun Osewa

41

এটা নির্ভর করে

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

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

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


এটি একটি ভালো দিক. আপনাকে কীভাবে ভাল পরীক্ষাগুলি লিখতে হবে যা SUT এর মান ক্যাপচার করে তা জানতে হবে।
অ্যান্ডি

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

38

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

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

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

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

এবং সর্বশেষে তবে সর্বনিম্ন নয়, ব্রায়ানের মন্তব্য যা আমি মনে করি পুরো বিষয়টি নখ করে:

(...) তারা আপনার আত্মবিশ্বাস বাড়িয়ে তোলে (বা হওয়া উচিত ...) যে কোডটি আপনি এটি করার জন্য ডিজাইন করেছেন সেটি করে এবং আগামীকাল যা করে তা আজ অবিরত করে চলে।

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

* তারা ধীরে ধীরে তাদের কোড বেসটিতে আরও এবং আরও পরীক্ষা চালিয়ে যায় তবে এই জিনিসটি সাধারণত কীভাবে দেখায় আমরা সবাই জানি।


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

25

এএসপি.নেট ওয়েবফর্মগুলির জন্য ইউনিট টেস্টগুলি লিখে যা প্রায়শই হয়ে থাকে এবং যদি হয়: "গতিশীল পরিবেশ" সমস্যাটি কীভাবে সমাধান করব?

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

আপনি কি আমাকে ইউনিট পরীক্ষা লেখা শুরু করার পরামর্শ দিবেন? আমি মনে করি এটি সত্যিকারের বাস্তবায়নে আমাকে সহায়তা করতে পারে, তবে তারপরে আবার আমার মনে হয় এটি আমাকে ধীর করে দিতে পারে।

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

একটি বিষয় লক্ষণীয় যে তারা সাধারণত আপনাকে ধীর করে দেয়।

ঠিক আছে.

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


8
প্রশ্নের ব্যবহারের ক্ষেত্রে উত্তর দেওয়ার জন্য +1! অন্য প্রত্যেকে "ইউনিট পরীক্ষা" অংশে ঝাঁপিয়ে
পড়েছিল এবং

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

11

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

কারণ আপনি কখনই বড় প্রোগ্রাম করেননি।

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

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

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

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

-আপনি কি আমাকে পরামর্শ দেবেন ইউনিট পরীক্ষা লেখার জন্য?

হ্যাঁ জাহান্নাম. প্রথমে বেকের "টেস্ট চালিত বিকাশ" পড়ুন ।

আমি মনে করি এটি সত্যিকারের বাস্তবায়নে আমাকে সহায়তা করতে পারে, তবে তারপরে আবার আমার মনে হয় এটি আমাকে ধীর করে দিতে পারে।

এটি আপনাকে এখন কমিয়ে দেয়। কিন্তু যখন আপনাকে দিনের পরিবর্তে ঘন্টার জন্য ডিবাগ করতে হবে, আপনি আপনার মতামত পরিবর্তন করবেন।

কোন পরামর্শ প্রশংসা করা হবে :)

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


8

সম্পাদনা: আমি অবশ্যই টিডিডি প্রো / কন ডগপাইল এবং যোগদান করা প্রশ্ন # 1 এ যোগদান করেছি:

1 - এএসপিএন ওয়েবফোমে ইউনিট পরীক্ষাগুলি প্রয়োগ করছে:

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

2 - ইউনিট পরীক্ষাগুলি প্রথম স্থানে সার্থক কিনা তা নিয়ে:

ঠিক আছে, সম্পূর্ণ প্রকাশ:

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

যাহোক,

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

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

সুতরাং হ্যাঁ, আপনার ডিজাইনের দক্ষতাগুলি সম্পূর্ণ ক্র্যাপ হয় বা আপনি যদি 1-2 মানের দেব সমস্যাগুলিতে বড় পরিমাণে মাঝারি ডিভস নিক্ষেপ করে থাকেন তবে এখানে কয়েকটি টুইটের জন্য প্রচুর সুযোগ রয়েছে এবং সেখানে ব্যর্থতার বিশাল ক্যাসকেড তৈরি করার সুযোগ রয়েছে।

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

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

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

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

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


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

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

5

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

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

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

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

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

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

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

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

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

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

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

এখন, যা বলা হয়েছিল, ইউনিট পরীক্ষার অসুবিধাগুলি রয়েছে:

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

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

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

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

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

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

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


4

সঠিকভাবে ব্যবহার করার সময় ইউনিট পরীক্ষাগুলি দরকারী; আপনার যুক্তি দিয়ে বিভিন্ন সমস্যা আছে।

কেভিন বলেছিলেন, "যখন আমি বিকাশ করি তখন আমি প্রচুর পরীক্ষা-নিরীক্ষার মধ্য দিয়ে যাই"।

কাকতালীয়ভাবে প্রোগ্রামিং দেখুন। কোনও কোড কী করা উচিত তা বোঝা এবং তারপরে প্রমাণ করুন যে এটি ইউনিট পরীক্ষার মাধ্যমে এটি করে। আপনি কোনও প্রোগ্রামটি চালানোর সময় ইউআই ভাঙ্গেনি বলে কেবল একটি কোড কাজ করে তা ধরে নেই!

s writing unit tests for ASP.NET web forms something that is done often

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

So, question number 2: Would you guys advise me to start writing unit tests?

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


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

4

ব্যবহারিক স্তরে ইউনিট পরীক্ষাগুলি একটি অত্যন্ত গুরুত্বপূর্ণ কারণে অত্যন্ত কার্যকর হতে পারে: আপনি একবারে একটি কোডের একটি বিট পরীক্ষা করতে পারেন।

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

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

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

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


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

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

4

একটি জিনিস যা স্পর্শ করে বলে মনে হচ্ছে না তা হ'ল বিভিন্ন ধরণের কোড পরীক্ষা করার জটিলতা।

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

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

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


4

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

ইউনিট পরীক্ষাগুলি corner stonesমিশন সমালোচনামূলক অ্যাপ্লিকেশনগুলির এবং এগুলি নির্ভরযোগ্যতা এবং মানসিক শান্তি সরবরাহ করে যা মূল কার্যকারিতা প্রত্যাশা অনুযায়ী সম্পাদন করে।

প্রকৃতপক্ষে আপনি ASP.NET এমভিপি প্যাটার্নের সাহায্যে ইউনিট পরীক্ষার প্রবর্তন করতে পারেন যা আপনার ওয়েব ফর্ম বিকাশে ব্যবহার করা যেতে পারে। এটি উদ্বেগ এবং পৃথকীকরণ প্রবর্তন করবে ability to write essential unit tests

দেখার জন্য সহায়ক হতে পারে এমন কয়েকটি উল্লেখ:


2
+1 আপনি ইউনিট পরীক্ষা করছেন বা না করছেন এটি বিবেচ্য নয়, এমভিপি হ'ল ওয়েব ফর্মগুলির সাথে কাজ করার সময় (সম্ভবত উইনফর্মগুলিও)।
সিমোরাম্যান

3

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


6
ভয় ছাড়া সুরক্ষা একটি মিথ্যা ধারণা।
কোডার

হতে পারে "কম ভয়" একটি ভাল বাক্যাংশ, তবে উত্তর এখনও মূলত সঠিক।
ব্রেন্ডন লং

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

2

এটি আমার অভিজ্ঞতা যে হ্যাঁ , ইউনিট পরীক্ষাগুলি কার্যকর।

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

ইউনিট টেস্টিং বিভিন্ন সুবিধা দেয়:

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

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

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

যাহোক...

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


1

পরীক্ষার জন্য অল্প সংখ্যক স্তরযুক্ত সহজ অ্যাপ্লিকেশনগুলির জন্য (মূল উইন্ডো -> উপ মেনু), সম্ভবত পরিবর্তনগুলি পরীক্ষা করতে চালনা করার জন্য সংকলন করা ঠিক আছে।

আপনি যে পৃষ্ঠাগুলির পরীক্ষা করছেন তাতে ওটি পেতে 30 টি নেভিগেশন লাগে এমন বৃহত্তর অ্যাপ্লিকেশনগুলির জন্য এটি খুব ব্যয়বহুল হয়ে যায় ..


1

আমি এটিতে একটি নতুন দিক যুক্ত করতে চাই (প্রকৃতপক্ষে, বরং একটি পুরানো): আপনার কোডটি সুনির্দিষ্টভাবে ডিজাইন করা থাকলে ইউনিট পরীক্ষাগুলি তেমন কার্যকর নয় ।

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

আমার ধারণা আপনি আর কোনও প্রোগ্রাম ডিজাইন করবেন না - বর্তমান লোকেরা আপনাকে এটি না করার জন্য ছাঁচে চাপ দেবে - তবে সম্ভবত এটি মনে রাখা মূল্যবান যে ইউনিট পরীক্ষাটি ডিজাইনের তুলনায় খুব কম দক্ষতার পদ্ধতি method

এটি একটি ডাইজস্ক্রিয়িয়ান যুক্তি: ইউনিট পরীক্ষা কেবলমাত্র এমন কোনও প্রোগ্রামের বিরুদ্ধে চালানো যেতে পারে যা যথেষ্ট পরিমাণে চালানো যায়।

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

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

10 + -5 ক্লাসটি কী কী আপত্তি করে বা আপনি এখনই কী করছেন তা জানতে হবে এবং একাধিক দৃষ্টিকোণ থেকে আপনার কোড পরীক্ষা করতে সক্ষম হবেন, প্রতিটি চিত্রটি আপনি যে দৃষ্টিকোণটি দেখছেন ঠিক তার প্রতিনিধিত্ব করে এবং আপনি হাজার হাজার বাগ মুছে ফেলবেন কাগজে.

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

এখানে অনেক সহজ ...

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

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

কখনও কখনও আমি সরাসরি একটি অঙ্কন 3-4 দিনের জন্য কোডের একটি লাইন করি না। তারপরে, একদিনে, আমি 1500-2000 লাইনে টাইপ করি। পরের দিন, তারা বেশিরভাগ উত্পাদন প্রস্তুত। কখনও কখনও ইউনিট পরীক্ষাগুলি লেখা হয় (80%% কভারেজ সহ), কখনও কখনও (পাশাপাশি) পরীক্ষকরা এটি ভাঙার চেষ্টা করতে বলা হয়, প্রতি একক সময় কিছু লোককে এটি দেখে পর্যালোচনা করতে বলা হয়।

আমি এখনও সেই ইউনিট পরীক্ষাগুলি কিছু খুঁজে পাচ্ছি না।

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


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

আমাকে বিশ্বাস করুন, একাকী ফাংশন কোনও A4 (বা মার্কিন পত্র) কাগজে ফিট করে না। কখনও কখনও আমি যখন অলস হয় আমি কীবোর্ডে "ডিজাইন" করি তবে এটি একই মানের নয়। আমি যখনই গুরুতর বিকাশ করি, আমি ইউএমএল দিয়ে ডিজাইন করি। আপনি যখন এগুলি অঙ্কন করছেন, আপনি কী কী ঘটছে তা অনেক সীমাবদ্ধ তবে এখনও কাঠামোগত উপায়ে নিজেকে এবং অন্যদের কাছে ব্যাখ্যা করার চেষ্টা করছেন এবং যখন আপনি কোডটি প্রতিটি একক দৃষ্টিকোণ থেকে ব্যাখ্যা করতে সক্ষম হন, কেবল তখনই আপনি টাইপ করুন এটি
হ'ল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.