ইউনিট টেস্টিং যদি দুর্দান্ত হয় তবে আরও সংস্থাগুলি কেন এটি করছে না? [বন্ধ]


103

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

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

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

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


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

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

11
চেয়ার টেস্টিং: ব্যক্তি চেয়ারে বসে অ্যাপ্লিকেশন চালায়, বাগগুলি রিপোর্ট করে।
jcollum

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

1
@ পোর্টফোলিওবিল্ডার হ্যাঁ, আপনার আইডিই-র মধ্যে মানগুলি বাড়িয়ে দেওয়া কোডের মান উন্নত করতে সত্যই সহায়তা করবে। কারণ রাষ্ট্র সর্বদা একই থাকবে এবং কোডটি কখনই পরিবর্তিত হবে না। ঠিক! এবং সৌভাগ্য.
ফ্রানজ ডি

উত্তর:


112

আমার অভিজ্ঞতায় এর সাথে জড়িত কয়েকটি কারণ রয়েছে:

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

স্বাভাবিকভাবেই, অন্যান্য কারণও রয়েছে তবে আমি এখন পর্যন্ত যা চালিয়েছি তা সেগুলি।


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

এবং কয়েকটি জনপ্রিয় ল্যাংগুলিতে এর জন্য সমর্থন (সি / সি ++) খুব কম।
মার্টিন বেকেট

@ এমজিবি - সিএক্সএক্সউনিট আমার জন্য বেশ ভালভাবে কাজ করে ...
ডমিনিক রজার

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

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

87

1) এটি শক্ত
2) এটি সময় নেয়
3) পরীক্ষার কোডের মান নির্ধারণ করা খুব কঠিন

পয়েন্ট 3 একটি স্টিকি এক। ভাল ইউনিট পরীক্ষা বাগ কমাতে। তবে তাই ভাল উত্পাদন কোড। আপনার ইউনিট পরীক্ষার কারণে আপনি কতগুলি বাগের অস্তিত্ব নেই তা কীভাবে নির্ধারণ করবেন? যা বিদ্যমান নেই তা আপনি পরিমাপ করতে পারবেন না। আপনি পড়াশোনার দিকে নির্দেশ করতে পারেন তবে সেগুলি আপনার ব্যবসায়ের পরিচালকের স্প্রেডশিটে ভালভাবে ফিট করে না।


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

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

দুর্দান্ত উত্তর! আপনি আমার উত্তর হিসাবে একই জিনিস খুব কম কথায় বলেছিলেন।
ওয়েজ

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

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

70

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

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

আমি মনে করি আপনার প্রশ্নের আসল উত্তর হ'ল: ইউনিট পরীক্ষা করা সত্যিই কঠিন, এবং কম্পিউটার-বিজ্ঞানের শিক্ষার্থীরা এর জন্য প্রশিক্ষণপ্রাপ্ত নয়।

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

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

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

পরের বার যখন আপনার বস আপনাকে সময়ের অনুমান করতে বলেন, ইউনিট পরীক্ষা লেখার সময় অন্তর্ভুক্ত করুন এবং দেখুন কী ঘটে।


2
ভাল ধারণা. তবে "পণ্য" কোড তৈরির সময় থেকে পৃথক হিসাবে ইউনিট টেস্টগুলি তৈরি করার সময়কে ডাকবেন না!
জেফ কোটুলা

3
এই উত্তরটি পড়ার ফলে আমি বুঝতে পেরেছিলাম যে আমি যখন ইউনিট পরীক্ষার ধারণা এবং বুনিয়াদি সম্পর্কে পরিচিত তখনও কার্যকরভাবে কীভাবে এটি করা যায় তা আমি জানি না। আপনি কি বিষয়টির উপর একটি ভাল বই অর্জন করতে পারেন?
ব্রেটন

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

1
বোচস বা কিউইএমইউ দিয়ে আপনার কার্নেল ড্রাইভারের সাথে কথা বলার জন্য আপনার ডিভাইসের সিমুলেশন লেখা সম্ভব।
জ্যান লিংস

2
@ ফ্লোডিং, আকর্ষণীয় উত্তর। আমি মনে করি আমাকে ইউনিট পরীক্ষার উপর একটি বই পড়তে হবে।
ড্যান রোজনস্টার্ক 10:51

28

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

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

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


