ইউনিট টেস্টগুলি কি সত্যই ডকুমেন্টেশন হিসাবে ব্যবহৃত হয়?


22

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

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

সুতরাং প্রশ্নটি হল: ইউনিট টেস্টগুলি ডকুমেন্টেশন হিসাবে কখন ব্যবহৃত হয়? কমেন্টস সব কভার করে না? উত্স বর্ধনকারী দ্বারা? এবং এগুলি কীভাবে উদ্ভাসিত করবে যে দরকারী এবং প্রাসঙ্গিক হতে পারে যা ডকুমেন্টেশন নিজেই প্রকাশ করতে পারে না?


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

10
মন্তব্যগুলি ভুল হতে পারে।

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

3
আমি ইউনিট পরীক্ষা দেখেছি যা "ইউনিট পরীক্ষা-নিরীক্ষা" হিসাবে আরও বেশি বৈশিষ্ট্যযুক্ত। বাহ্যিক কারণগুলির উপর তাদের নির্ভরতা কেবল তাদের অকেজো করার জন্য তৈরি করেছিল। তারা খুব অস্পষ্ট ছিল। (হ্যাঁ, সেগুলি আরও ভাল হওয়ার জন্য আমার দীর্ঘমেয়াদী লক্ষ্য রয়েছে তবে আমি অন্যান্য জিনিসগুলিও করি ...)
ডোনাল ফেলো

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

উত্তর:


17

তারা কোনও নিখুঁত রেফারেন্স ডকুমেন্টেশন নয়

নোট করুন যে নীচের অনেকগুলি মন্তব্যগুলিতেও প্রযোজ্য, কারণ তারা কোডের সাথে সিঙ্কের বাইরে যেতে পারে, যেমন পরীক্ষার (যদিও এটি কম প্রয়োগযোগ্য)।

সুতরাং শেষ পর্যন্ত, কোড বোঝার সর্বোত্তম উপায় হ'ল পঠনযোগ্য কার্য কোড

যদি কিছুটা সম্ভব হয় এবং হার্ড-ওয়্যার লো-লেভেল কোড বিভাগগুলি বা বিশেষত কৌতুকপূর্ণ শর্তগুলি না লিখলে অতিরিক্ত ডকুমেন্টেশন গুরুত্বপূর্ণ ছিল।

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

তবে তারা এখনও একটি সহায়ক ডকুমেন্টেশন পরিপূরক

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

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

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

অঞ্চলসমূহ এবং বাগগুলিও খুব বেশি টেস্টের প্রয়োজন

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

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


আমি জিজ্ঞাসা করতে পারি কেন আমাকে নিম্নচাপ দেওয়া হয়েছিল? সেখানে আপনাকে কী টিকটিক করছে বা আপনি কীসের সাথে একমত নন?
হাইলেম

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

@ ম্যাডকিথভি: ধন্যবাদ আমি "পঠনযোগ্য এবং কার্যক্ষম কোড" এর জন্য আপডেট করেছি এবং কিছুটা উপরে ঠেলেছি।
হাইলেম

11

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

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


5

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

তারা ডকুমেন্টেশন প্রতিস্থাপন করা হয়? না।

তারা ডকুমেন্টেশন একটি দরকারী সংযোজন? হ্যাঁ।


4

আমি ইউনিট পরীক্ষা হিসাবে দেখছি:

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

কিছু প্রসারিত করার জন্য এগুলিকে একটি বিদ্যমান নথিপত্রের পরিপূরক হিসাবে দেখা যেতে পারে তবে ডকুমেন্টেশন হিসাবে নয়।


3

আমি আপনাকে অন্য একটি জিজ্ঞাসা করে আপনার প্রশ্নের উত্তর দিতে যাচ্ছি।

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

আপনি যখন ডকুমেন্টেশন হিসাবে ইউনিট পরীক্ষাগুলি ব্যবহার করবেন ঠিক সেই সময়।

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

আমি সন্দেহ করি যে কয়েকটি কারণের কারণে ইউনিট পরীক্ষা নথিপত্র হিসাবে ব্যবহার করার ঝোঁক নেয় না যদিও তারা আরও প্রচলিত ডকুমেন্টেশনের সেরা পরিপূরক হতে পারে:

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

2

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

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

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

একটি উদাহরণ: আপনার কাছে একটি পদ্ধতি মি আছে (a, b)যা একটি নির্দিষ্ট গণনা করে। পশ্চাদপটে সামঞ্জস্যতার প্রয়োজনীয়তার কারণে এটি অবশ্যই বিশেষ-ক্ষেত্রে ইনপুটগুলির a=0এবং অবশ্যই a=-1, কেবলমাত্র যদি bNUL হয়। এটিকে কোনও মন্তব্যে রাখা জটিল, ভারবস এবং জটিলতার পরে প্রয়োজনটি অপসারণ করা গেলে সম্ভবত বাসি হয়ে যায়।

যদি আপনি কিছু ইউনিট পরীক্ষা করে থাকেন যা এর আচরণটি পরীক্ষা করে m(0, NULL), m(-1, x)আপনি বেশ কয়েকটি সুবিধা পান:

  • সঠিক আচরণের বর্ণনাটি পরিষ্কার, ভুল বোঝাবুঝি হ্রাস পেয়েছে
  • লোকেরা কোনও মন্তব্যের বিপরীতে কোডটি পরিবর্তন করার সময় প্রয়োজনীয়তা উপেক্ষা করতে পারে না

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

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