ইউনিট পরীক্ষা না করা কখন উপযুক্ত?


138

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

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

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

তাই প্রতিবার একই উপসংহারে শেষ করছি। বিনিয়োগের ক্ষেত্রে রিটার্ন খুব কম।

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

আমার পরিস্থিতিতে, আপনি কি এখনও ইউনিট টেস্টিংকে নিয়মিত অনুশীলন করার কোনও উপায় খুঁজে পাবেন, বা আমি এই ওভারহেড এড়ানো ন্যায়সঙ্গত?

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


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

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

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

1
এটি আসলে কোনও উত্তর নয়, কেবল একটি পর্যবেক্ষণ ... ইউনিট-পরীক্ষার বিরুদ্ধে আপনার যুক্তি কারণ "প্রয়োজনীয়তাগুলি খুব ঘন ঘন পরিবর্তিত হয়" আমাকে যেখানে আমি যেখানে কাজ করি তার বিপরীত যুক্তির কথা মনে করিয়ে দেয়: "আমাদের প্রোগ্রামগুলি এত স্থির, পরীক্ষার মূল বিষয় কী? এটা? এটি প্রায় কোনওভাবেই বদলায় না! " ;)
বনে

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

উত্তর:


84

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

তাই? আপনাকে সব কিছু পরীক্ষা করতে হবে না । শুধু প্রাসঙ্গিক জিনিস।

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

এটা আসলে মিথ্যা। এটি বেশি দক্ষ নয়। এটা সত্যিই একটি অভ্যাস।

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

এটা খুব, খুব দক্ষ।

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

এটাও মিথ্যা। পরীক্ষাগুলি টানা হয় না। প্রয়োজনীয় পরিবর্তনগুলি হ'ল টানুন।

প্রয়োজনীয়তা প্রতিফলিত করতে আপনাকে পরীক্ষাগুলি ঠিক করতে হবে। তাদের মিনটিয়া হোক বা উচ্চ-স্তরের; প্রথম লেখা বা সর্বশেষে লিখিত

কোডগুলি পাস না হওয়া পর্যন্ত সম্পন্ন হয় না। এটিই সফটওয়্যারটির সর্বজনীন সত্য।

আপনার একটি সীমাবদ্ধ থাকতে পারে "এটি এখানে" গ্রহণযোগ্যতা পরীক্ষা।

অথবা আপনি কিছু ইউনিট পরীক্ষা করতে পারেন।

অথবা আপনি উভয় থাকতে পারে।

তবে আপনি যাই করেন না কেন, সফ্টওয়্যারটি কাজ করে তা প্রমাণ করার জন্য সর্বদা একটি পরীক্ষা থাকে।

আমি প্রস্তাব দিচ্ছি যে সামান্য কিছু আনুষ্ঠানিকতা এবং চমৎকার ইউনিট পরীক্ষার সরঞ্জাম স্যুট সেই পরীক্ষাকে অনেক বেশি দরকারী করে তোলে।


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

9
@ কেন পেসপিসা: দুঃখিত আমি প্রায় দু'বছর আগে টিডিডি কুল-এইড পান করেছিলাম (পরীক্ষার শেষের 30 বছর পরে)। এখন আমি টেস্টে প্রথম আটকে আছি। এটি আমাকে অনেক বেশি, উত্পাদনশীল করে তোলে কারণ নির্মাণের সময় আমার করার চিন্তাভাবনা কম।
এস। লট

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

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

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

107

কল্পনা করুন যে আপনার পরীক্ষাগুলির একটি স্যুট রয়েছে যা আইব্লিংক চালাতে পারে এবং একটি সবুজ বা লাল আলো জ্বেলে উঠবে। কল্পনা করুন যে পরীক্ষাগুলির এই স্যুটটি সবকিছু পরীক্ষা করেছে ! কল্পনা করুন যে পরীক্ষার স্যুট চালাতে আপনাকে যা করতে হয়েছিল তা হ'ল। টি টাইপ করা। এটি আপনাকে কী শক্তি দেবে?

