ইউনিট টেস্টিং কোনও বিদ্যমান উত্পাদন প্রকল্পে সফলভাবে যুক্ত করা যাবে? যদি তা হয় তবে কীভাবে এবং এর মূল্য?


140

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

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

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

সুতরাং আমি অনুমান করি আমি যা জিজ্ঞাসা করছি তা হ'ল;

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

(স্পষ্টতই তৃতীয় পয়েন্টের উত্তর সম্পূর্ণভাবে নির্ভর করে আপনি পরিচালনা বা বিকাশকারীর সাথে কথা বলছেন)


অনুগ্রহের কারণ

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

আমি এই প্রশ্নটি পরে চেষ্টা করার জন্য পেশাদারদের সাথে এই পরামর্শটি লেখার চেষ্টা করছি এবং ভবিষ্যতের বিকাশকে টিডিডি-তে স্থানান্তরিত করার জন্য ম্যান ঘন্টা ব্যয় করা উপযুক্ত। আমি এই চ্যালেঞ্জের কাছে যেতে চাই এবং নিজের পক্ষপাতদুষ্ট দৃষ্টিভঙ্গি ছাড়াই আমার যুক্তি বিকাশ করতে চাই।


11
বিষয়ে মাইকেল পালক 'বই বাধ্যতামূলক লিঙ্ক: amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/...
মার্ক Rushakoff

1
@ মার্ক - ধন্যবাদ, এটি আমার দেওয়া লিঙ্কটিতে রয়েছে। আমি অন্য একটি বই না কিনে একটি সুনামের উত্তর পাওয়ার প্রত্যাশা করছিলাম ... যদিও আপনার কাছে কখনও খুব বেশি বই থাকতে পারে না (যদি না আপনি কাজটি করতে চান তবে)।
djdd87

1
আপনার এই বইটি সত্যিই পড়তে হবে :) এটি আমার পছন্দের একটি এবং রিফ্যাক্টরিং এবং স্বয়ংক্রিয়-পরীক্ষার মধ্যবর্তী উত্তেজনা বুঝতে সহায়তা করে।
ম্যানুয়েল আলডানা

উত্তর:


177

আমি কোড বেসগুলিতে ইউনিট টেস্টগুলি চালু করেছি যার আগে এটি ছিল না। সর্বশেষ বড় প্রকল্পের সাথে আমি জড়িত ছিলাম যেখানে আমি এই পণ্যটি তৈরি করেছি যখন আমি দলে পৌঁছেছিলাম তখন শূন্য ইউনিট পরীক্ষা দিয়ে উত্পাদিত হয়েছিল। যখন আমি চলে গেলাম - 2 বছর পরে - আমাদের কাছে 4500+ বা তার বেশি পরীক্ষা হয়েছে 230 000 + প্রোডাকশন এলওসি (রিয়েল টাইম ফিনান্সিয়াল উইন-ফর্ম অ্যাপ্লিকেশন) সহ একটি কোড বেজে প্রায় 33% কোড কভারেজ ing এটি কম শোনাতে পারে তবে ফলাফলটি ছিল কোয়ালিটির মান এবং ত্রুটি হারের একটি উল্লেখযোগ্য উন্নতি - মনোবল এবং লাভজনকতা উন্নত।

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

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

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

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

এখন, আপনার মন্তব্য এবং প্রশ্নের জন্য:

যাইহোক, আমি উদ্বিগ্ন যে আমি বড় ছবিটি হারিয়ে যাব এবং মুল টেস্টগুলি হারিয়ে যাব যদি আমি যেতে যেতে টিডিডি ব্যবহার করতাম তবে তা অন্তর্ভুক্ত হত।

সংক্ষিপ্ত উত্তর: হ্যাঁ, আপনি পরীক্ষাগুলি মিস করবেন এবং হ্যাঁ তারা প্রথমদিকে সবুজ ক্ষেত্রের পরিস্থিতি মতো দেখতে পছন্দ করবে না।

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

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

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

সুসংবাদটি হ'ল যে মাসগুলি (এবং এমনকি বছরগুলি) কেটে যাওয়ার সাথে সাথে আপনার কোডটি ধীরে ধীরে "যথাযথ" ভাল ফ্যাক্টরড এবং ভাল পরীক্ষিত কোড হতে শুরু করবে।

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

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

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

আপনার লোকদের প্রশিক্ষণ দিন।

গ্রাহকের দৃষ্টিকোণ থেকে অগ্রগতি করার সময় কোথাও শুরু করুন এবং পরীক্ষাগুলি যুক্ত করা শুরু করুন (নীচে দেখুন)।

