আপনি কি কর্মক্ষেত্রে ইউনিট পরীক্ষা ব্যবহার করেন? এগুলি থেকে আপনি কী উপকার পাবেন? [বন্ধ]


18

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

আমি কৌতূহলী যে কীভাবে লোকেরা কর্মক্ষেত্রে ইউনিট টেস্টিং প্রয়োগ করেছে এবং সেগুলি ব্যবহার করে কী কী উপকার পাচ্ছে, যেমন, উন্নত কোডের মান, দীর্ঘমেয়াদে উন্নয়নের সময় হ্রাস করা ইত্যাদি etc.


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

2
এটি সম্ভবত ভুল, উপাখ্যান্তভাবে, আমি এখনও কোনও সংস্থার পক্ষে বা তার সাথে কাজ করতে পারি নি যা কমপক্ষে ইউনিট টেস্টিংয়ের কিছু স্তর করেনি
জেকে।

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

এই সাইটের বিকাশকারীরা কত ইউনিট টেস্টিং ব্যবহার করেন?
জেফো

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

উত্তর:


20

তাদের মধ্যে কিছু আমাকে পরামর্শ দেয় যে এটি প্রয়োজনীয় নয়

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

এবং এটির খুব সামান্য উপকার আছে।

এটি বেশিরভাগ ক্ষেত্রেই সত্য নয় । এটি হ'ল আমরা যদি এমন প্রযোজনীয় সফটওয়্যার নিয়ে কথা বলি যা ভবিষ্যতে বছরের জন্য ব্যবহার করা হবে - এইভাবে রক্ষণাবেক্ষণের জন্য।

তারা আরও দাবি করেন যে কেবল কয়েকটি সংস্থাই প্রোডাকশন সফটওয়্যার দিয়ে ইউনিট-টেস্ট করে।

এটি সত্য হতে পারে (আমার অভিজ্ঞতা কম বেশি হলেও কম) তবে ইউনিট পরীক্ষার মান সম্পর্কে এটি বলার কিছুই নেই । এই পুরানো রসিকতার বিপরীতে "ছিটে ভাল - 50 বিলিয়ন মাছি ভুল হতে পারে না!" ;-)

আপনি কি আপনার ইউনিট-পরীক্ষা প্রয়োগ করেছেন এবং আপনি এটি থেকে কী পান? (যেমন উন্নত কোডের মান, দীর্ঘমেয়াদে সময় হ্রাস করা ইত্যাদি)

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


14

আমি ইউনিটেটস করি, তবে কাজে (বা কয়েকটি) করি না

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

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

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

যখন আমার গোষ্ঠীটি একমত হয় (এবং 1 টির পক্ষে এটি সহজ) তখন পরীক্ষাগুলি প্রকল্পের মান, শৈলী এবং দৃ and়তার জন্য একটি বড় সুবিধা।

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

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


1
নেতিবাচক
শোনার

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

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

