টেস্টেবল কোড কি আরও ভাল কোড?

Question

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

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

পরীক্ষার যোগ্য কোডটি কি পরীক্ষার অভাবে এমনকি এখনও অনুশীলন করা ভাল ?

---

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

Comments

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

— রবার্ট হার্ভে

আপনি কি "আরও ভাল কোড" সংজ্ঞায়িত করতে পারেন? আপনার অর্থ কি "রক্ষণাবেক্ষণযোগ্য" ?, "আইওসি-কনটেইনার-যাদুবিহীন ব্যবহারযোগ্য?"

— k3b

আমি অনুমান করি আপনি কখনই পরীক্ষাতে ব্যর্থ হননি কারণ এটি প্রকৃত সিস্টেমের সময় ব্যবহার করে এবং তারপরে টাইম জোনের অফসেট পরিবর্তিত হয়।

— অ্যান্ডি

এটি অকেটেস্টেবল কোডের চেয়ে ভাল।

— তুলিনাস কর্ডোভা

@RobertHarvey আমি যে idempotency কল না, আমি বলতে হবে এটা উল্লেখ স্বচ্ছতা যদি func(X)আয় "Morning", তারপর সব occurences প্রতিস্থাপন func(X)সঙ্গে "Morning"প্রোগ্রাম পরিবর্তন করবে না (অর্থাত কলিং। funcঅন্য যেকোনো কিছুর চেয়ে মান না না)। আইডেম্পোটেন্সিটি বোঝায় যেটি func(func(X)) == X(যা টাইপ-সঠিক নয়), বা func(X); func(X);এটি একই পার্শ্ব-প্রতিক্রিয়াগুলি সম্পাদন করে func(X)(তবে এখানে কোনও পার্শ্ব-প্রতিক্রিয়া নেই)

— ওয়ারবো

Answer 1

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

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

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

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— বিশ্ব প্রকৌশলী

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

— jpmc26

আমি মনে করি "পরীক্ষার কাঠামোর সাথে মানিয়ে নিতে" টেস্টেবল কোড "এবং" কোড [বাঁকা] "এর মধ্যে পার্থক্য রয়েছে। আমি এই মন্তব্যটি নিয়ে কোথায় যাচ্ছি তা নিশ্চিত নই, আমি ছাড়াও আমি একমত যে "বাঁকানো" কোডটি খারাপ, এবং ভাল ইন্টারফেসের সাথে "টেস্টেবল" কোডটি ভাল।

— ব্রায়ান ওকলে

আমি নিবন্ধটির মন্তব্যে আমার কিছু ধারণা প্রকাশ করেছি (যেহেতু এখানে প্রসারিত মন্তব্যের অনুমতি নেই), এটি পরীক্ষা করে দেখুন! পরিষ্কার হতে হবে: আমি উল্লিখিত নিবন্ধটির লেখক :)

— সের্গেই কোলোদিয়

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

— ভিন্স এমি

Answer 2

পরীক্ষার যোগ্য কোডটি কি পরীক্ষার অভাবে এমনকি এখনও অনুশীলন করা ভাল?

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

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

আমার কাছে তাই লিখিত কোডে সর্বদা অগ্রাধিকারের সেট থাকে:

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

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

Comments

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

— ওয়ানাবাকেডার

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

— জেভেন্টিং

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

— লুয়ান

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

— তৃতীয়

@ টেলাস্টিন 10 বছরেরও বেশি বিকাশের মধ্যে আমার কখনই একটি দল ছিল না যা ইউনিট পরীক্ষার কাঠামোকে বাধ্যতামূলক করেছিল এবং কেবল দু'জনের এমনকি একটিতেও ছিল (উভয়েরই কভারেজ ছিল না)। আপনি যে বৈশিষ্ট্যটি লিখছিলেন তা কীভাবে পরীক্ষা করতে হবে তার এক জায়গায় শব্দের নথির প্রয়োজন document এটাই. সম্ভবত আমি দুর্ভাগ্য? আমি ইউনিটবিরোধী পরীক্ষা নই (গুরুতরভাবে, আমি এসকিউএ.এসই সাইটটি সংশোধন করছি, আমি খুব প্রো ইউনিট পরীক্ষা!) তবে আপনার বিবৃতি দাবির মতো এগুলি বিস্তৃত হিসাবে আমি পাইনি।

