কখনও কখনও ব্যক্তিগত ফাংশনগুলি কেবল কার্যক্ষমতার অভ্যন্তরীণ ইউনিটগুলিতে এখনও বহনযোগ্য হয় না। তাহলে কেন তাদের পরীক্ষা দিবেন না?


9

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

প্রদর্শন করার জন্যে:

এখানে চিত্র বর্ণনা লিখুন

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


মনে করুন নিম্নলিখিত ফাংশনগুলি সহ আমার একটি মডিউল রয়েছে (এটি একটি শ্রেণিও হতে পারে):

def public_func(a):
    b = _do_stuff(a)
    return _do_more_stuff(b)

_do_stuffএবং _do_more_stuffমডিউলটির 'ব্যক্তিগত' ফাংশনগুলি।

আমি ধারণাটি বুঝতে পারি যে আমাদের কেবলমাত্র সার্বজনীন ইন্টারফেসটি পরীক্ষা করা উচিত, বাস্তবায়নের বিশদটি নয়। তবে, জিনিসটি এখানে:

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

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



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

3
"আমার ব্যক্তিগত ফাংশন পরীক্ষা করা উচিত?" না, কখনও, কখনও নয় ever
ডেভিড আরনো

2
@ ডেভিড আর্নো কেন? ইন্টার্নাল পরীক্ষার বিকল্প কী? শুধু একীকরণের পরীক্ষা? বা আরও জিনিস প্রকাশ্যে করা? (যদিও আমার অভিজ্ঞতায় আমি বেশিরভাগ অভ্যন্তরীণ ক্লাসে পাবলিক পদ্ধতি পরীক্ষা করি, বেসরকারী পদ্ধতিতে না)
কোডসইনচওস

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

উত্তর:


14

পরীক্ষার প্রয়োজনীয়তা জনসাধারণ হওয়ার প্রয়োজনের মতো নয়।

নন তুচ্ছ কোডের এক্সপোজার নির্বিশেষে পরীক্ষার প্রয়োজন। অ-জনসাধারণের আচরণের পরীক্ষা করার দরকার নেই exist

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

এটি উত্তর নয়। ব্যক্তিগত সহায়ক ফাংশন তৈরি করতে ইচ্ছুক হন। এটি সর্বজনীন ইন্টারফেসের মাধ্যমে পরীক্ষা করুন যা এটি যতটা সম্ভব ব্যবহার করে।

যদি জনসাধারণের ইন্টারফেসের মাধ্যমে পরীক্ষার দ্বারা ব্যক্তিগত ফাংশনটি পর্যাপ্ত পরিমাণে অনুশীলন না করা হয় তবে ব্যক্তিগত ফাংশনটি বেশি কিছু করার সুযোগ দিচ্ছে।

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

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

অবশ্যই নাল ঠিক থাকতে পারে। এটি এখানে একটি উদাহরণ মাত্র। তবে আপনি যদি কিছু আশা করেন, তবে সেই প্রত্যাশাটি পরিষ্কার করুন make

এটি আপনার মনে যে পরীক্ষার ধরণ ছিল সে ধরণের নাও হতে পারে তবে আশা করি আপনি উপযুক্ত হলে ব্যক্তিগত সাহায্যকারী ফাংশন তৈরি করতে রাজি হবেন।

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

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


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

আমি বলব আমি অন্যান্য উত্তরদাতারা যারা এখানে উত্তর দিয়েছিলাম একই জিনিস জিজ্ঞাসা করছি :) আমি প্রত্যেকের মতামত শুনতে চাই।
আভিভ কোহন

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

1
"জনসাধারণের ইন্টারফেসের মাধ্যমে পরীক্ষা করা যদি ব্যক্তিগত ফাংশনটি পর্যাপ্ত পরিমাণে ব্যবহার না করে তবে ব্যক্তিগত ফাংশন অনেক কিছু করার অনুমতি দেওয়ার চেষ্টা করছে for
ক্রিস ওয়েলশ

7

সংক্ষিপ্ত উত্তর: না

দীর্ঘ উত্তর: হ্যাঁ, তবে আপনার শ্রেণীর পাবলিক 'এপিআই' এর মাধ্যমে

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

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


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


হাই, আপনার উত্তরের জন্য ধন্যবাদ :) দয়া করে প্রশ্নটি আবার পড়ুন, আমি স্পষ্ট করার জন্য সম্পাদনা করেছি।
আভিভ কোহন

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

আমি বলব আমি অন্যান্য উত্তরদাতারা যারা এখানে উত্তর দিয়েছিলাম একই জিনিস জিজ্ঞাসা করছি :) আমি প্রত্যেকের মতামত শুনতে চাই।
আভিভ কোহন

5

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

def public_func(a):
    b = _do_stuff(a)
    return _do_more_stuff(b)

যদি আপনার কেবলমাত্র পরীক্ষার একটি সিরিজ public_funcথাকে তবে আপনি যদি এটিতে আবার লিখেন:

def public_func(a):
    b = _do_all_the_new_stuff(a)
    return _do_all_the_old_stuff(b)

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

এটি সমস্ত ভাল জিনিস: স্ট্যাটিক পাবলিক এপিআই; ভাল encapsulated অভ্যন্তরীণ কর্ম; এবং শক্ত পরীক্ষা।

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

এটি একটি খারাপ জিনিস: একটি পরিবর্তনশীল এপিআই; অনাবৃত অভ্যন্তরীণ কাজ শক্তভাবে পরীক্ষায় মিলিত; এবং ভঙ্গুর পরীক্ষা যা বাস্তবায়নে পরিবর্তনগুলি করা মাত্রই পরিবর্তন হয়।

সুতরাং না, ব্যক্তিগত ফাংশন পরীক্ষা করবেন না। কখনো।


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

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

আপনি যা সত্যই বিতর্ক করছেন তা হ'ল আপনার ব্যক্তিগত কাজ করা উচিত নয়।
রবার্ট হার্ভে

1
@ অভিভকোহন তারা পরীক্ষার পরোয়ানা দেওয়ার পক্ষে যথেষ্ট বড়, এই ক্ষেত্রে তারা তাদের নিজস্ব ফাইল পাওয়ার জন্য যথেষ্ট বড়; বা এগুলি এত ছোট যে আপনার আলাদা করে পরীক্ষা করার দরকার নেই। তাহলে এটি কোনটি?
ডোভাল

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