কিছু ভঙ্গ করার ভয় ছাড়াই আপনি কোডটিতে পরিবর্তন আনতে পারেন? কোনও পুরানো বৈশিষ্ট্য ভঙ্গ করার ভয় ছাড়াই আপনি কি নতুন বৈশিষ্ট্য যুক্ত করতে পারবেন? আপনি ক্ষতি করার ভয় ছাড়াই অগোছালো কোডটি দ্রুত পরিষ্কার করতে পারবেন?

হ্যাঁ, আপনি এই সমস্ত জিনিস করতে পারে! এবং সময়ের সাথে সাথে আপনার কোডের কী হবে? এটি পরিষ্কার এবং ক্লিনার পাবেন কারণ এটি পরিষ্কার করার কোনও ঝুঁকি নেই।

আসুন কল্পনা করুন যে আপনি কাঁধে একটি পরী ছিল। যতবারই আপনি কোডের একটি লাইন লিখেছিলেন, পরী টেস্ট স্যুটে এমন কিছু যুক্ত করত যা পরীক্ষিত করে যে কোডটির লাইনটি এটি করার উদ্দেশ্যে যা করেছিল তাই করেছিল। সুতরাং প্রতি কয়েক সেকেন্ডের মধ্যে আপনি hit T হিট করতে পারেন এবং দেখুন যে আপনি লিখেছেন কোডের শেষ লাইনটি কাজ করেছে।

আপনি কতটা ডিবাগিং করবেন বলে আপনি মনে করেন?

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

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

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


28
বাহ, আঙ্কেল বব? আপনার চিন্তা এখানে পেয়ে দুর্দান্ত। আমি আপনার সাথে টিডিডির সুবিধা নিয়ে একমত, সেখানে আসলেই কোন যুক্তি নেই। প্রশ্নটি সময় বিনিয়োগ এবং আরওআইয়ের বিষয়ে। এই বিষয়গুলি বিবেচনা করা আমার পক্ষে বোকামি নয়। কল্পনা করুন যে কোনও প্রকল্পের বাইরে টিডিডি শেষ করতে আমার ৫০% বেশি সময় লাগবে, এবং পরী আমাকে বলে যে এটি প্রকল্পের আজীবন ম্যানুয়াল পরীক্ষায় আমার কেবলমাত্র 10% সময় সাশ্রয় করবে। এটি একটি কল্পনার মতো মনে হতে পারে তবে আমি এটি নির্দিষ্ট প্রকল্পগুলির সাথে পুরোপুরি প্রশংসনীয় দেখতে পাচ্ছি।
কেন পেসপিসা

11
@ কেন "কল্পনা করুন যে কোনও প্রকল্পে আমাকে টিডিডি ছাড়াই শেষ হতে 50% বেশি সময় লাগবে"। এটি আমার কাছে কল্পনার মতো অবাক লাগে sounds প্রকৃতপক্ষে, এটির মতো মনে হচ্ছে আপনি এটির পক্ষে প্রমাণ হিসাবে কোনও চিহ্ন ছাড়াই এই চিত্রটি সুনির্দিষ্টভাবে তৈরি করেছেন।
রেন হেনরিচস

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

11
@ রেইন, "উপলব্ধ প্রমাণগুলি ঠিক কী?" সম্প্রসারিত করুন.
কেন পেসপিসা

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

34

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

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

দ্বিতীয়ত এগুলি চালানো ত্রুটিগুলি প্রকাশ করে যা অন্যথায় পরীক্ষায় আসে।

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

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

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

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


2
@ কেন, টেস্ট স্যুটগুলি এক্সিকিউটেবল ফর্মের নির্দিষ্টকরণ।

