ইউনিট পরীক্ষার পরিবর্তে গ্রহণযোগ্যতা এবং ইন্টিগ্রেশন টেস্টগুলি ব্যবহার করা কি যথেষ্ট?


62

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

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

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

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

আমি ওয়েবে সন্ধান করার পরে আমি জানতে পারি যে এখানে এবং সেখানে আমার উল্লিখিতগুলির সাথে খুব মিল রয়েছে । আপনি এই ধারণা সম্পর্কে কী ভাবছেন?

সম্পাদন করা

প্রশ্নগুলির জবাব দেওয়ার একটি উদাহরণ যেখানে নকশাটি ভাল ছিল, তবে পরবর্তী প্রয়োজনের জন্য আমার একটি বিশাল রিফ্যাক্টরিং প্রয়োজন:

প্রথমে কিছু কমান্ড কার্যকর করার জন্য কিছু প্রয়োজনীয়তা ছিল। আমি একটি এক্সটেন্ডেবল কমান্ড পার্সার লিখেছি - যা কোনও ধরণের কমান্ড প্রম্পট থেকে কমান্ডগুলি পার্স করে এবং মডেলটিতে সঠিকটিকে ডাকে। ফলাফলটি একটি ভিউ মডেল শ্রেণিতে প্রতিনিধিত্ব করা হয়েছিল: প্রথম নকশা

এখানে কোন ভুল ছিল না। সমস্ত ক্লাস একে অপরের থেকে স্বতন্ত্র ছিল এবং আমি সহজেই নতুন কমান্ড যুক্ত করতে পারি, নতুন ডেটা প্রদর্শন করতে পারি।

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

এটিও ভাল ছিল কারণ এখন প্রতিটি কমান্ডের নিজস্ব ভিউ মডেল রয়েছে এবং তাই এর নিজস্ব পূর্বরূপ।

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

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

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

উপসংহার

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

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


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

আমার পড়া প্রতি ডুপ্লিকেট প্রশ্ন উত্তর যখন সম্পর্কে প্রাথমিকভাবে হয় -unit পরীক্ষার আরো জানার জন্য
মশা

প্রথম লিঙ্কটি নিজেই একটি সদৃশ। আপনার অর্থ মনে হয়: প্রোগ্রামার্স.স্ট্যাকেক্সচেঞ্জ
রবি ডি

রবি ডি-এর লিঙ্কের উত্তরগুলি কেন কেন একেবারে পরীক্ষা করতে হবে সে সম্পর্কে আরও বেশি।
Yggdrasil

উত্তর:


37

এটি কমলা এবং আপেল তুলনা করে।

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

আমি আমার মতে বিভিন্ন পরীক্ষাগুলির প্রত্যেকটিতে যাচ্ছি এবং আশা করি যে সেগুলিগুলির একটি মিশ্রণের জন্য আপনার কেন প্রয়োজন:

সংহতকরণ পরীক্ষা:

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

গ্রহণের পরীক্ষা:

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

ইউনিট পরীক্ষা:

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

আচরণ পরীক্ষা:

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

পরীক্ষাগুলি লেখার অনেক অভিজ্ঞতার মাধ্যমে এগুলি আমার মতে; আমি পাঠ্যপুস্তকের পদ্ধতির দিকে মনোনিবেশ করতে পছন্দ করি না - বরং আপনার পরীক্ষাগুলিকে কী মূল্য দেয় তার দিকে ফোকাস করুন।


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

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

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

1
আপনি যা পরীক্ষা করছেন তার উপর নির্ভর করে - আপনি কি ব্যবসায়িক বৈশিষ্ট্যগুলি পরীক্ষা করছেন (স্বীকৃতি পরীক্ষা)? আপনি কি সংহতকরণের পরীক্ষা করছেন (সংহতকরণ পরীক্ষা)? আপনি যখন বোতামটি (আচরণের পরীক্ষা) ক্লিক করেন তখন কী পরীক্ষা করছেন? আপনি কি অ্যালগরিদম (ইউনিট পরীক্ষা) পরীক্ষা করছেন?
মাইকেল

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

40

টিএল; ডিআর: যতক্ষণ না এটি আপনার প্রয়োজনগুলি পূরণ করে, হ্যাঁ।

আমি বহু বছর ধরে অ্যাকসেপ্টেন্স টেস্ট ড্রাইভেন ডেভলপমেন্ট (এটিডিডি) বিকাশ করছি। এটি খুব সফল হতে পারে। সচেতন হওয়ার মতো কয়েকটি বিষয় রয়েছে।

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

এখন সুবিধা

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

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


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

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

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

আপনি কি কেবলমাত্র ইন্টিগ্রেশন টেস্টিংয়ের যুক্তি বনাম উভয় ইন্টিগ্রেশন এবং ইউনিট টেস্টিংয়ের (আইএমও সেরা) বিকল্পটিতে আপনার ইনপুট দিতে পারেন? আপনার উত্তর এখানে ভাল, কিন্তু এই বিষয়গুলি পারস্পরিক একচেটিয়া হিসাবে ফ্রেম বলে মনে হচ্ছে, যা আমি বিশ্বাস করি না they
স্টারম্যান্ডেলাক্স

