প্রকৃত কোডের চেয়ে পরীক্ষার সময় লেখার চেয়ে বেশি ব্যয় করা কি স্বাভাবিক?


210

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

এটা কি স্বাভাবিক নাকি আমি কিছু ভুল করছি?

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

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


20
উপাখ্যানীয়, তবে আমি টিডিডি করার সময় লেখার কোডের মতো পরীক্ষার লেখার জন্য প্রায় সময় ব্যয় করি। কোডের চেয়ে পরীক্ষাগুলিতে আমি বেশি সময় ব্যয় করি এই পরে আমি যখন পিছলে যাই এবং পরীক্ষাগুলি লিখি It's
রাবারডাক

10
আপনি নিজের কোড লেখার চেয়েও বেশি সময় ব্যয় করেন।
থরবজর্ন রাভন অ্যান্ডারসন

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

5
আদর্শভাবে আপনি নিজের কোডটি লেখার চেয়ে বেশি সময় ব্যয় করবেন। (অন্যথায়, আপনি কেবল হাতে হাতে কাজটি করতেন))
জোশুয়া টেলর

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

উত্তর:


204

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

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

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

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


4
কোডটি কেন পরীক্ষা করা এত কঠিন তা খতিয়ে দেখার জন্য ভাল সময় হতে পারে :) জটিল মাল্টি-ফাংশন লাইনগুলি "আনারল" করার চেষ্টা করুন যা কঠোরভাবে প্রয়োজনীয় নয়, যেমন বৃহত্তর নেস্টেড বাইনারি / টেরিনারি অপারেটরগুলি ... আমি সত্যিই অপ্রয়োজনীয় বাইনারি ঘৃণা করি / টার্নারি অপারেটর যার একটি বাইনারি / টেরিনারি অপারেটর রয়েছে সেই পথগুলির মধ্যে একটি হিসাবে ...
নেলসন

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

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

2
@ ফায়ারফক্স আমি মনে করি এটি অত্যন্ত সতর্ক, এটি "কোডের অন্যান্য 99% প্রান্তের ক্ষেত্রে" এর মতোই। যার অর্থ অন্যান্য 99% পরীক্ষাগুলি সেই প্রান্তের ক্ষেত্রে।
Móż

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

96

এটাই.

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

একটি সাধারণ কোড বিবেচনা করুন:

public void SayHello(string personName)
{
    if (personName == null) throw new NullArgumentException("personName");

    Console.WriteLine("Hello, {0}!", personName);
}

পরীক্ষা কি হবে? এখানে পরীক্ষার জন্য কমপক্ষে চারটি সাধারণ মামলা রয়েছে:

  1. ব্যক্তির নাম null। ব্যতিক্রম আসলে নিক্ষেপ করা হয়? লেখার জন্য টেস্ট কোডের কমপক্ষে তিনটি লাইন।

  2. ব্যক্তির নাম "Jeff"। আমরা কি "Hello, Jeff!"প্রতিক্রিয়া পেতে পারি ? এটি টেস্ট কোডের চারটি লাইন।

  3. ব্যক্তির নাম একটি খালি স্ট্রিং। আমরা কী আউটপুট আশা করি? আসল আউটপুট কি? পার্শ্ব প্রশ্ন: এটি কার্যকরী প্রয়োজনীয়তার সাথে মেলে? তার মানে ইউনিট পরীক্ষার জন্য কোডের আরও চারটি লাইন।

  4. স্ট্রিংয়ের জন্য ব্যক্তির নাম যথেষ্ট সংক্ষিপ্ত, তবে একত্রিত হতে খুব দীর্ঘ "Hello, "এবং উদ্দীপনা বিন্দু। কি হয়?

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

যদি অনুপাতটি খুব বড় হয় তবে এক্ষেত্রে আপনি কয়েকটি জিনিস পরীক্ষা করতে পারেন:

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

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

  • আপনি যে কোডটি পরীক্ষা করা উচিত তা কি আপনি পরীক্ষা করছেন? আপনি তৃতীয় পক্ষের লাইব্রেরির অন্তর্নিহিত কাঠামোটি পরীক্ষা করার আশা করছেন না , তবে কেবলমাত্র প্রকল্পটির কোড।

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