আপনার প্রডাকশন কোড বেসটির কত অংশ পরীক্ষার অধীনে রয়েছে তার গাইড রেফারেন্স হিসাবে কোড কভারেজ ব্যবহার করুন।

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

পরিদর্শন এবং অভিযোজিত।

আমি কীভাবে নিশ্চিত করতে পারি যে পরীক্ষাগুলি একটি ভাল মানের এবং কোনও পরীক্ষার ক্ষেত্রে কেবল কোনও পরীক্ষার চেয়ে ভাল নয়।

আপনার নিজের রায় অবশ্যই আপনার বাস্তবতার উত্স হতে পারে। দক্ষতার প্রতিস্থাপন করতে পারে এমন কোনও মেট্রিক নেই।

আপনার যদি সেই অভিজ্ঞতা বা রায় না থেকে থাকে তবে কারও সাথে চুক্তি করার বিষয়টি বিবেচনা করুন।

দুটি মোটামুটি মাধ্যমিক সূচকগুলি হ'ল মোট কোড কভারেজ এবং গতির গতি।

উত্পাদিত কোন বিদ্যমান সমাধানের জন্য এটি কি মূল্যবান?

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

এই প্রকল্পের পরীক্ষাটি উপেক্ষা করে ভবিষ্যতের কোনও পুনরায় লেখায় এটি যুক্ত করা ভাল কি?

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

আমার ব্যক্তিগত উত্তরটি বেশিরভাগ ক্ষেত্রে "হ্যাঁ অবশ্যই" হবে কারণ আমি এর আরও অনেক ভাল জানি তবে আমি বুঝতে পারি যে এর ব্যতিক্রমও হতে পারে।

এর চেয়ে বেশি উপকারী কী হবে; কয়েক সপ্তাহ পরীক্ষার যোগে ব্যয় করা বা কয়েক সপ্তাহ কার্যকারিতা যুক্ত করে?

আমরাও। আপনার কার্যকারিতার দিক থেকে আপনি যখন অগ্রগতি করছেন তখন আপনার কোডটি আপনার কোড বেসে পরীক্ষা যুক্ত করা উচিত।

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

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

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

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

আশা করি এইটি কাজ করবে


আমার মতো একই মানসিকতা প্রতিফলিত করে। বর্তমানে আমি বড় জাভা আবেদনে পরীক্ষার কেসগুলি প্রবর্তন করার জন্য এই সঠিক প্রক্রিয়া / পদ্ধতিটি প্রদর্শন করার প্রক্রিয়াধীন। :)
দর্শন যোশি

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

ধন্যবাদ ইয়ারমো আমার কাছে কোনও বই লেখার সময় আছে কিনা তা নিশ্চিত নই। তবে সম্ভবত আমি দু'একটি ব্লগ লিখতে পারি। আমার নতুন ব্লগটি কেবল শুরু করা, তাই এটি কিছুটা সময় হতে পারে।
মাহোল 25

2
এই ডিউডস ইউনিট পরীক্ষার পরামর্শ হ'ল সাধারণ জীবনের পরামর্শ। সিরিয়াসলি।
Wjdavis5

24
  • উত্পাদিত কোন বিদ্যমান সমাধানের জন্য এটি কি মূল্যবান?

হ্যাঁ!

  • এই প্রকল্পের পরীক্ষাটি উপেক্ষা করে ভবিষ্যতের কোনও পুনরায় লেখায় এটি যুক্ত করা ভাল কি?

না!

  • এর চেয়ে বেশি উপকারী কী হবে; কয়েক সপ্তাহ পরীক্ষার যোগে ব্যয় করা বা কয়েক সপ্তাহ কার্যকারিতা যুক্ত করে?

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

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

তারপরে আপনার বাগ ডেটাবেজে প্রতিটি বর্তমান বাগের জন্য একটি পরীক্ষা করুন যা ঠিক ত্রুটিটি প্ররোচিত করে এবং বাগটি ঠিক করার পরে যা পাস হবে। তারপরে bu বাগগুলি ঠিক করুন! :-)

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


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

15

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

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


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

13

আমি প্রত্যেকে যা বলেছি তাতে আমি একমত নই। বিদ্যমান কোডে পরীক্ষা যুক্ত করা মূল্যবান। আমি কখনই এই দফায় দ্বিমত করব না, তবে আমি একটি সাবধানবাণী যুক্ত করতে চাই।

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

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

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

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

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

সম্পাদনা:

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

এটি "সোর্স নিয়ন্ত্রণ ব্যবহারের পক্ষে কী কী উপকারিতা হবে?" জিজ্ঞাসার মতো? বা "লোককে নিয়োগ দেওয়ার আগে তাদের সাক্ষাত্কার নেওয়ার পক্ষে কি মতামত রয়েছে?" বা "শ্বাস নেওয়ার উপকারিতা এবং কি কি?"

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


