ইউনিট টেস্টিং সক্ষম করতে কি আমাদের কোডটি শুরু থেকেই ডিজাইন করা উচিত?

Question

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

বিশেষত, আমাদের একটি ওয়েব এপিআই পরিষেবা থাকবে যা খুব পাতলা হবে। এর মূল দায়িত্ব হ'ল ওয়েব অনুরোধগুলি / প্রতিক্রিয়াগুলিকে মার্শাল করা এবং ব্যবসায় যুক্তিযুক্ত একটি অন্তর্নিহিত API কল করা।

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

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

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

কেবল স্পষ্ট করে বলতে গেলে, এটি একেবারে নতুন প্রকল্প, সুতরাং ইউনিট পরীক্ষার সক্ষম করার জন্য কোডটি পরিবর্তন করার পক্ষে এটি সত্যই নয়; এটি ইউনিট টেস্টেবল হতে আমরা যে কোডটি লিখছি তা ডিজাইন করার বিষয়ে about

Comments

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

— ডক ব্রাউন

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

— খ্রিস্টান হ্যাকেল

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

— l0b0

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

— আর স্মিটজ

মাইকেল ফেদারস বইয়ের সুপারিশের জন্য ধন্যবাদ, আমি অবশ্যই একটি অনুলিপি গ্রহণ করব।

— লি

Answer 1

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

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

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

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

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

Comments

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

— ম্যাথিউ মিঃ

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

— খ্রিস্টান হ্যাকেল

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

— কনরাড রুডলফ

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

— বাল্ড্রিক 24

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

— আফপা

Answer 2

এটি যতটা সহজ আপনি ভাবেন তেমন সহজ নয়। আসুন এটি ভেঙে দিন।

• লেখার ইউনিট পরীক্ষা অবশ্যই একটি ভাল জিনিস।

কিন্ত!

• আপনার কোডের যে কোনও পরিবর্তন একটি ত্রুটি প্রবর্তন করতে পারে। সুতরাং কোনও ব্যবসায়ের কারণ ছাড়াই কোড পরিবর্তন করা ভাল ধারণা নয়।

• আপনার 'খুব পাতলা' ওয়েবপিকে ইউনিট পরীক্ষার জন্য সবচেয়ে বড় কেসের মতো মনে হচ্ছে না।

• কোড এবং পরীক্ষা একই সাথে পরিবর্তন করা খারাপ জিনিস a

আমি নিম্নলিখিত পদ্ধতির পরামর্শ দেব:

1. ইন্টিগ্রেশন পরীক্ষা লিখুন । এর জন্য কোনও কোড পরিবর্তনের প্রয়োজন হবে না। এটি আপনাকে আপনার মৌলিক পরীক্ষার কেস দেবে এবং আপনার করা কোডের আরও কোনও পরিবর্তন কোনও বাগ প্রবর্তন করবে না তা পরীক্ষা করতে সক্ষম করবে।

2. নিশ্চিত হয়ে নিন যে নতুন কোডটি পরীক্ষামূলক এবং এর ইউনিট এবং সংহতকরণ পরীক্ষা রয়েছে।

3. আপনার সিআই চেইন বিল্ড এবং স্থাপনার পরে পরীক্ষা চালিয়েছে তা নিশ্চিত করুন।

আপনি যখন এই জিনিসগুলি সেট আপ করেন, কেবল তখনই টেস্টিবিলিটির জন্য লিগ্যাসি প্রকল্পগুলি রিফ্যাক্টর করার বিষয়ে চিন্তা শুরু করুন।

আশা করি সবাই প্রক্রিয়াটি থেকে শিক্ষা গ্রহণ করবে এবং পরীক্ষার সর্বাধিক প্রয়োজন কোথায়, আপনি কীভাবে এটি কাঠামো তৈরি করতে চান এবং ব্যবসায় এটির জন্য কী মূল্য নিয়ে আসে সে সম্পর্কে একটি ভাল ধারণা থাকবে।

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

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