টিডিডি সম্পর্কে একটি নোট

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


N একটি স্ট্রিংয়ের সর্বাধিক দৈর্ঘ্য হওয়া যাক । আমরা SayHelloরেফারেন্স দিয়ে কল এবং n দৈর্ঘ্যের একটি স্ট্রিং পাস করতে পারি - যা ঠিক কাজ করা উচিত। এখন, Console.WriteLineপদক্ষেপে, ফর্ম্যাটটির দৈর্ঘ্য n + 8 এর স্ট্রিংয়ের সাথে শেষ হওয়া উচিত , যার ফলস্বরূপ ব্যতিক্রম হবে। সম্ভবত, মেমরির সীমাবদ্ধতার কারণে, এমনকি এন / 2 অক্ষরযুক্ত স্ট্রিং একটি ব্যতিক্রম ঘটায়। যে প্রশ্নটি জিজ্ঞাসা করা উচিত তা হ'ল এই চতুর্থ পরীক্ষাটি ইউনিট পরীক্ষা কিনা (এটি দেখতে একরকম মনে হয় তবে এটির গড় ইউনিট পরীক্ষার তুলনায় সংস্থানগুলির ক্ষেত্রে আরও বেশি প্রভাব থাকতে পারে) এবং যদি এটি প্রকৃত কোড বা অন্তর্নিহিত কাঠামোটি পরীক্ষা করে।


5
কোনও ব্যক্তির নামও নাল হতে পারে তা ভুলে যাবেন না। stackoverflow.com/questions/4456438/...
psatek

1
@ জ্যাকোব্রাইহলে আমি ধরে নিয়েছি @ মাইনমা ​​মানে personNameএকটি এর মধ্যে ফিটের মান string, তবে সংযোগযুক্ত personNameমানগুলির ওভারফ্লো string
ওয়াজ

@ জ্যাকোব্রাইহলে: আমি এই উত্তরটি ব্যাখ্যা করতে আমার উত্তর সম্পাদনা করেছি পাদটীকা দেখুন।
আর্সেনী মরজেনকো

4
As a rule of thumb, if you remove a unit test, the branch coverage should decrease.আপনি উল্লিখিত চারটি পরীক্ষা যদি আমি লিখি এবং তারপরে তৃতীয় টেস্টটি সরিয়ে দিই, তবে কি কভারেজ হ্রাস পাবে?
বিবেক

3
"দীর্ঘ যথেষ্ট" long "খুব দীর্ঘ" (পয়েন্ট 4)?
পাওলো ইবারম্যান

59

আমি মনে করি পরীক্ষার কৌশলগুলির দুটি ধরণের মধ্যে পার্থক্য করা গুরুত্বপূর্ণ: ইউনিট টেস্টিং এবং ইন্টিগ্রেশন / গ্রহণযোগ্যতা পরীক্ষা।

যদিও কিছু ক্ষেত্রে ইউনিট টেস্টিং প্রয়োজনীয়, এটি প্রায়শই আশাহীনভাবে অতিরিক্ত কাজ করা হয়। এটি "100% কভারেজ" এর মতো বিকাশকারীদের উপর চাপিয়ে দেওয়া অর্থহীন মেট্রিকগুলির দ্বারা উত্থিত। http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf এটির জন্য একটি বাধ্যতামূলক যুক্তি সরবরাহ করে। আগ্রাসী ইউনিট পরীক্ষার সাথে নিম্নলিখিত বিষয়গুলি বিবেচনা করুন:

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

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

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


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

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