পুনঃটুইটগুলি বরং এটি আপনি যে মূল্য থেকে পরীক্ষা নিতে চান তা একটি প্রশ্ন of আমি ইউনিট পরীক্ষা করবো যেখানেই ইউনিট পরীক্ষাগুলি লেখার মূল্য / সমর্থন ব্যয়কে ছাড়িয়ে গেছে। প্রাক্তন। আমি অবশ্যই আর্থিক প্রয়োগে যৌগিক আগ্রহের ফাংশনটি পরীক্ষা করব।
ডায়েটবুদ্ধ

18

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

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

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

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

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

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

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

    var x= new X();
    Assert.AreEqual("expected value 1" x.MyMethod("value 1"));
    Assert.AreEqual("expected value 2" x.MyMethod("value 2"));
    // ...
    Assert.AreEqual("expected value 500" x.MyMethod("value 500"));

(ধরুন মানগুলির কোনও ধরণের অর্থ রয়েছে)।

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

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

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


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

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

@ জর্জিও: একটি উদাহরণ স্পষ্ট করতে পারে: বলুন আপনার কাছে একটি উপাদান "মাইমেথড" এবং 2 টি পরামিতি রয়েছে have টিডিডি ব্যবহার করে আপনি X x= new X(); AssertTrue(x.MyMethod(12,"abc"))পদ্ধতিটি বাস্তবায়নের আগে লিখবেন । সামনে নকশা ব্যবহার করে, আপনি class X{ public bool MyMethod(int p, string q){/*...*/}}প্রথমে লিখতে পারেন , এবং পরে পরীক্ষাগুলি লিখতে পারেন। উভয় ক্ষেত্রেই, আপনি একই নকশার সিদ্ধান্ত নিয়েছেন। যদি সিদ্ধান্তটি ভাল বা খারাপ হয়, টিডিডি আপনাকে জানায় না।
ডক ব্রাউন

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

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

9

হ্যা, অবশ্যই।

এই বিবেচনা:

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

সামগ্রিক পার্থক্য দেখুন ....

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

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

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

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


7
একদম সত্য নয় ... ইন্টিগ্রেশন পরীক্ষার সাথে দুটি বগী দুটি উপাদান থাকা সম্ভব, তবে তাদের বাগগুলি ইন্টিগ্রেশন পরীক্ষায় বাতিল হয়ে যায়। যতক্ষণ না শেষ ব্যবহারকারী এটি এমনভাবে ব্যবহার করে যাতে এই উপাদানগুলির মধ্যে একটি মাত্র ব্যবহৃত হয় ...
মাইকেল শ

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

4
@ টলেমি আমি মনে করি যে ২ টি বগী উপাদান একে অপরকে বাতিল করে দিচ্ছে তার বিরলতা একে অপরের সাথে হস্তক্ষেপকারী 2 কার্যকারী উপাদানগুলির চেয়ে অনেক কম।
gbjbaanb

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

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

2

আমি মনে করি এটি একটি ভয়ঙ্কর ধারণা।

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

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


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

2
প্রকৃতপক্ষে, "এটি পরে পোলিশ করা" বলে মনে হয় আসলে কখনই ঘটে না - প্রতিটি পর্যালোচনা যেখানে আমি করি যেখানে কোনও বিকাশকারী "ধাক্কা খায়," এটি পরে করা হবে "যখন আমরা সবাই জানি, এটি ঘটবে না - প্রযুক্তিগত debtণ = আমার মতে দেউলিয়ার বিকাশকারী।
মাইকেল

3
উত্তরটি আমার কাছে উপলব্ধি করে, কেন এটি এত কম বিয়োগের ঘটনা পেয়েছিল তা জানেন না। মাইক কোহনের উদ্ধৃতি দিতে: "ইউনিট টেস্টিং একটি কঠিন পরীক্ষা অটোমেশন কৌশলের ভিত্তি হওয়া উচিত এবং যেমন পিরামিডের বৃহত্তম অংশকে উপস্থাপন করে । স্বয়ংক্রিয় ইউনিট পরীক্ষাগুলি দুর্দান্ত কারণ তারা একটি প্রোগ্রামারকে নির্দিষ্ট ডেটা দেয় — একটি বাগ রয়েছে এবং এটি চালু রয়েছে লাইন 47 " Mountaingoatsoftware.com/blog/…
guillaume31

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

2
@ ইয়েজিড্রেসিল আমি মার্টিন ফাউলারের উদ্ধৃতিও দিতে পারি: "যদি আপনি একটি উচ্চ স্তরের পরীক্ষায় ব্যর্থতা পান তবে কেবলমাত্র আপনার কার্যকরী কোডে একটি ত্রুটি নেই, আপনার একটি ইউনিট পরীক্ষাও রয়েছে"। martinfowler.com/bliki/TestPyramid.html যাইহোক, যদি একীকরণ পরীক্ষাগুলি একা আপনার জন্য কাজ করে তবে জরিমানা। আমার অভিজ্ঞতা হ'ল প্রয়োজনের সময় এগুলি ধীরে ধীরে, ইউনিট পরীক্ষার চেয়ে কম সুনির্দিষ্ট ব্যর্থতার বার্তা এবং কম চিকিত্সাযোগ্য (আরও সংযুক্তি) সরবরাহ করে। এছাড়াও, আমি যখন ইন্টিগ্রেশন টেস্টগুলি লিখি তখন কম ভবিষ্যতের প্রুফ হওয়ার প্রবণতা রাখি - প্রাক - (মিস?) সম্পর্কিত ধারণাগুলি প্রতি সেটের জন্য কোনও বস্তুর যথার্থতার চেয়ে কল্পনা করা হয়েছিল।
guillaume31