Comments

এটি গৃহীত উত্তরটির চেয়ে অনেক ভাল উত্তর। ভোটের ভারসাম্যহীনতা হতাশাব্যঞ্জক।

— কনরাড রুডলফ

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

— ওয়েস টলেম্যান

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

— ডক ব্রাউন

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

— সুলতান

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

— অ্যান্ডার্স ফোর্সগ্রেন

Answer 3

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

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

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

Comments

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

— Riking

Answer 4

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

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

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

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

Comments

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

— লি

@ লী: একটি সংস্থায় পরিবর্তন আনার ফলে সর্বদা কিছুটা প্রতিরোধের সৃষ্টি হয় এবং নতুন জিনিসগুলিকে মানিয়ে নিতে সর্বদা কিছুটা সময় প্রয়োজন, এটি কোনও নতুন জ্ঞান নয়। এটি একটি মানুষের সমস্যা।

— ডক ব্রাউন

একেবারে। আমি কেবল আমাদের আরও সময় দেওয়া চাই!

— লি

এটি প্রায়শই লোকদের দেখানোর বিষয় যে এটি এভাবে করা তাদের সময় সাশ্রয় করবে (এবং আশা করি খুব দ্রুত)। এমন কিছু করবেন যা আপনার উপকারে আসবে না?

— থরবজর্ন রাভন অ্যান্ডারসন

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

— ক্রিশ্চিয়ান হ্যাকেল

Answer 5

আপনার করা (অসমর্থিত) দৃser়তার সাথে আমি বিষয়টি নিয়েছি:

ওয়েব এপিআই পরিষেবাটি পরীক্ষা করার জন্য আমাদের এই কারখানাটি উপহাস করতে হবে

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

একটি বিকল্প পরীক্ষার সিঁম খুঁজে পেতে আপনাকে সহায়তা করার জন্য কিছু প্রশ্ন, যা আরও প্রাকৃতিক হতে পারে:

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

আপনার করা অন্য একটি অসমর্থিত দাবি: ডিআই সম্পর্কে:

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

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

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

Comments

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

— লি

Answer 6

এটি একটি নতুন প্রকল্প হিসাবে আপনি ভাগ্যবান। আমি খুঁজে পেয়েছি যে টেস্ট ড্রাইভড ডিজাইন ভাল কোড লেখার জন্য খুব ভাল কাজ করে (যার কারণে আমরা এটি প্রথম স্থানে করি)।

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

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

এটা বিবেচনা. বিশেষত পিয়ার পর্যালোচনা সহ। আমার অভিজ্ঞতায় সময় এবং প্রচেষ্টার বিনিয়োগ খুব দ্রুত ফিরে আসবে।

Comments

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

— লি

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

— আর স্মিটজ

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

— আর স্মিটজ

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

— থরবজর্ন রাভন অ্যান্ডারসন

এছাড়াও, রিগ্রেশন টেস্টগুলি খুব গুরুত্বপূর্ণ। তারা কি দলের জন্য সুযোগ আছে?

— থরবজর্ন রাভন অ্যান্ডারসন

Answer 7

আপনার যদি কোডটিতে পরিবর্তন করতে হয় তবে তা হল কোডের গন্ধ।

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

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

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

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

Comments

"থ্রোওয়ে প্রোটোটাইপ" - প্রতিটি একক প্রকল্পই জীবনকে সেই সময়ের মধ্যে একটি হিসাবে শুরু করে ... জিনিসকে কখনই না সে হিসাবে ভাবা ভাল। আমি যেমন টাইপ করছি .. অনুমান কি? ... থ্রোওয়ে প্রোটোটাইপ রিফ্যাক্টরিং যা তা হয়ে

— উঠেনি

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

— থোরবজর্ন রাভন অ্যান্ডারসন

@ ThorbjørnRavnAndersen যা আমাকে কড়াকড়ি করে তুলেছে। তার মানে কি এই ভাষাগুলিতে একটি খনন করা উচিত? :)