15
আমি মনে করি এই উত্তরটি চিহ্নটি কিছুটা মিস করেছে। ইউনিট টেস্টিং এবং কার্যকরী পরীক্ষা একই জিনিস নয় এবং হওয়া উচিত নয়।
ওয়েজ

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

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

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

1
টিডিডি "প্রোগ্রামার যে কোডটি লিখেছিল সেগুলিও পরীক্ষাগুলি লেখায়" এর অনমনীয় পরীক্ষার সমস্যাটি পরিচালনা করে আপনি কোড লেখার আগে আপনাকে পরীক্ষাগুলি লেখার মাধ্যমে করে।
ওপিডিয়ান


15

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


12

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

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

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

মনে রাখবেন যে ইউনিট পরীক্ষায় প্রচুর প্রচেষ্টা করা গুণগত সফ্টওয়্যারটির কোনও গ্যারান্টি নয়। এবং, এছাড়াও, কোনও ইউনিট যা পরীক্ষা না করে সর্বোচ্চ মানের সফ্টওয়্যার তৈরি করা সম্ভব।


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

11

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

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

সংক্ষেপে, আমরা টিডিডিতে বিশ্বাস করি না, তবে আমরা ইউনিট পরীক্ষা করতে চাই। আমাদের কেবল এটি করার অভিজ্ঞতা নেই এবং আমরা এটি সহজে খুঁজে পাই না।


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

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

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

3
এটি কীভাবে হতে পারে যে আপনি ইউনিট পরীক্ষার জন্য "কীভাবে নিশ্চিত নন" তবে বিশ্বাস করেন যে টিডিডি সৃজনশীলতা এবং নমনীয়তাটিকে স্তব্ধ করে?
jcorcoran

1
@ স্টিভ 6 বছর পরে, আপনি কখনও ইউনিট পরীক্ষার (বা এমনকি টিডিডি) প্রবর্তন করেছেন কিনা এবং আপনি এটি চালিয়ে যাচ্ছেন কিনা তা জেনে ভাল লাগবে।
লুক পুপলেট

11

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

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

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


আমি সাধারণত এমন একটি অবস্থানে থাকি যেখানে নীতিগত সিদ্ধান্তের উপর আমার শূন্য প্রভাব থাকে; আমি জুনিয়র সিনেটরকে কমিটির সভাপতিত্ব থেকে বঞ্চিত করা হচ্ছে।
jcollum

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

হ্যাঁ! সত্যের জন্য এটি শুনতে দিন। আমাদের বিকাশকারীরা সর্বোত্তম অনুশীলন সম্পর্কে ঝাঁকুনি ব্যয় করার পরেও, এটি সত্যিকারের বিশ্বে সর্বদা ব্যবহৃত হয় না। সত্যিই করুণা।
নিডহ্যাক 13

6

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


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

6

সংকলক যেমন হয় তেমন ইউনিট টেস্টিং কোড বিকাশের কর্মপ্রবাহের একটি প্রাকৃতিক অংশ হওয়া উচিত।

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

আমার বিশ্বাস "এটি কী অনুপস্থিত এবং আরও সংস্থাগুলি কেন ইউনিট টেস্টিং করছে না" আপনার প্রশ্নের উত্তর এটি । :-)


1
"কোড বিকাশের কর্মপ্রবাহের একটি প্রাকৃতিক অংশ হওয়া উচিত" এর জন্য +1। প্রতিটি পেশাদার বিকাশকারীকে অফিসিয়াল প্রক্রিয়া নির্বিশেষে সেখানে নিজস্ব ইউনিট টেস্টিং করা উচিত । এই ইস্যুতে একমাত্র বৈধ যুক্তি হ'ল একটি ইউনিটের সংজ্ঞা ।
ডাঙ্ক

1
@ ডাঙ্ক আপনি যদি "ইউনিট" সংজ্ঞায়িত না করেন তবে আপনি কেবল বলছেন যে "পেশাদার বিকাশকারীদের তাদের নিজস্ব পরীক্ষা করা উচিত"।
ক্রিসডাব্লু

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

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

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

5

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


পৃথিবীতে কীভাবে আপনি অনুমান করতে পারেন যে কোনও বাগটি ডিবাগ করতে এবং ঠিক করতে কতক্ষণ সময় নেয়। সাধারণত আমার অভিজ্ঞতার তুলনায় ডিবাগিং এলোমেলো হয় - সমস্যাটি আমার যেখানে হয় না তা আমার ধারণা হয় don't
ডমিনিক রজার