9

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

আমরা প্রথম কাজগুলির মধ্যে একটি (অবিচ্ছিন্ন বিল্ড সার্ভার স্থাপন করার পরে) হ'ল রিগ্রেশন টেস্ট যুক্ত করা। এগুলি শেষ থেকে শেষের পরীক্ষা ছিল।

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

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

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

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

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


8

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

আপনি যদি টেস্টগুলি লেখেন যা আপনি সংযোজন বা সংশোধন করছেন কার্যকারিতাটি কভার করে, আপনি তাৎক্ষণিক সুবিধা পাবেন। আপনি যদি পুনর্লিখনের জন্য অপেক্ষা করেন, আপনি কখনও স্বয়ংক্রিয় পরীক্ষা করতে পারবেন না।

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


6

আমি আমার ভয়েস যুক্ত করব এবং হ্যাঁ বলব, এটি সর্বদা দরকারী!

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

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

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

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

অন্যদের মতো, আমিও আপনাকে টিডিডি সম্পর্কে দুটি গুরুত্বপূর্ণ বিষয় মনে করিয়ে দেব:

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

4

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

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

আপনার তৃতীয় প্রশ্নের আমার উত্তরটি প্রথমটির মতোই: এটি আপনার প্রকল্পের প্রসঙ্গে নির্ভর করে।

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


4

আপনি বাস্তবায়নের ভাষাটি উল্লেখ করেন না, তবে জাভাতে থাকলে আপনি এই পদ্ধতির চেষ্টা করতে পারেন:

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

    • পণ্যের পরামর্শ - আমি ফ্রি ওয়েব ভিত্তিক পণ্য জুনিট ফ্যাক্টরি ব্যবহার করতাম, তবে দুঃখের বিষয় এটি এখন বন্ধ। তবে পণ্যটি http://www.agitar.com / সমাধান / প্রোডাক্টস / আউটোমেটেড_জুনিট_জেনারেশন html এ বাণিজ্যিকভাবে লাইসেন্সিত অজিটারোনে জুনিট জেনারেটরে বাস করে
  2. আপনি যে কোনও বাগটি ঠিক করেছেন, বা এখন থেকে যে বৈশিষ্ট্যটি যুক্ত করেছেন তার জন্য, নতুন কোডটি পরীক্ষারযোগ্য করার জন্য নকশাকৃত হয়েছে এবং এই পরীক্ষাগুলি একটি সাধারণ পরীক্ষার উত্স ট্রিতে রাখার জন্য একটি টিডিডি পদ্ধতির ব্যবহার করুন।

  3. নতুন বৈশিষ্ট্য যুক্ত করার অংশ হিসাবে এটি পরীক্ষাযোগ্য করে তোলার জন্য বিদ্যমান কোডটিও সম্ভবত পরিবর্তন করা বা পুনরুদ্ধার করা দরকার; আপনার ধূমপান পরীক্ষা আপনাকে নিয়ন্ত্রণে বা আচরণে অযৌক্তিক সূক্ষ্ম পরিবর্তনের বিরুদ্ধে সুরক্ষা জাল দেবে।

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

  5. বাগগুলি স্থির করার সময় একটি ব্যর্থ ইউনিট পরীক্ষা লিখুন যা প্রথমে বাগটি প্রকাশ করে।


3

আমি এই উত্তরটি দিয়ে এই উত্তরটি শুরু করতে চাই যে ইউনিট টেস্টিংটি সত্যই গুরুত্বপূর্ণ কারণ এটি আপনাকে বাগের প্রযোজনার আগেই গ্রেপ্তার করতে সহায়তা করবে।

যে সমস্ত অঞ্চল / বাগগুলি পুনরায় চালু করা হয়েছে সেগুলি চিহ্নিত করুন mod পরীক্ষা লিখতে সেই প্রকল্পগুলির সাথে শুরু করুন start নতুন কার্যকারিতা এবং বাগ ফিক্সের জন্য পরীক্ষা লিখতে এটি পুরোপুরি জ্ঞান করে।

উত্পাদিত কোন বিদ্যমান সমাধানের জন্য এটি কি মূল্যবান?

হ্যাঁ. আপনি বাগগুলির প্রভাব নীচে নেমে আসা এবং রক্ষণাবেক্ষণ আরও সহজ হয়ে যাওয়া দেখতে পাবেন