32

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

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

  1. একটি পরীক্ষা লিখুন
  2. এটি ব্যর্থ দেখুন (আপনার কিছু করার আছে তা প্রমাণ করুন)
  3. পরীক্ষার পাস করার জন্য যা প্রয়োজন তা লিখুন - আর নেই।
  4. এটি পাস দেখুন (হ্যাঁ!)
  5. রিফ্যাক্টর (এটি আরও ভাল করুন)
  6. ধুয়ে, ধুয়ে ফেলুন এবং পুনরাবৃত্তি করুন

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

এখন, আপনার কি সি # বৈশিষ্ট্যের মতো জিনিসগুলি পরীক্ষা করা দরকার? এর মতো সংজ্ঞাযুক্ত একটি সম্পত্তিটি কল্পনা করুন:

bool IsWorthTesting {get; set;}

উত্তরটি "না" হবে এটি পরীক্ষা করার মতো নয়, কারণ এই মুহুর্তে আপনি ভাষা বৈশিষ্ট্যটি পরীক্ষা করছেন। কেবল বিশ্বাস করুন যে সি # প্ল্যাটফর্মের ছেলেরা এটি সঠিকভাবে পেয়েছে। এছাড়াও, যদি এটি ব্যর্থ হয় তবে আপনি এটি ঠিক করতে কী করতে পারেন?

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

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

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


24

বাগের দামের সাথে আপনাকে পরীক্ষার ব্যয়কে ভারসাম্যপূর্ণ করতে হবে।

কোনও ফাংশনের জন্য 10 লাইন ইউনিট পরীক্ষা লেখার ফলে একটি ফাইল খোলে, যেখানে ব্যর্থতা "ফাইলটি পাওয়া যায় নি" সেখানে অর্থহীন।

একটি ফাংশন যা জটিল ডেটা কাঠামোর জন্য জটিল কিছু করে - তবে অবশ্যই হ্যাঁ।

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


23

পরীক্ষা হচ্ছে জুয়া খেলা।

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

কোনও বাজি মতো, কখনও আপনি জিতেন, কখনও কখনও আপনি হেরে যান

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

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


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

10

আমার পরামর্শটি কেবলমাত্র সেই কোডটি পরীক্ষা করা যা আপনি সঠিকভাবে কাজ করতে চান।

আপনি যে বগি হতে চান এবং আপনার পথে রাস্তায় সমস্যা তৈরি করতে চান সে কোডটি পরীক্ষা করবেন না।


9
আমার ডেন্টিস্টের এই উক্তিটি স্মরণ করিয়ে দেয়: আপনার দাঁতগুলি সমস্তই ভেসে উঠতে হবে না, কেবল আপনি রাখতে চান।
কেন পেসপিসা

আমি স্বীকার করি যে এটিই আমাকে এটি ভাবতে বাধ্য করেছিল। ;-)
নিক হজস

8

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

টিডিডি এবং ইউনিট টেস্টিং এক জিনিস নয়।

আপনি কোড লিখতে পারেন, তারপরে ইউনিট পরীক্ষা যুক্ত করুন add এটি টিডিডি নয়, এবং অনেক অতিরিক্ত কাজ।

টিডিডি হ'ল রেড লাইটের লুপে কোডিং করার অভ্যাস। সবুজ আলো. রিফ্যাক্টর পুনরাবৃত্তি।

এর অর্থ কোডের জন্য পরীক্ষাগুলি লেখা যা এখনও বিদ্যমান নেই, পরীক্ষাগুলি ব্যর্থ হওয়া দেখা, পরীক্ষাগুলি কার্যকর করার জন্য কোড ঠিক করা এবং তারপরে কোডটি "ডান" করা making এটি প্রায়শই আপনার কাজের সাশ্রয় করে

টিডিডির একটি সুবিধা হ'ল এটি ট্রিভিয়া সম্পর্কে চিন্তাভাবনা কমিয়ে দেয়। একের পর এক ত্রুটিগুলি অদৃশ্য হয়ে যায়। আপনার ফিরে আসা তালিকাটি 0 বা 1 থেকে শুরু হয় কিনা তা অনুসন্ধান করার জন্য আপনাকে এপিআই ডকুমেন্টেশনের মাধ্যমে শিকারে যেতে হবে না, কেবল এটি করুন।