1
হ্যাঁ, এজন্যই আমি পরীক্ষার সুবিধাগুলির পরিমাণ নির্ধারণ করা এত কঠিন বলেছি।
ওভি টিসলার

5

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

তার উপরে, আপনার দল তৈরি করা (বা কেউ) দরকার পরিকাঠামো স্থাপন এবং এটি বজায় রাখা।

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


5

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


5

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

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

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


4

ইউনিট টেস্টিং সেই ব্ল্যাক বক্সের একটি শর্ত যা বেশিরভাগ লোকেরা শুনেছিল, তবে জানে না যে ইউনিট পরীক্ষাটি ঠিক কী গঠন করে, কোথা থেকে শুরু করতে হয়, কীভাবে লিখতে হয়, কীভাবে প্রকৃতপক্ষে পরীক্ষা চালানো যায়, ঠিক কী কী পরীক্ষা করা উচিত ইত্যাদি ইত্যাদি don't ইত্যাদি ইত্যাদি

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


4

আমি ইউনিট পরীক্ষার একটি বিশাল অনুরাগী এবং বিভিন্ন ক্লায়েন্টের জন্য চুক্তি বিকাশ প্রকল্পগুলি করা একটি সংস্থার আমিও অংশীদার। এক মাসে আমরা বিভিন্ন আকারের বিভিন্ন 3-4 টি প্রকল্প স্পর্শ করব।

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

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

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


3

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


আমি রাজী. আপনি যদি মডেল / ভিউ / কন্ট্রোলার ব্যবহার করেন তবে এটি মডেল এবং নিয়ামককে ইউনিট পরীক্ষা করতে অনেক বোঝায়। ইউআই প্রায় সবসময়ই একজন মানুষ পরীক্ষা করে থাকে।
জ্যান লিংস

3

আমি ইউনিট পরীক্ষা মিস করি - এটি কেবল জীবনকে সহজ করে তোলে।

যে না , সত্যিই, একটি কোম্পানির জন্য একটি যথেষ্ট কারণ ইউনিট টেস্টিং দত্তক গ্রহণ করা।

একটি যথেষ্ট কারণ "সস্তা" (এবং / অথবা "আরও ভাল") হতে পারে: যা ইউনিট পরীক্ষার বিষয়ে প্রমাণ করা তত সহজ নয়।

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

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


3

অবশ্যই, আদর্শ বিশ্বে আপনি ইউনিট পরীক্ষা দেওয়ার বিরুদ্ধে তর্ক করতে পারবেন না।

তবে, আপনি ইউনিট পরীক্ষা লেখেন কিনা তা বিভিন্ন বিষয়ের উপর নির্ভর করে:

  • সফটওয়্যারটি কীভাবে ব্যবহার করা হবে। আপনি যদি কেবল নিজের জন্য সফ্টওয়্যার লেখেন তবে আপনি ইউনিট পরীক্ষা লিখবেন? সম্ভবত না. আপনি যদি বাণিজ্যিকভাবে বিক্রি করার জন্য প্রাক-প্যাকেজযুক্ত সফ্টওয়্যারটি লিখতেন তবে সম্ভবত হ্যাঁ।

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

  • কোড জটিলতা: কেবলমাত্র পরীক্ষার কোড যা একটি পরীক্ষার প্রয়োজন। একটি ওয়ান লাইন ভেরিয়েবল অ্যাসাইনমেন্ট পদ্ধতিতে টেস্টিংয়ের দরকার নেই। কার্যকর করার একাধিক পাথ সহ একটি 50 লাইন পদ্ধতি সম্ভবত এটি করে।

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

এবং অন্যরা যেমন বলেছে যে, পরীক্ষাটি সেই ব্যক্তির মতোই ভাল যা এটি লিখেছিল।


3

মূল কারণটি হ'ল অনেক বিকাশকারী এবং বিকাশ পরিচালকগণের ইউনিট পরীক্ষার উপস্থিতি বা কীভাবে সেগুলি ব্যবহার করবেন সে সম্পর্কে কোনও ক্লু নেই।

দ্বিতীয় কারণ হ'ল ইউনিট পরীক্ষাগুলি কেবলমাত্র কোড সহ ব্যবহার করা যেতে পারে (যা ইতিমধ্যে কিছু মানের মান পূরণ করে। সম্ভাবনাগুলি হ'ল, কিছু বিদ্যমান কোডবেস সেই বিভাগের মধ্যে পড়ে না।

