কীভাবে ইউনিট পরীক্ষার প্রাইভেট পদ্ধতিতে প্রয়োজনীয়তা এড়ানো যায়


15

আমি জানি আপনার ব্যক্তিগত পদ্ধতি পরীক্ষা করার কথা নয়, এবং যদি মনে হয় আপনার এটির প্রয়োজন আছে তবে সেখানে একটি ক্লাস থাকতে পারে waiting

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

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

আমি কি পাগল?


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

উত্তর:


24

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

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

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

সুতরাং - আপনার ব্যক্তিগত পদ্ধতিগুলি উপহাস করবেন না। আপনি যে কার্যকারিতা সরবরাহ করেন তার ভাল কভারেজ দেওয়ার জন্য আপনার যা পরীক্ষা করতে হবে তা বুঝতে তাদের ব্যবহার করুন। এটি ইউনিট পরীক্ষা পর্যায়ে বিশেষত সত্য।


1
"আপনার ব্যক্তিগত পদ্ধতিগুলিকে উপহাস করবেন না" হ্যাঁ, আমি পরীক্ষার বিষয়টি বুঝতে পারি, আপনি যখন তাদের নিয়ে ঠাট্টা করছেন তখন আপনি সূক্ষ্ম সূক্ষ্ম রেখাটি পাগল হয়ে যেতে পারেন
ইভান

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

8
@ ফ্রানস্যাভিলানো আপনি যদি এতটা বাজি বা ঠাট্টা-বিদ্রূপ করতে হয় তবে আমি আপনার সামগ্রিক নকশাটি দেখব। কিছু মনে হচ্ছে।
টমাস ওয়েন্স

একটি কোড কভারেজ সরঞ্জাম এটিতে সহায়তা করে।
অ্যান্ডি

5
@ ফ্রানসিভিলানো: একটি শ্রেণীর জন্য অনেকগুলি ভাল কারণ নেই যা প্রচুর নির্ভরতা রাখতে কোনও কাজ করে। আপনার যদি প্রচুর নির্ভরতা থাকে তবে আপনার সম্ভবত probablyশ্বরের বর্গ রয়েছে।
হাঁসকে মুগিং করা হচ্ছে

4

আমি মনে করি এটি খুব খারাপ ধারণা।

ব্যক্তিগত সদস্যদের ইউনিট পরীক্ষা তৈরির ক্ষেত্রে সমস্যাটি হ'ল এটি পণ্য জীবনচক্রের সাথে খারাপভাবে ফিট করে।

এই পদ্ধতিগুলিকে ব্যক্তিগত করার জন্য আপনি যে কারণটি বেছে নিয়েছেন তা হ'ল তারা আপনার ক্লাসগুলি যা করার চেষ্টা করছেন তার কেন্দ্রিক নয় - আপনি কীভাবে বর্তমানে এই কার্যকারিতাটি বাস্তবায়িত করেন তার জন্য কেবল সহায়ক। আপনি যেমন রিফ্যাক্টর হিসাবে, সেই ব্যক্তিগত বিবরণগুলি সম্ভবত প্রার্থীদের পরিবর্তন হতে পারে এবং রিফ্যাক্টরিংয়ের সাথে তখন ঘর্ষণ সৃষ্টি করবে।

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

আমি তোমাকে পরামর্শ দিচ্ছি:

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

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


6
আমি একমত নই আইএমও, এটি ইন্টিগ্রেশন পরীক্ষার জন্য 100% সঠিক। তবে ইউনিট পরীক্ষার সাথে জিনিসগুলি পৃথক; ইউনিট টেস্টিংয়ের লক্ষ্যটি হ'ল একটি বাগ কোথায় রয়েছে তা নির্ধারণ করা, যথেষ্ট সংকীর্ণ যাতে আপনি এটি দ্রুত সমাধান করতে পারেন। আমি নিজেকে এই পরিস্থিতিতে প্রায়শই খুঁজে পাই: আমার খুব কম পাবলিক পদ্ধতি রয়েছে কারণ এটি আমার ক্লাসের মূল মূল্য (যেমন আপনি বলেছিলেন যে একটি করা উচিত)। যাইহোক, আমি 400 জন লাইন পদ্ধতিও এড়ানো, না জনসাধারণ বা ব্যক্তিগত private সুতরাং আমার কয়েকটি পাবলিক পদ্ধতি দশটি ব্যক্তিগত পদ্ধতির সাহায্যে কেবল তাদের লক্ষ্য অর্জন করতে পারে। "তাড়াতাড়ি এটি ঠিক করতে" খুব বেশি কোড রয়েছে। আমাকে ডিবাগার ইত্যাদি শুরু করতে হবে ..
মার্সাতাতো

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

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

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

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

3

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

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