— লি

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

— থোরবজর্ন রাভন অ্যান্ডারসন

Answer 8

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

তুমি বলো

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

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

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

Answer 9

প্রতিটি ইঞ্জিনিয়ারিং বিভাগে আমি ভাবতে পারি, শালীন বা উচ্চ স্তরের মানের অর্জনের একমাত্র উপায়:

ডিজাইনে পরিদর্শন / পরীক্ষার জন্য অ্যাকাউন্ট করা।

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

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

Answer 10

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

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

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

Comments

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

— থোরবজর্ন রাভন অ্যান্ডারসন

Answer 11

সংক্ষেপে:

বরং বা, কোড যে - Testable কোড (সাধারণত) রক্ষণীয় কোড হার্ড পরীক্ষা করার জন্য সাধারণত কঠিন বজায় রাখার জন্য। টেস্টযোগ্য নয় এমন ডিজাইনিং কোডটি মেরামতযোগ্য নয় এমন একটি মেশিন ডিজাইনের অনুরূপ - দরিদ্র শামককে করুণা করুন যিনি শেষ পর্যন্ত এটি মেরামত করার জন্য নিযুক্ত করা হবে (এটি আপনি হতে পারে)।

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

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

Answer 12

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

Comments

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

— জানুয়ারী

@ জন এটি আকর্ষণীয় তারা কীভাবে ভুল করেছে?

— লি

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

— জানুয়ারী

Answer 13

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

আসুন পরীক্ষার যোগ্যের মধ্যে পার্থক্যটি দেখুন:

public class MyController : Controller
{
    private readonly IMyDependency _thing;

    public MyController(IMyDependency thing)
    {
        _thing = thing;
    }
}

এবং অ পরীক্ষামূলক নিয়ামক:

public class MyController : Controller
{
}

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

টেডিবিলিটি মঞ্জুর করার জন্য কোডের 6 টি অতিরিক্ত লাইন ... এবং আপনার সহকর্মীরা এই বিতর্ক করছেন যে এটি "খুব বেশি কাজ"? এই যুক্তিটি আমার সাথে উড়বে না এবং এটি আপনার সাথে উড়তে হবে না।

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

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

Comments

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

— খ্রিস্টান হ্যাকেল

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

— ইয়ান কেম্প

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

— খ্রিস্টান হ্যাকেল

Answer 14

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

আপনি যতটা পারেন খাঁটি ফাংশন ব্যবহার করার প্রবণতা রয়েছে (সার্ভারলেস অ্যাপস)। ইউনিট টেস্টিং আমাকে রাষ্ট্রকে বিচ্ছিন্ন করতে এবং খাঁটি ফাংশন লিখতে সহায়তা করে।

বিশেষত, আমাদের একটি ওয়েব এপিআই পরিষেবা থাকবে যা খুব পাতলা হবে। এর মূল দায়িত্ব হ'ল ওয়েব অনুরোধগুলি / প্রতিক্রিয়াগুলিকে মার্শাল করা এবং ব্যবসায় যুক্তিযুক্ত একটি অন্তর্নিহিত API কল করা।

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

টিএল; ডিআর, ইউনিট টেস্টিং কোডের মান উন্নত করতে সহায়তা করে এবং কোডকে ঝুঁকিমুক্ত ভবিষ্যতে পরিবর্তন করতে সহায়তা করে। এটি কোডের পঠনযোগ্যতাও উন্নত করে। আপনার বক্তব্য তৈরি করার জন্য মন্তব্যের পরিবর্তে পরীক্ষাগুলি ব্যবহার করুন।

Answer 15

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

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

স্পষ্টতই কিছু লোকের এ সম্পর্কে আলাদা ধারণা রয়েছে। আমি আপনাকে প্রথমে এটি ঠিক করার চেষ্টা করার পরামর্শ দিচ্ছি।