আপনি কীভাবে বাইরের ত্রুটিগুলি অদৃশ্য হয়ে যায় তা বিশদ দিয়ে বলতে পারেন? আপনি কি বলছেন যে কোনও অ্যারের সূচক ডকুমেন্টেশনের মাধ্যমে অনুসন্ধান করার চেয়ে পরীক্ষার মাধ্যমে শূন্য-ভিত্তিক বা এক-ভিত্তিক কিনা আপনি আরও দ্রুত উত্তর পেতে পারেন? আমাকে সম্ভবনা - আমি আছি বেশ দ্রুত গুগল :) উপর
কেন Pespisa

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


@ কেন পেপিসা, এটি অবশ্যই দ্রুততর - কোডটি আপনি 0 বা 1 মনে করেন কিনা তার ভিত্তিতে কোডটি লিখুন, এটি চালান, প্রয়োজনে এটি ঠিক করুন। বেশিরভাগ সময়, আপনি ঠিক থাকবেন এবং আপনি এটি সন্ধান করতে এড়িয়ে গেছেন, যদি আপনি ভুল হয়ে থাকেন তবে আপনি 10 সেকেন্ডের মধ্যেই জানেন।
পল কসাই

খুব আকর্ষণীয় সুবিধা। যে ধরনের মত আমি।
কেন পেসপিসা

3

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

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

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


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

2

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

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

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

টিএল; ডিআর এটি সত্যই কখনই উপযুক্ত নয় কারণ সুবিধাগুলি খুব ভাল just


2

দুটি খুব ভাল উত্তর আমি এসেছি এখানে:

  1. কখন ইউনিট-পরীক্ষা বনাম ম্যানুয়াল টেস্ট
  2. ইউনিট টেস্টিংয়ের বিষয়টি পরীক্ষা করার সময় কী হবে না?

অনুভূত ওভারহেড এড়ানোর যৌক্তিকতা:

  • আপনার কোম্পানির জন্য তাত্ক্ষণিক সময় / ব্যয় সাশ্রয়
  • আপনার চলে যাওয়ার পরেও দীর্ঘমেয়াদে সমস্যার সমাধান / রক্ষণাবেক্ষণ / এক্সটেনশনে সম্ভাব্য সময় / খরচ সাশ্রয়।

আপনি কি আপনার কাজের মানের প্রমাণ হিসাবে আপনার পাশ থেকে একটি দুর্দান্ত পণ্য ছেড়ে যেতে চান না? স্বার্থপর কথায় বলতে গেলে, আপনার পক্ষে কি তা করা ভাল নয়?


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

1

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

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

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

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

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


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

1

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

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

  1. ব্যক্তিগত পদ্ধতি

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

  1. আপনি ইতিমধ্যে জানেন যে জিনিসগুলি কাজ করা উচিত (বা অন্য কারও দ্বারা পরীক্ষিত জিনিসগুলি)

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

আপনি উভয়ই টিডিডি করছেন কিনা তা উভয়ই প্রয়োগ করতে পারে।


0

কেন, আমি এবং আরও অনেক বিকাশকারী আমাদের ক্যারিয়ার জুড়ে আপনি কয়েকবার একই সিদ্ধান্তে পৌঁছেছেন।

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

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

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

তারপরের একমাত্র কৌতুকপূর্ণ অংশটি আপনি যে প্রকল্পেই করছেন তা কোন ধরণের গ্রানুলারিটি স্তর হিসাবে আপনি মনে করছেন সেরা "বক ফর দ্য ব্যাঙ্ক" think

কোনও ঠিকানা পুস্তক তৈরির জন্য এন্টারপ্রাইজ অনুসন্ধান ইঞ্জিনের চেয়ে কম পরীক্ষার প্রয়োজন হবে, তবে মূলসূত্রগুলি বাস্তবে পরিবর্তন হয় না।

শুভকামনা!


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

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