2

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

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

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

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

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

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


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

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

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

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

1

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

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

অবশ্যই ইউনিট পরীক্ষাগুলি ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে বেড়েছে, তবে তারা তাত্ক্ষণিকতার চেয়ে দ্রুত ক্রমের চেয়েও বেশি। উদাহরণস্বরূপ, আমার পূর্ববর্তী প্রকল্পে (সি ++, কিছু 600 কেপিএল, 4000 ইউনিট পরীক্ষা এবং 200 ইন্টিগ্রেশন পরীক্ষা), ইন্টিগ্রেশন টেস্টগুলি কার্যকর করতে 15 এবং তারপরে আরও বেশি কার্যকর করতে প্রায় এক মিনিট সময় লেগেছিল। অংশটি পরিবর্তিত হওয়ার জন্য ইউনিট পরীক্ষাগুলি তৈরি এবং সম্পাদন করতে, গড়ে ৩০ সেকেন্ডের চেয়ে কম সময় লাগবে। আপনি যখন এটি এত তাড়াতাড়ি করতে পারেন, আপনি সর্বদা এটি করতে চাইবেন।

কেবল এটি পরিষ্কার করার জন্য: আমি একীকরণ এবং গ্রহণযোগ্যতা পরীক্ষা যোগ না করার কথা বলছি না, তবে মনে হচ্ছে আপনি ভুল উপায়ে টিডিডি / বিডিডি করেছেন।

ইউনিট পরীক্ষা নকশা জন্য ভাল।

হ্যাঁ, পরীক্ষার যোগ্যতার কথা মাথায় রেখে ডিজাইনের নকশা আরও ভাল করে তুলবে।

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

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

এর ফলাফলটি আরও ভাল কোডের মান এবং পরীক্ষার আরেকটি স্তর। আমি বলব এটি মূল্য।


আমাদের বেশ কয়েকটি বাল্য গ্রহণযোগ্যতা পরীক্ষাও ছিল এবং সমস্তটি কার্যকর করতে পুরো সপ্তাহটি সময় লাগবে।


1
আপনি আমার উদাহরণ তাকান? সারাদিন এমনই হয়েছিল। মুল বক্তব্যটি হ'ল আমি যখন নতুন বৈশিষ্ট্যটি প্রয়োগ করি তখন আমি ইউনিট পরীক্ষা পরিবর্তন / যুক্ত করি যাতে তারা নতুন বৈশিষ্ট্যটি পরীক্ষা করে - তাই কোনও ইউনিট পরীক্ষা ভঙ্গ হবে না। বেশিরভাগ ক্ষেত্রে আমার এমন পরিবর্তনগুলির পার্শ্ব প্রতিক্রিয়া রয়েছে যা ইউনিট পরীক্ষাগুলি দ্বারা সনাক্ত করা যায় নি - কারণ পরিবেশ উপহাস করা হয়েছে। আমার অভিজ্ঞতার কারণে এটির কোনও ইউনিট পরীক্ষা আমাকে কখনও বলেনি যে আমি একটি বিদ্যমান বৈশিষ্ট্যটি ভেঙে ফেলেছি। এটি সর্বদা ইন্টিগ্রেশন এবং গ্রহণযোগ্যতা পরীক্ষা ছিল যা আমাকে আমার ভুলগুলি দেখায়।
Yggdrasil

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

@Yggdrasil আমি যেমন বলেছি, ইউনিট পরীক্ষাগুলি সমস্ত শক্তিশালী নয়, তবে তারা সাধারণত টেস্টিংয়ের প্রথম স্তর হয়, যেহেতু তারা দ্রুততম হয়। অন্যান্য পরীক্ষাও দরকারী, এবং একত্রিত করা উচিত।
BЈовић

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

1
প্রশ্ন ছিল, ইউনিট পরীক্ষা থেকে আমার কী মূল্য থাকবে, যখন তারা ব্রেক না করে? এগুলি লেখার জন্য কেন আমাকে বিরক্ত করা হয়, যখন আমার সর্বদা নতুন প্রয়োজনগুলির সাথে সামঞ্জস্য করা প্রয়োজন? আমি তাদের থেকে একমাত্র মানটি দেখতে পাই উচ্চতর ছাড় দিয়ে অ্যালগরিদম এবং অন্যান্য শ্রেণীর জন্য। তবে এগুলি উপাদান এবং গ্রহণযোগ্যতা পরীক্ষার চেয়ে কম।
Yggdrasil
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.