তৃতীয় কারণ অলসতা এবং / বা সস্তাতা।


3

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

সম্পাদনা: "অলস এবং" বা সস্তা "হিসাবে অলস" অলস "; কিছু বিরল সময়ে, লোকেরা প্রকৃতপক্ষে পরীক্ষা লেখার দক্ষতা এবং ক্ষমতা এবং ইচ্ছা থাকে তবে তাদের আরও কিছু করার আছে যা আরও সরাসরি তলরেখাকে প্রভাবিত করে।


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

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

2

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

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

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


আপনার অবশ্য জড়িত ব্যবস্থাপনা দরকার কারণ আপনার সহ-বিকাশকারীদের আপনাকে বোর্ডে আনতে হবে এবং এটির জন্য সর্বোত্তম উপায় হ'ল এটি নিচ থেকে নীচে থেকে প্রয়োজন।
জন

2

লোকেরা অলস হয় এবং যখন বাধ্য হয় কেবল তখনই পরিবর্তনটি গ্রহণ করে।


2

আমার 2 সেন্ট:

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

সুতরাং, এটি সময়ের বিষয় মাত্র।

মার্টিন-কোপলিন বিতর্ক আছে যেখানে বব মার্টিন দৃser়ভাবে দাবি করেছেন:

"আজকাল কোনও বিকাশকারীর পক্ষে কোনও ইউনিট পরীক্ষায় তিনি কার্যকর করেননি এমন একটি লাইন কোডের শিপিং করা দায়বদ্ধ।"

[ http://www.infoq.com/interviews/coplien-martin-tdd]


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

2

আপনি যদি পরীক্ষায় প্রত্যেককে বিক্রয় করতে চান তবে নিম্নলিখিতগুলি করুন:

  1. গুচ্ছ পরীক্ষাগুলি লিখুন।
  2. কোড পরিবর্তন করে এবং আপনার পরীক্ষা (গুলি) কে ব্যর্থ করে এমন অন্যান্য বিকাশকারীকে অবহিত করুন।
  3. তারা তাদের কোড ঠিক করবে।
  4. এখন আপনি সেই বিশেষ বাগগুলি ছাড়াই মুক্তি দিতে পারেন।

এমনকি কোনও পরিচালকও এটি বুঝতে পেরেছিলেন।


ইউনিট পরীক্ষার ফলে আপনার রিলিজ বাগ-মুক্ত হবে না। এটি বাগের সংখ্যাটি হ্রাস করতে পারে, তবে পরীক্ষার কারণে / যেটি / ত্রুটিযুক্ত উত্পাদনে আঘাত করে নি তার সংখ্যা সংখ্যা পরিমাপ করা অত্যন্ত কঠিন।
টম

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

@ জ্যাকলাম যথারীতি এটি ব্যয় / লাভের অনুপাতের উপর নির্ভর করে।
কোয়ান্ট_দেব

2

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


2

বেশিরভাগ ভাল ধারণার মতো, ধারণার তুলনায় সাংগঠনিক পথ নির্ভরতার সাথে গ্রহণের আরও অনেক কিছু রয়েছে।

বেশিরভাগ সংস্থায় যে পণ্যগুলি সরবরাহ করা হয়েছে, তাদের মধ্যে সিনিয়র স্তরের কিউএ হেড দিয়ে একটি যথেষ্ট কিউএ বিভাগ তৈরি করা হয়েছে। টেস্টিং কিউএ দলের ফিফডম।

কিউএ টিম ইউনিট টেস্ট কোডটি লেখার সম্ভাবনা কম কারণ কোম্পানি সাধারণত তার ভারী শুল্ক কোডার দিয়ে কিউএ টিমকে কর্মী দেয় না।

প্রোগ্রামিং দলটি পরীক্ষার কোডটি লিখতে নারাজ কারণ এটি QA দলের সাথে দ্বন্দ্ব তৈরি করে।

আমি আরও আগ্রহী এবং ইউনিট টেস্টিং গ্রহণ করে এমন গ্রুপগুলিতে দেখছি যেখানে QA আলাদা চাকরির কার্যক্রমে কাটা হয়নি


1

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


আপনার আরওআই সম্পর্কিত লিঙ্কগুলি পড়া উচিত।
jcollum

1

বেশিরভাগ সংস্থা অকেজো। আপনি (বা আমি) যার পক্ষে কাজ করেন তা নয়, স্পষ্টতই।


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

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