এই প্রকল্পের পরীক্ষাটি উপেক্ষা করে ভবিষ্যতের কোনও পুনরায় লেখায় এটি যুক্ত করা ভাল কি?

আমি এখন থেকে শুরু করার জন্য সুপারিশ করব।

এর চেয়ে বেশি উপকারী কী হবে; কয়েক সপ্তাহ পরীক্ষার যোগে ব্যয় করা বা কয়েক সপ্তাহ কার্যকারিতা যুক্ত করে?

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


3

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

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


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

2

হ্যাঁ এটি করতে পারে: আপনি এখন থেকে যে সমস্ত কোড লিখেছেন তার একটি পরীক্ষা আছে কিনা তা নিশ্চিত করার চেষ্টা করুন।

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


2

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

এই প্রকল্পের পরীক্ষাটি উপেক্ষা করে ভবিষ্যতের কোনও পুনরায় লেখায় এটি যুক্ত করা ভাল কি?
না First

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


2

হালনাগাদ

আসল উত্তরের 6 বছর পরে আমার কিছুটা আলাদা নেওয়া দরকার।

আমার মনে হয় আপনি যে সমস্ত নতুন কোড লিখেছেন সেটিতে ইউনিট পরীক্ষা যুক্ত করার অর্থ হয়েছে - এবং তারপরে রিফেক্টর জায়গাগুলি যেখানে আপনি সেগুলি পরীক্ষাযোগ্য করে তোলার জন্য পরিবর্তনগুলি করেন make

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

আগের উত্তর

আমি এখানে কয়েকটি ভ্রু বাড়াতে যাচ্ছি :)

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

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

কেন?

  1. ইউনিট পরীক্ষাগুলি কেবল কোড পরীক্ষাগুলি coverেকে রাখে - কোডটি সেটির জন্য নকশাকৃত নকশাগুলি করে কিনা তা - এটি যেভাবেই করতে হবে ম্যানুয়াল টেস্টিংয়ের প্রতিস্থাপন নয় (কার্যকরী বাগগুলি, ব্যবহারযোগ্যতার সমস্যাগুলি এবং অন্যান্য সমস্ত ধরণের সমস্যা উদ্ঘাটিত করার জন্য)

  2. ইউনিট পরীক্ষায় সময় ব্যয়! এখন আমি যেখান থেকে এসেছি, এটি একটি মূল্যবান পণ্য - এবং ব্যবসায় সাধারণত একটি সম্পূর্ণ পরীক্ষার স্যুটের চেয়ে আরও ভাল কার্যকারিতা অর্জন করে।

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

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

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

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


এবং আমি আপনাকে এটি পড়তে অনুরোধ করি - joelonsoftware.com/items/2009/01/31.html
রূপেশ শেনয়

আপনি কি 'মুলতুবি থাকা বাগগুলি ঠিক করতে' পছন্দ করবেন বা তাদের উত্থিত হওয়া থেকে বিরত রাখবেন? সঠিক ইউনিট টেস্টিং বাগ-ফিক্সিংয়ে ব্যয় করা সময়ের পরিমাণ হ্রাস করে সময় সাশ্রয় করে।
ইহোর কাহারলিচেনকো

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

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

1

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

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

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

শুভকামনা!



1

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

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

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

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


1

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

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

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

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

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


1

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


1

আমি টপটাল ইঞ্জিনিয়ারের একটি উজ্জ্বল নিবন্ধটি পড়ার পরামর্শ দিচ্ছি , যেখানে টেস্ট যুক্ত করা শুরু করতে হবে তা ব্যাখ্যা করে: এতে প্রচুর গণিত রয়েছে, তবে প্রাথমিক ধারণাটি হ'ল:

1) আপনার কোডের অ্যাফেরেন্ট কাপলিং (সিএ ) পরিমাপ করুন ( অন্যান্য শ্রেণি দ্বারা কোনও শ্রেণি কতটা ব্যবহৃত হয়, যার অর্থ এটি ভেঙে দেওয়ার ফলে ব্যাপক ক্ষতি হতে পারে)

2) আপনার কোডের সাইক্লোমেটিক জটিলতা (সিসি ) পরিমাপ করুন (উচ্চতর জটিলতা = ভাঙার উচ্চতর পরিবর্তন)

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

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


0

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


-2

হ্যাঁ. না। পরীক্ষা যোগ করা হচ্ছে।

আরও বেশি টিডিডি পদ্ধতির দিকে যাওয়ার সাথে সাথে নতুন কার্যকারিতা যুক্ত করার এবং রিগ্রেশন টেস্টিংকে আরও সহজ করার জন্য আপনার প্রচেষ্টাটি আরও ভালভাবে জানানো হবে। এটা দেখ!

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