ইউনিট পরীক্ষায় কোডের মান?


23

ইউনিট টেস্টগুলি লেখার সময়, কোডটি ভাল মানের এবং পাঠযোগ্যতার জন্য অতিরিক্ত সময় ব্যয় করা কি উপযুক্ত?

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


5
পাঠযোগ্যতা এবং রক্ষণাবেক্ষণের ইউনিট পরীক্ষার প্রাথমিক ফোকাস হওয়া দরকার।
EL Yusubov

2
টেস্টগুলিও কোড!
অনুদান পালিন

এটি গ্রাহকদের কাছে না পেলেও এটি এখনও আপনার প্রকল্পের অংশ। সেই অনুযায়ী চিকিত্সা করুন।

উত্তর:


11

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

লিমিটার অফ ডিমিটারের লঙ্ঘন অবশ্যই সেই কারণে আপনার ইউনিট পরীক্ষাগুলিতে এবং অন্য 2 জন যা আমার মনে আসে:

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

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

যাইহোক, যখন আপনি বলেন

দ্রুত লেখার জন্য এবং এতগুলি ভেরিয়েবল ব্যবহার না করার জন্য আমি প্রায়শই ডেমিটারের আইন ভঙ্গ করি।

আপনার লেখার সচেতন হওয়া উচিত

var grab = myDependency.Grab;
var something = grab.Something;
var very = something.Very;

very.Deep();

ডেমিটার বুদ্ধিমানের চেয়ে আসলে আর ভাল কিছু নয়

myDependency.Grab.Something.Very.Deep();

যদি সেটাই আপনি বোঝাতে চেয়েছিলেন


47

ইউনিট পরীক্ষার জন্য ভাল মানের কোড লেখার জন্য সময় ব্যয় করা একেবারেই মূল্যবান:

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

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


22

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

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

  • ইউনিট পরীক্ষাগুলি বগিও হতে পারে। কোডটি ভাল লেখা থাকলে ত্রুটিগুলি আরও দৃশ্যমান হয়।

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

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


12

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

সত্যই ইউনিটসেটগুলির একটি প্রত্যাশিত ফলাফল হওয়া উচিত; পদ্ধতি করুন; প্রকৃত ফলাফল পান; প্রকৃত ধরণের কাঠামোর বিরুদ্ধে পরীক্ষা প্রত্যাশিত যা লিখতে ও বুঝতে সহজ


1

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

এর অর্থ:

  • বিল্ডার ক্লাসে পরীক্ষার ডেটা বিল্ডিং নিষ্ক্রিয় করুন।
  • পৃথক assertion পদ্ধতিতে একাধিক assertions এক্সট্রাক্ট।
  • আপনার নামকরণে খুব সুনির্দিষ্ট হন। Assert.That(x4, Is.EqualTo(y16*2*SOME_VALUE), ASS_ERR_TXT_56)বেশিরভাগ পাঠকের কাছে খুব কম সংবেদন তৈরি করে।

চূড়ান্ত দিকে নিয়ে যাওয়া, পরীক্ষাগুলি লেখা যেতে পারে তাই তারা পড়তে এবং গদ্য হিসাবে প্রায় বুঝতে পারে are চূড়ান্ত পরীক্ষক সম্ভবত বলবেন যে 10 লাইনের বেশি লম্বা ইউনিট পরীক্ষা করা খারাপ bad


1

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

আপনার পরীক্ষায় এই যে কোনও একটি করুন:

  • সদৃশ কোড
  • পাঠযোগ্যতা হ্রাস করুন
  • টাইট কাপলিং
  • অস্থায়ী মিলন
  • উচ্চ চক্রীয় জটিলতা (প্রচুর নির্ভরতা)

এবং যখন পরিবর্তন দরকার হয় আপনি পুরো কাজের জন্য সজ্জিত হন।

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


0

এই ইউনিট পরীক্ষাগুলি "অস্থায়ী" কিনা তা নির্ভর করে। যদি

  1. পরীক্ষা ঘন ঘন ব্যবহৃত হবে;

  2. বিকাশকারীদের অন্যান্য বিকাশকারীদের দ্বারা লিখিত ইউনিট পরীক্ষার সাথে কাজ করতে হয়;

  3. বেশিরভাগ টেস্টিং ইউনিট টেস্ট দ্বারা করা হয়

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

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


(1) ইউনিট পরীক্ষাগুলি কখনই অস্থায়ী হয় না (২) এমনকি এটি আপনার নিজের জন্য হলেও এক মাসে (বা তার বেশি), আপনি সমস্ত বিবরণ মনে রাখবেন না, সুতরাং এটি সঠিকভাবে করা গুরুত্বপূর্ণ - এমনকি নিজের জন্যও
BЈовић
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.