3
আমি আপনাকে অবহিত করছি যতক্ষণ না "গ্রহণের .equals()দ্বারা উত্পন্ন এই দীর্ঘ পদ্ধতিগুলির পরীক্ষা করার প্রয়োজন নেই । " আমি github.com/GlenKPeterson/TestUtils এর জন্য একটি পরীক্ষার জোতা লিখেছি equals()এবং আমি পরীক্ষিত প্রায় প্রতিটি বাস্তবায়নের অভাব ছিল। আপনি সংগ্রহ করে কিভাবে ব্যবহার করব এবং একসঙ্গে সঠিকভাবে এবং দক্ষতার কাজ করে না? আমি আপনার উত্তর বাকি জন্য আবার উত্সাহিত এবং এটি ভোট দিয়েছি। এমনকি আমি স্বীকার করি যে কিছু অটো উত্পাদিত সমান () পদ্ধতির টেস্টিংয়ের প্রয়োজন নাও হতে পারে তবে দুর্বল বাস্তবায়ন সহ আমার এতগুলি বাগ রয়েছে যা এটি আমাকে নার্ভাস করে তোলে। compareTo() equals()hashCode()
গ্লেনপিটারসন

1
@ গ্লেনপিটারসন সম্মত হন। আমার এক সহকর্মী এই উদ্দেশ্যে ইকুয়ালস্ ভিরিফায়ার লিখেছিলেন। দেখুন github.com/jqno/equalsverifier
Tohnmeister

@। না, আপনাকে এখনও অগ্রহণযোগ্য ইনপুট পরীক্ষা করতে হবে, এইভাবে লোকেরা সুরক্ষা কাজে লাগায়।
gbjbaanb

11

জেনারালাইজ করা যায় না।

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

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


এটি একটি সত্যই মূল্যবান দৃষ্টিভঙ্গি। পুরো উত্তর দেওয়ার জন্য প্রশ্নের আরও প্রসঙ্গ প্রয়োজন context
সিএলএফ

3

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

এই যে মানে:

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

(এটি কোড রিফ্যাক্টরিংয়ের জন্য অ্যাকাউন্ট করে না, যার লক্ষ্য পরবর্তী কোডগুলি লেখার জন্য কম সময় ব্যয় করা। এটি পরীক্ষার রিফ্যাক্টরিং দ্বারা ভারসাম্যযুক্ত, যার লক্ষ্য পরবর্তী পরীক্ষাগুলি লেখার জন্য কম সময় ব্যয় করা।)

হ্যাঁ আপনি যদি সত্যের পরে পরীক্ষাগুলি লেখার কথা বলছেন তবে আপনি আরও বেশি সময় ব্যয় করবেন:

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

আসলে আপনি কোড লেখার জন্য ব্যয় করবেন।

হ্যাঁ, এটি একটি প্রত্যাশিত পরিমাপ।


3

আমি এটি সবচেয়ে গুরুত্বপূর্ণ অংশ বলে মনে করি।

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

এই কারণেই এই পৃষ্ঠার অন্য উত্তরগুলির মধ্যে একটিতে উল্লেখ করা হয়েছে যে "কোর্সে" তারা 90% পরীক্ষা করেছিল, কারণ প্রত্যেককে তাদের উদ্দেশ্য সম্পর্কে সতর্কতা শিখতে হবে।

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


2

এটি অনেক লোকের জন্য হতে পারে তবে এটি নির্ভর করে।

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

  • ফলাফল এবং ইনপুট নির্ধারণ (পরামিতি)
  • নামকরণ অনুষ্ঠান
  • কাঠামো - যেখানে জিনিস রাখা।
  • সরল পুরানো চিন্তাভাবনা

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

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

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

এক পর্যায়ে, আমরা সকলেই কেবল কোডটি লিখতে সক্ষম হয়েছি যা এত ভাল। এটি ঠিক নয় যে আমি যদি কেবল একটি লেজার গাইড গাইড দেখতাম তবে আমি একটি বাড়ি তৈরি করতে পারি।


2

প্রকৃত কোডের চেয়ে পরীক্ষার সময় লেখার চেয়ে বেশি ব্যয় করা কি স্বাভাবিক?

হ্যাঁ, তাই কিছু সতর্কতা সহ।

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

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

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

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

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


0

প্রকৃত কোডের চেয়ে পরীক্ষার সময় লেখার চেয়ে বেশি ব্যয় করা কি স্বাভাবিক?

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.