1
@ কেপ্পলা, যথেষ্ট ন্যায্য, যদি সতীর্থরা তাদের সাধারণ জ্ঞান হারানোর স্তরে পক্ষপাতদুষ্ট হন, তবে তাদের যৌক্তিক প্রমাণ দিয়ে বোঝানোর কোনও উপায় নেই :-( এইরকম ক্ষেত্রে, দৃ management় ব্যবস্থাপনার সহায়তায় আপনি এখনও এই ধারণাটি এগিয়ে নিতে সফল হতে পারেন , তবে তা ছাড়া কোনও আশা নেই
পিটার টারিক

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

7

আমি আপনার সহকর্মীদের সাথে ঝোঁক রাখি তবে কেবল একটি বিষয় পর্যন্ত।

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

def add(x, y)
  x + y
end

এক ডজন পরীক্ষার পাশাপাশি তা নিশ্চিত করার জন্য যে সংযোজনটি প্রকৃতপক্ষে পছন্দসইভাবে বেছে নেওয়া ব্যবহারের ক্ষেত্রে কার্যকর হবে। Duh ...

ইউনিট পরীক্ষার পিছনে সাধারণ ভিত্তি হ'ল: যদি আপনার কোডটিতে কোনও বাগ থাকে না, কারণ আপনি যথেষ্ট পরীক্ষা করেননি। এখন, কখন সঠিক ইউনিট পরীক্ষা লিখবেন। উত্তর:

  1. আপনি যখন পরীক্ষা করছেন
  2. আপনি যখন ডিবাগ করছেন
  3. আপনি সত্যই জটিল জিনিস বিকাশ হিসাবে

মনে করি আপনি প্রতিটি অ্যাপটি ওয়েব অ্যাপ্লিকেশন বিকাশ করছেন ing

আপনি নতুন কার্যকারিতাতে কিছু কোড লিখুন এবং এটি এখনই যুক্তিসঙ্গতভাবে কাজ করা উচিত। তারপরে আপনি আপনার ব্রাউজারের জন্য পৌঁছে যান এবং যাচাই করে নিন যে এটি আরও নিবিড়ভাবে পরীক্ষা করে কাজ করে, তাই না? Bzzzt! ... ভুল উত্তর। আপনি একটি ইউনিট পরীক্ষা লিখুন। আপনি যদি এখন এটি না করেন, আপনি সম্ভবত কখনও করবেন না। এবং এটি এমন এক স্থানে যেখানে ইউনিট পরীক্ষাগুলি খুব ভালভাবে কাজ করে: উচ্চ স্তরের কার্যকারিতা পরীক্ষা করে।

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

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

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

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


কেন্ট বেক যেমন রেখেছিলেন: "সমস্ত কিছু যা সম্ভবত ভঙ্গ হতে পারে তা পরীক্ষা করুন।"
প্যাটার টারিক

1
তার সাথে আন্তরিকভাবে সম্মত। আমার মূল আশা ওপ এটি নোট করবে: যেখানে প্রযোজ্য সেখানে পরীক্ষা করতে ভুলবেন না। :-)
ডেনিস ডি বার্নার্ডি

7

সমস্ত কোড পরীক্ষা করা আবশ্যক। সে সম্পর্কে কোনও উপায় নেই।

স্বীকৃত কোড অকেজো: এটি কোনও কিছুতেই বিশ্বাস করা যায় না।

আপনি ইউনিট পরীক্ষা লিখতে পারেন বা উচ্চ স্তরের ইন্টিগ্রেশন পরীক্ষা বা গ্রহণযোগ্যতা পরীক্ষা লিখতে আশা করতে পারেন।

ইউনিট পরীক্ষাগুলি লিখতে সহজ, ডিবাগ করা সহজ এবং পরিচালনা করা সহজ।

একীকরণ পরীক্ষা ইউনিটগুলি বাস্তবে কাজ করে এমন অনুমানের উপর ভিত্তি করে। ইউনিট পরীক্ষা না করে আপনি কীভাবে ইউনিটগুলি কাজ করবেন তা জানেন? আপনি স্বতন্ত্র ইউনিটগুলি বাস্তবে কাজ করে যাচ্ছেন তা না জানলে আপনি কীভাবে একটি ইন্টিগ্রেশন টেস্ট ডিবাগ করতে পারেন?

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

পরীক্ষা বাধ্যতামূলক। সমস্ত উচ্চ-স্তরের পরীক্ষা প্রকৃতপক্ষে কর্মরত ইউনিটগুলির উপর নির্ভর করে।

এটি ইউনিটকে একটি যৌক্তিক প্রয়োজনীয়তার পরীক্ষা করে তোলে। অন্য কোন উপায় নেই।


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

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

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

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

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

6

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

এটি বেশ সহজ: আপনি যদি প্রমাণ করতে না পারেন যে আপনার কোডটি কাজ করে (এবং একটি পরীক্ষার আকারে এক্সিকিউটেবল স্পেসিফিকেশনের চেয়ে ভাল উপায় কী?) তবে এটি কার্যকর হয় না

এটি আমাকে দেয়:

  • মনের প্রশান্তি: আমার সিআই সার্ভার আমাকে আমার পুরো কোডবেসটি কাজ করে বলে।
  • আমার কোড উন্নত করার দক্ষতা: আমি আমার কোডটি পুনর্গঠন করতে পারি - এটি রিফ্যাক্টর - জেনে যে পুনর্গঠনের পরে আমি কিছুই ভাঙ্গি নি।

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

আপনার পরিবেশটি যদি না যায় তবে "যদি আপনি প্রমাণ করতে না পারেন যে আপনার কোডটি কাজ করে না তবে এটি কাজ করে।" : পি
ডেভি 8

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

@ ডেভি 8: কোন ক্ষেত্রে আপনার আরও গুরুতর সমস্যা রয়েছে যা "ইউনিট টেস্টগুলি কাজ করে?"
ফ্রাঙ্ক শায়ারার

