অনেকগুলি আসার কোডের গন্ধ আছে?


19

আমি ইউনিট টেস্টিং এবং টিডিডি-র প্রেমে পড়েছি - আমি পরীক্ষায় আক্রান্ত।

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

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

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

কোড গন্ধ হিসাবে কেউ কি খুব বেশি জোরের কথা ভাবতে পারে?


1
এই দাবিগুলি মুক্তি বা বন্ধ হয়?
জে কে।

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

সবেমাত্র এটি খুঁজে পেয়েছে "বাগগুলি ট্র্যাক করে প্রোডাক্টিভিটি বাড়িয়ে তোলা" প্রোগ্রামারস.স্ট্যাকেক্সেঞ্জাও.এ
১63১17১/ / ৩৩২৪৪২

আপনি "অনেকগুলি" কীভাবে সংজ্ঞায়িত করবেন?
হাইলেম

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

উত্তর:


26

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

এগুলি দৃ as়ভাবে মন্তব্যগুলি ব্যবহার করার চেয়ে দৃ Keep়রূপে রাখা আরও ভাল কারণ তারা যখনই চালিত হয় তখন তারা সক্রিয়ভাবে অনুমানগুলি পরীক্ষা করে।


2
খুব ভাল পয়েন্ট!
ফ্লোরেন্টস তুষাই

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

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

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

15

মনে হচ্ছে আপনি হাতে ডিজাইন-কন্ট্রাক্ট করার চেষ্টা করছেন ।

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

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

সুতরাং, সংক্ষেপে: আপনি যদি সত্যিই DbC করছেন, এমনকি যদি আপনি এটি জানেন না, তবে সেই উক্তিগুলি পুরোপুরি ঠিক আছে।


4

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

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

আমি মনে করি না যে আপনি রিটার্ন প্যারামিটারগুলিতে দৃ as়তার সাথে কথা বলা উচিত (যদি না আপনি স্পষ্টভাবে একটি আগত না পেয়ে থাকেন যা আপনি পাঠক বুঝতে চান)। এটি ইউনিটেটস এর কাজও।

ব্যক্তিগতভাবে আমি assertজাভাতে বিবৃতি পছন্দ করি না , যেহেতু সেগুলি বন্ধ করা যায় এবং তারপরে এটি একটি মিথ্যা সুরক্ষা।


1
+1 "" জাভাতে আমি জোর দেওয়া বিবৃতি পছন্দ করি না, যেহেতু সেগুলি বন্ধ করে দেওয়া যেতে পারে এবং তারপরে এটি একটি মিথ্যা সুরক্ষা। "
ফ্লোরেন্টস সিসলাই

3

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

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

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

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


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

যুক্তিতে (এবং অনেক ক্ষেত্রে হওয়া উচিত) লগিং এবং নিক্ষেপ ব্যতিক্রমগুলি (বা সি-তে ত্রুটি কোডগুলি) অন্তর্ভুক্ত থাকতে পারে।
ড্যানি ভারোদ

3

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

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

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

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


2

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

এছাড়াও সমস্ত প্রোগ্রামার নিখুঁত নয় - আবারও, দৃ the়তার অর্থ হল যে "স্লিপ আপগুলি" এর মধ্যে একটিও খুব বেশি প্রচার করে না।

রক্ষণাবেক্ষণের ব্যয় হ্রাস করার জন্য এই দাবীগুলির (এবং অনুমানগুলি সম্পর্কে অন্যান্য চেকস) প্রভাবগুলি কীভাবে কম করবেন তা ভাবেন না।


0

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

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

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

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


0

তবে ইউনিট টেস্টিংটি পাবলিক পদ্ধতির জন্য ব্যবহৃত হয়।

যদি আপনার পরীক্ষার কাঠামো অ্যাক্সেসরদের জন্য অনুমতি দেয় তবে ইউনিট পরীক্ষার ব্যক্তিগত পদ্ধতিগুলিও একটি ভাল ধারণা (আইএমও)।

কোড গন্ধ হিসাবে কেউ কি খুব বেশি জোরের কথা ভাবতে পারে?

আমি করি. জোর দেওয়া ঠিক আছে, তবে আপনার প্রথম লক্ষ্যটি করা উচিত যাতে দৃশ্য এমনকি সম্ভব না হয় ; শুধু যে এটি ঘটে না।


-2

এটা খারাপ অভ্যাস।

আপনার সর্বজনীন / ব্যক্তিগত পদ্ধতি পরীক্ষা করা উচিত নয় should আপনার পুরো ক্লাসটি পরীক্ষা করা উচিত। আপনার কভারেজ ঠিক আছে তা নিশ্চিত করুন।

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

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

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


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

এছাড়াও "এটি পরামর্শ দেয় যে কোডটির লেখক সত্যই জানেন না যে তিনি কী করছেন [...] আপনি কি করছেন।" ভবিষ্যতের বিকাশকারীরা কোনও নির্দিষ্ট পদ্ধতি কী করে সে সম্পর্কে এতটা পরিষ্কার হতে পারে না। এই ক্ষেত্রে, asserts আকারে প্রাক এবং পোস্ট শর্তাবলী একটি কোড বুঝতে পারার ক্ষেত্রে অমূল্য হতে পারে।
ওলেক্সি

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