আপনি কেন পরীক্ষা করতে চান না তার প্রধান কারণ private methodsহ'ল তারা বাস্তবায়ন বিশদ এবং আপনি রিফ্যাক্টরিংয়ের সময় এগুলি পরিবর্তন করতে পারেন (কার্যকারিতা পরিবর্তন না করে OO- নীতি প্রয়োগ করে আপনার কোডটি উন্নত করুন)। এটি হ'ল ঠিক যখন আপনি চান না আপনার ইউনিটসেটগুলি পরিবর্তন হয় যাতে তারা গ্যারান্টি দিতে পারে যে আপনার সিইটির আচরণটি রিফ্যাক্টরিংয়ের সময় পরিবর্তন হয়নি।

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

আমি সাধারণত বিপরীত অভিজ্ঞতা অর্জন করি: ক্লাসগুলি যত কম হবে (তাদের কম দায়িত্ব) তাদের কম নির্ভরতা কম, এবং লেখার জন্য এবং পড়ার পক্ষে উভয়ই ইউনিটেটস are

আদর্শভাবে আপনি আপনার ক্লাসগুলিতে বিমূর্ত প্যাটার্নের একই স্তরের প্রয়োগ করেন । এর অর্থ হল আপনার ক্লাসগুলি হয় কিছু ব্যবসায়ের যুক্তি সরবরাহ করে (পছন্দসই "খাঁটি ফাংশন" হিসাবে কেবলমাত্র তার নিজস্ব পরামিতিগুলি রক্ষণ না করেই তাদের প্যারামিটারগুলিতে কাজ করে) (এক্স) বা অন্যান্য বস্তুগুলিতে কল পদ্ধতিগুলি একই সাথে নয় both

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


1

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

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

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

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

এই পরিস্থিতিতে আপনি যদি ব্যক্তিগত পদ্ধতিগুলির পরীক্ষা অন্তর্ভুক্ত করেন তবে কি হবে? স্পষ্টতই এটি কোনও অর্থবোধ করে না।

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


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

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

1

এই জাতীয় প্রশ্নের উত্তর দেওয়ার আগে, আপনি আসলে কী অর্জন করতে চান তা সিদ্ধান্ত নেওয়া উচিত।

আপনি কোড লিখুন। আপনি আশা করেন যে এটি তার চুক্তিটি পূরণ করেছে (অন্য কথায়, এটি যা করার কথা বলেছিল তা করে does

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

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

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

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


0

হ্যাঁ, আপনি পাগল .... একটি ফোকাস পছন্দ করুন!

ব্যক্তিগত পদ্ধতি পরীক্ষা করার কয়েকটি উপায় রয়েছে যার মধ্যে কয়েকটি ভাষা নির্ভর।

  • প্রতিফলন! নিয়ম ভাঙার জন্য তৈরি করা হয়!
  • তাদের সুরক্ষিত করুন, উত্তরাধিকারী করুন এবং ওভাররাইড করুন
  • বন্ধু / ইন্টার্নালভিজিবলটো ক্লাস

সামগ্রিকভাবে আপনি যদি ব্যক্তিগত পদ্ধতি পরীক্ষা করতে চান তবে আপনি সম্ভবত এগুলি নির্ভরতা এবং পরীক্ষা / ইনজেকশনের উপর তাদের সরকারী পদ্ধতিতে সরানোতে চান।


আমি জানি না, আমার দৃষ্টিতে আপনি ব্যাখ্যা করেছেন যে এটি একটি ভাল ধারণা নয় তবে প্রশ্নের উত্তরটি অবিরত রেখেছেন
লিয়্যাথ

আমি ভেবেছিলাম আমার সমস্ত ঘাঁটি কভার হয়েছে :(
ইভান

3
আমি উত্সাহিত করেছি, কারণ আপনার ব্যক্তিগত সহায়ক সহায়তার পদ্ধতিগুলি কেবল তাদের পরীক্ষার জন্য জনসাধারণের API এ প্রকাশ করার ধারণাটি পাগল, এবং আমি সবসময়ই ভেবেছি।
রবার্ট হার্ভে

0

ব্যবহারিক থাকুন। উদাহরণস্বরূপ রাষ্ট্রের স্থিতি স্থাপনের মাধ্যমে এবং একটি সরকারী পদ্ধতির পরামিতিগুলির ক্ষেত্রে যেমন কেসগুলি ঘটে থাকে সেগুলি দ্বারা ব্যক্তিগত ক্ষেত্রে বিশেষ কেসগুলি পরীক্ষা করা প্রায়শই খুব জটিল।

এই "ব্যক্তিগত" পদ্ধতিগুলি পরীক্ষা করার জন্য আমি একটি অতিরিক্ত internalঅ্যাক্সেসর (পতাকা InternalsVisibleToপরীক্ষার সমাবেশের সাথে একসাথে ) যুক্ত করেছি clearlyDoSomethingForTesting(parameters)

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

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