— কর্সিকা

Answer 3

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

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

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

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

Comments

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

— ভ্যালেনটারি

Nobody cares about the tests themselves-- আমি করি. কোডগুলি কোনও মন্তব্য বা রিডমি ফাইলের চেয়ে কোড কী করে তার একটি আরও ভাল ডকুমেন্টেশন হিসাবে আমি পরীক্ষাগুলি খুঁজে পাই।

— jcollum

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

— plast1k

Answer 4

এক পর্যায়ে মানটি আরম্ভ করা দরকার, এবং কেন গ্রাহকের নিকটতম নয়?

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

কার্যত কোড টেস্টেবল তৈরির অর্থ কোড তৈরি করা (যা শুরু থেকে) দুটি পৃথক পরিস্থিতিতে ব্যবহার করা যেতে পারে (উত্পাদন এবং পরীক্ষা)।

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

এছাড়াও, আমার মনে পদ্ধতিটির উদ্দেশ্য হ'ল বর্তমান সময়ের উপর ভিত্তি করে কিছু মান ফেরত দেওয়া, এটি একটি প্যারামিটার করে আপনি বোঝাচ্ছেন যে এই উদ্দেশ্যটি পরিবর্তন করা উচিত /।

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

Answer 5

এটি এভাবে বলা নির্বোধ বলে মনে হতে পারে তবে আপনি যদি নিজের কোডটি পরীক্ষা করতে সক্ষম হতে চান তবে হ্যাঁ, পরীক্ষার যোগ্য কোডটি লেখাই ভাল। আপনি জিজ্ঞাসা:

এক পর্যায়ে মানটি আরম্ভ করা দরকার, এবং কেন গ্রাহকের নিকটতম নয়?

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

অবিচ্ছিন্ন হওয়া ছাড়াও, সেই ছোট পদ্ধতির প্রশ্নে দুটি দায়িত্ব রয়েছে: (১) সিস্টেমের সময় পাওয়া এবং তারপরে (২) এর ভিত্তিতে কিছু মূল্য ফেরত দেওয়া।

public static string GetTimeOfDay()
{
    DateTime time = DateTime.Now;
    if (time.Hour >= 0 && time.Hour < 6)
    {
        return "Night";
    }
    if (time.Hour >= 6 && time.Hour < 12)
    {
        return "Morning";
    }
    if (time.Hour >= 12 && time.Hour < 18)
    {
        return "Afternoon";
    }
    return "Evening";
}

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

Comments

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

— gnasher729

@ gnasher729 ঠিক আমার বক্তব্য "এই কোডটিকে পরীক্ষারযোগ্য করে তোলা" একটি সাধারণ পরিবর্তন যা প্রচুর (পরীক্ষার) সমস্যার সমাধান করতে পারে। আপনি যদি পরীক্ষাটি স্বয়ংক্রিয় করতে চান না, তবে আমার ধারণা কোডটি যেমন হয় তেমন পাসযোগ্য pass তবে এটি একবার "পরীক্ষামূলক" হওয়ার চেয়ে ভাল হবে।

— এরিক কিং

Answer 6

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

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

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

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

Comments

+1 - রাইটিং ইউনিট পরীক্ষা সহজ করার জন্য আপনার নকশা এবং আর্কিটেকচারের উন্নতি করতে হবে।

— BЈовић

+ - এটি আপনার কোডের গুরুত্বপূর্ণ যে এটি গুরুত্বপূর্ণ the আরও সহজ পরীক্ষা কেবল একটি সুখী পার্শ্ব-প্রতিক্রিয়া।

— gbjbaanb

Answer 7

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

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

হ্যাঁ. পরীক্ষা-নিরীক্ষা নির্বিশেষে টেস্টেবল কোড লেখাই ভাল অনুশীলন।

Comments

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

— gbjbaanb

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

