ইউনিট টেস্টিং বা পরীক্ষা-চালিত উন্নয়ন কি সার্থক?


48

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

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

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

এছাড়াও, এমন কি এমন কিছু আছে যা টিডিডি বিশেষত স্ক্রামের জন্য ভাল করে তোলে?


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

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

2
"লোকেরা সত্যিকারের কোড লিখলে ক্র্যাচ দেয়"? সর্বাধিক সেরা অনুশীলনগুলি এভাবে বর্ণনা করা যায় না ?
ব্যবহারকারী16764

4
@ ডেভিডওয়্যালেস: এটি টিডিডির অভাব নয়, অযোগ্য বিকাশকারীদের সমস্যা। তদ্ব্যতীত, যখন টিডিডি ব্যাপকভাবে ব্যবহৃত হয়, এটি শূন্য গ্যারান্টি দেয় যে আপনি যে পরিবর্তনটি করেছেন তা কিছুই ভঙ্গ করে না।
কোডার

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

উত্তর:


68

সংক্ষিপ্ত উত্তর: একেবারে ইতিবাচক।

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

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

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

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


5
আমি কী যুক্ত করতে চাই, সেই ইউনিট পরীক্ষাটি আপনাকে আপনার ইন্টারফেসের নকশা সম্পর্কেও ভাবিয়ে তোলে makes আপনি যখন এমন কোনও অংশে পৌঁছে যান যেখানে আপনি মনে করেন "আমি কীভাবে বেসরকারী পদ্ধতি পরীক্ষা করব?", আপনি জানেন যে এটি সম্ভবত আপনার ইন্টারফেসটি ভুল।
টিসি 1

1
"আমি আপনাকে একটি বর্ধিত সময় ধরে চেষ্টা করতে এবং নিজেই উপকারিতা পেতে উত্সাহিত করি।" কেবল একবার চেষ্টা করা আমার পক্ষে যথেষ্ট ছিল, সুবিধাগুলি সুস্পষ্ট বলে মনে হয়েছিল।
নিমচিম্পস্কি

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

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

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

16

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

এখানে চিত্র বর্ণনা লিখুন

চিত্র উত্স


Traditional তিহ্যবাহী বলতে কী বোঝ ? টিডিডি নয় এমন কিছু?
জর্জিও

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

9

ইউনিট টেস্টিং বা পরীক্ষা চালিত উন্নয়ন কি মূল্যবান?

হ্যাঁ এটা আছে । চাচা বব (রবার্ট সি মার্টিন) একটি উপস্থাপনায় বলেছেন;

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

এবং যেহেতু আপনি পরীক্ষাটি মুছে ফেলছেন না, যতক্ষণ না পরীক্ষাটি পাস হয় আপনি নিশ্চিত যে কার্যকারিতাটি কাজ করছে - রিগ্রেশন সম্পর্কিত সমস্যাগুলি সমাধান হয়ে গেছে।

এটিতে প্রচুর স্টাফ লেখা আছে,

  1. বৈশিষ্ট্যটির কাজটি করার জন্য আপনি দায়বদ্ধ। একটি পরীক্ষা লিখুন। সপ্তাহের দিন.
  2. ইন্টিগ্রেশন টেস্টের সাথে ইউনিট টেস্টগুলি কখন প্রতিস্থাপন করবেন

এসসিআরএম, ইউনিট টেস্টিং এবং টিডিডি কি সম্পর্কিত?

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

এমন কি এমন কিছু আছে যা টিসিডি বিশেষত এসসিআরএম-র জন্য ভাল করে?

আমি উপরে বলেছি যে তারা একটি ভাল সমন্বয় তৈরি করে ; যদি আপনি এটিতে কিছু অটোমেশন টেস্টিং যুক্ত করেন তবে এটি আরও বিশেষ


8

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

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

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

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

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

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

এছাড়াও, এমন কি এমন কিছু আছে যা টিসিডি বিশেষত এসসিআরএম-র জন্য ভাল করে?

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


6

লোকেরা এটি অতিরিক্ত প্রচেষ্টা বলে মনে করে কারণ এটি একটি সামনের কার্যক্রম। সময়ের মধ্যে আপনি যা হারিয়েছেন এখন তা আবার ফিরে পাবেন।

ইউনিট পরীক্ষার জন্য আমার কারণগুলির মধ্যে রয়েছে:

আপনাকে লক্ষ্য দেয়: সফ্টওয়্যারটি কী করবে তা আপনি যদি না জানেন তবে আপনি পরীক্ষা লিখতে পারবেন না। এটি পূর্বের পরিবর্তে স্পেসিফিকেশনগুলিতে সমস্যাগুলিকে আগাছা কাটাতে সহায়তা করে।

আপনাকে অগ্রগতির অনুভূতি দেয়।

আপনাকে সতর্ক করে যদি কোনও কোড পরিবর্তন কোডের অন্যান্য ক্ষেত্রের আউটপুট পরিবর্তন করে। এটি রিফ্যাক্টরিংকে সহজ করে তোলে।

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

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

এই থ্রেডের অন্যান্য পোস্টগুলিতে অন্যদের পাশাপাশি কভার করা হয়েছে। এটা মূল্য।


2

ইউনিট টেস্টিং বা পরীক্ষা-চালিত উন্নয়ন কি সার্থক?

অবশ্যই হ্যাঁ (অন্যান্য উত্তর দেখুন)

[এটি] সত্যিই একটি ভাল ধারণা এবং প্রচেষ্টা এবং সময় মূল্য?

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

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

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

আপনি টিডিডি করলে কোডটি স্বয়ংক্রিয়ভাবে পরীক্ষাযোগ্য।


2

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

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

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

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

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

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


1

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

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

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


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

0

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

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

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

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

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

সুতরাং, আপনার একটি পছন্দ আছে। আপনি টিডিডি অনুশীলন করে ডিজাইন এবং ডকুমেন্টেশন করতে পারেন যা আমার 10 বছরের বিকাশের অভিজ্ঞতার ভিত্তিতে এই জাতীয় ডকুমেন্টেশন তৈরির একমাত্র জ্ঞাত এবং প্রমাণিত পদ্ধতি। অথবা আপনি রাজনীতিতে যেতে পারেন।


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

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

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

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