4

ইউনিট টেস্টিং একটি শৃঙ্খলা। কোড কাজ করার জন্য এটি প্রয়োজনীয় নয় বলে এটি প্রায়শই ফেলে দেওয়া হয়।

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

আমি আপনার সহকর্মীদের সন্দেহ করি যে এটি ব্যবহারের বিরুদ্ধে প্রস্তাব দেয় যা প্রোগ্রামার নয়। যদি তা হয় তবে ভালভাবে বলা যাক যে মার্টিন ফোলার বা কেন্ট বেকের মতো লোকের চেয়ে আমি বেশি লোককে বেশি মূল্যবান মনে করি না ;)।

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

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


3

ইউনিট-পরীক্ষার জন্য ইউনিট-পরীক্ষামূলক বন্ধুত্বপূর্ণ ভাষা, ইউনিট-পরীক্ষা বন্ধুত্বপূর্ণ নকশা এবং ইউনিট-পরীক্ষামূলক বন্ধুত্বপূর্ণ সমস্যা প্রয়োজন।

সি ++, মাল্টিথ্রেডেড ডিজাইন এবং জিইউআই একটি দুঃস্বপ্ন হবে এবং সমস্যার কভারেজটি ভয়াবহ হবে।

.NET, পুনরায় ব্যবহারযোগ্য একক থ্রেডযুক্ত dll সমাবেশ, খাঁটি গণনা যুক্তি একটি হাওয়া হবে।

এটা কি মূল্য, আমি সত্যিই বলতে পারি না।

আপনি কি অনেক চুল্লী? আপনি কি আপনার কোডটিতে "বুদ্ধিমান বাগগুলি" "অফ বাই এক" পছন্দ করেন?

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


1
মাল্টিথ্রেডেড ডিজাইন কেন দুঃস্বপ্ন হতে পারে? সিঙ্ক্রোনাইজেশন পয়েন্টগুলির জন্য ডিজাইন করুন এবং সেখানে পরীক্ষা করুন।
ফ্রাঙ্ক শেয়ারার

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

1
আমি পরীক্ষিত চালিত মাল্টিথ্রেডেড স্টাফ লিখেছি। এটি অবশ্যই স্পষ্টভাবে করণীয়।
ফ্র্যাঙ্ক শিয়েরার

4
আবর্জনা, আপনি যে কোনও ভাষায় পরীক্ষা করতে পারেন।
জে কে।

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

3

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

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


2

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

কোড পর্যালোচনায় মিস করা জিনিসগুলি খুঁজে পাওয়ার এটি দুর্দান্ত উপায়।

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

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


2

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

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

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


2

ব্যয়: ধীরে ধীরে কোড, লার্নিং কার্ভ, বিকাশকারী জড়তা

উপকারিতা: সাধারণত যখন আমি প্রথম পরীক্ষা করেছিলাম তখন নিজেকে আরও ভাল কোড লিখতে দেখেছি - SOLID મુજબ ...

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


0

সুযোগ পেলেই আমি কিছু ইউনিট পরীক্ষা করি এবং আমি আমার সহকর্মীদেরও এটি করার জন্য রাজি করার চেষ্টা করি।

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


0

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

ইউনিট পরীক্ষার জন্য আমার গাইডলাইনগুলি হ'ল:

  1. আপনার কোডের জন্য খারাপ ইনপুট, সীমানা ইত্যাদি সহ যে শর্ত আপনি ভাবতে পারেন তার পরীক্ষা করুন
  2. সমস্ত মডিউলগুলির জন্য সমস্ত ইউনিট টেস্টগুলি নিয়মিতভাবে কার্যকর করা উচিত (অর্থাত রাতের তৈরি অংশগুলির অংশ হিসাবে)
  3. ইউনিট পরীক্ষার ফলাফল পরীক্ষা করে দেখুন!
  4. যদি কেউ আপনার কোডটিতে একটি বাগ খুঁজে পায় যা আপনার পরীক্ষাগুলি পেরিয়ে যায়, তবে এটির জন্য একটি নতুন পরীক্ষা লিখুন!

0

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

সবচেয়ে শক্ত অংশটি ভাল ইউনিট পরীক্ষা লিখছে ।

এটি আপনার কোডের জন্য একটি ভাল মাপদণ্ড।

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