— অ্যান্ড্রু হিল

Answer 8

টেস্টেবল কোড রচনা গুরুত্বপূর্ণ যদি আপনি প্রমাণ করতে সক্ষম হন যে আপনার কোডটি আসলে কাজ করে।

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

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

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

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

সুতরাং আমার সংক্ষিপ্তসার কাছাকাছি, টেস্টযোগ্য কোড আরও ভাল কোড?

আমি জানি না, সম্ভবত না। এখানকার লোকদের কিছু বৈধ পয়েন্ট রয়েছে।

তবে আমি বিশ্বাস করি যে আরও ভাল কোড টেস্টেবল কোড হতে পারে ।

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

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

Comments

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

— anaximander

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

— pjc50

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

— wobbily_col 11

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

— ক্রেগ

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

— ক্রেগ 21

Answer 9

যদিও আমার কাছে মনে হয়, যুক্তি হিসাবে সময় কাটানো ওভারকিলের মতো।

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

def time_of_day():
    return datetime.datetime.utcnow().strftime('%H:%M:%S')

এবার ধরা যাক আপনি একটি লিপ সেকেন্ডের সময় কী ঘটে তা পরীক্ষা করতে চান। আপনি যেমন বলেছিলেন, ওভারকিল পদ্ধতিতে এটি পরীক্ষা করতে আপনাকে (উত্পাদন) কোডটি পরিবর্তন করতে হবে:

def time_of_day(now=None):
    now = now if now is not None else datetime.datetime.utcnow()
    return now.strftime('%H:%M:%S')

পাইথন যদি লিপ সেকেন্ডে সমর্থন করে তবে পরীক্ষার কোডটি এর মতো দেখতে পাওয়া যাবে:

def test_handle_leap_second(self):
    actual = time_of_day(
        now=datetime.datetime(year=2015, month=6, day=30, hour=23, minute=59, second=60)
    expected = '23:59:60'
    self.assertEquals(actual, expected)

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

def time_of_day():
    return datetime.datetime.utcnow().strftime('%H:%M:%S')

পরীক্ষার কোড:

@unittest.patch('datetime.datetime.utcnow')
def test_handle_leap_second(self, utcnow_mock):
    utcnow_mock.return_value = datetime.datetime(
        year=2015, month=6, day=30, hour=23, minute=59, second=60)
    actual = time_of_day()
    expected = '23:59:60'
    self.assertEquals(actual, expected)

এটি বিভিন্ন সুবিধা দেয়:

• আপনি এর নির্ভরতাগুলি time_of_day স্বাধীনভাবে পরীক্ষা করছেন ।
• আপনি উত্পাদন কোড হিসাবে একই কোড পাথ পরীক্ষা করছেন ।
• উত্পাদন কোড যতটা সম্ভব সহজ।

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

Comments

এফওয়াইআই: আপনার ডিফল্ট যুক্তিটি ভুল। এটি কেবল একবার সংজ্ঞায়িত করা হবে, সুতরাং আপনার ফাংশনটি সর্বদা মূল্যায়নের সময়টি ফিরিয়ে আনবে।

— অহরুস

Answer 10

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

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

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

Answer 11

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

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

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

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

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

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

সংক্ষেপে, টেস্টেবল কোড অগত্যা "ভাল" কোড নয়, তবে "ভাল" কোডটি সাধারণত পরীক্ষামূলক হয়।

Answer 12

যদি আপনি সলিড নীতিগুলি নিয়ে যান তবে আপনি ভাল দিকে থাকবেন, বিশেষত যদি এটি KISS , DRY , এবং YAGNI এর সাথে প্রসারিত করুন ।

আমার জন্য একটি অনুপস্থিত বিন্দু একটি পদ্ধতির জটিলতার বিন্দু। এটি কি একটি সহজ গেটার / সেটার পদ্ধতি? তারপরে আপনার পরীক্ষার কাঠামোটি পূরণ করার জন্য কেবল পরীক্ষাগুলি লেখাই সময় নষ্ট হবে।

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

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

শুধু আমার দুই সেন্ট ।