ইউনিট পরীক্ষা করার সময় সি # "অভ্যন্তরীণ" অ্যাক্সেস মডিফায়ার


469

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


1
উল্লেখযোগ্যভাবে উল্লেখ করা - আপনি প্রায়শই পদ্ধতিগুলির System.Diagnostics.Debug.Assert()মধ্যে ব্যবহার করে আপনার অভ্যন্তরীণ পদ্ধতিগুলির পরীক্ষা করার ইউনিটের প্রয়োজন এড়াতে পারেন ।
মাইক মেরিনোভস্কি

উত্তর:


1195

অভ্যন্তরীণ ক্লাসগুলির পরীক্ষা করা দরকার এবং এখানে একটি অ্যাসেমব্রি বৈশিষ্ট্য রয়েছে:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

প্রকল্পের তথ্য ফাইলে এটি যুক্ত করুন, যেমন Properties\AssemblyInfo.cs


70
এটি পরীক্ষার অধীনে প্রকল্পে যুক্ত করুন (উদাহরণস্বরূপ বৈশিষ্ট্যসমূহ \ এসেম্বলিআইএনফো-তে)। "মাই টেস্টস" টেস্ট সমাবেশ হবে।
এরিকশাফার

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

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

31
ইন এবং #if DEBUG, #endifব্লক মোড়ানো কেবলমাত্র ডিবাগ বিল্ডগুলিতে এই বিকল্পটিকে সক্ষম করবে।
দ্য রিয়েল এডওয়ার্ড কুলেন

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

127

আপনি যদি ব্যক্তিগত পদ্ধতিগুলি পরীক্ষা করতে চান তবে নেমস্পেসে PrivateObjectএবং দেখুন । তারা প্রয়োজনীয় প্রতিবিম্ব কোডের চারপাশে মোড়ক ব্যবহার করা সহজ অফার করে।PrivateTypeMicrosoft.VisualStudio.TestTools.UnitTesting

ডক্স: প্রাইভেটটাইপ , প্রাইভেটঅবজেক্ট

VS2017 এবং 2019 এর জন্য, আপনি এমএসটিস্ট.টেষ্টফ্রেমওয়ার্ক নুগেট ডাউনলোড করে এগুলি সন্ধান করতে পারেন


15
ভোট নেওয়ার সময় একটি মন্তব্য দয়া করে। ধন্যবাদ।
ব্রায়ান রাসমুসেন

35
এই উত্তরটি মূ .়ভাবে ভোট দেওয়া। এটি একটি নতুন সমাধান এবং সত্যিই ভাল যা ইতিপূর্বে উল্লিখিত হয়নি নির্দেশ করে।
ইগনাসিও সোলার গার্সিয়া

স্পষ্টতই, .N2 2.0 বা আরও নতুন অ্যাপ্লিকেশনটিকে লক্ষ্য করে দেখানোর জন্য টেস্টফ্রেমওয়ার্কটি ব্যবহার করার ক্ষেত্রে কিছু সমস্যা আছে: github.com/Mic
জনি উ

41

এরিকের উত্তরে যুক্ত করে আপনি এটি csprojফাইলটিতেও কনফিগার করতে পারেন :

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>MyTests</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

বা যদি আপনার পরীক্ষার জন্য প্রতি প্রকল্পের জন্য একটি পরীক্ষার প্রকল্প হয়, আপনি নিজের Directory.Build.propsফাইলে এই জাতীয় কিছু করতে পারেন :

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>$(MSBuildProjectName).Test</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

দেখুন: https://stackoverflow.com/a/49978185/1678053
উদাহরণ: https://github.com/gldraphael/evlog/blob/master/Directory.Build.prop#L5-L12


2
এটি সেরা উত্তর ইমো হওয়া উচিত। অন্যান্য সমস্ত উত্তরগুলি খুব পুরানো are
mBrice1024

12

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

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

একটি বিষয় বিবেচনা করার জন্য এটি হতে পারে "ফরস্টেস্ট" প্রত্যয়:

internal void DoThisForTest(string name)
{
    DoThis(name);
}

private void DoThis(string name)
{
    // Real implementation
}

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


2
যদি পদ্ধতিটি অভ্যন্তরীণ হয় তবে এটি কি পরীক্ষার সমাবেশ থেকে এর ব্যবহারকে বিরত রাখবে না?
র‌্যাল্ফ শিলিংটন

7
আমি মাঝে মাঝে ForTestপন্থাটি ব্যবহার করি তবে আমি সর্বদা এটি মরা কুশ্রী দেখতে পাই (এমন কোড যুক্ত করা যা উত্পাদন ব্যবসায়ের যুক্তি হিসাবে কোনও প্রকৃত মান দেয় না)। সাধারণত আমি দেখতে পেলাম যে আমাকে দৃষ্টিভঙ্গিটি ব্যবহার করতে হয়েছে কারণ ডিজাইনটি কিছুটা দুর্ভাগ্যজনক (যেমন পরীক্ষার মধ্যে
সিঙ্গেলটন

1
এটি হ্রাস করার জন্য প্রলুব্ধ - এই হ্যাক এবং কেবল ব্যক্তিগত পরিবর্তে শ্রেণি অভ্যন্তরীণ করার মধ্যে পার্থক্য কী? ভাল, কমপক্ষে সংকলন শর্তসাপেক্ষে। তারপর এটি সত্যিই অগোছালো হয়ে যায়।
সিএডি

6
@ ক্যাডব্লোক: আপনি কী ব্যক্তিগতটিকে না বলে পদ্ধতিটি অভ্যন্তরীণ করে তোলেন ? পার্থক্যটি হ'ল এটি সুস্পষ্ট যে আপনি সত্যই এটি ব্যক্তিগত থাকতে চান । আপনার প্রোডাকশন কোডবেসের মধ্যে এমন কোনও কোড যা একটি পদ্ধতিকে কল করে ForTestতা স্পষ্টতই ভুল, অন্যদিকে আপনি যদি কেবল পদ্ধতিটি অভ্যন্তরীণ করেন তবে মনে হয় এটি ব্যবহার করা ভাল fine
জন স্কিটি

2
@ কেএডব্লোক: আপনি আঞ্চলিক ক্লাস, আইএমও ব্যবহার করার মতো একই ফাইলটিতে কেবল একটি বিল্ডের মধ্যে পৃথক পদ্ধতি বাদ দিতে পারেন। এবং যদি আপনি না যে কি, এটা প্রস্তাব করে যে আপনি আপনার মুক্তি বিল্ড, যা আমার কাছে একটি খারাপ ধারণা মত শোনাচ্ছে বিরুদ্ধে আপনার পরীক্ষা না চালাচ্ছেন।
জন স্কিটি

11

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

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

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


3

আমি ব্যবহার করছি Dotnet 3.1.101এবং .csprojআমার জন্য কাজ করা সংযোজনগুলি হ'ল:

<PropertyGroup>
  <!-- Explicitly generate Assembly Info -->
  <GenerateAssemblyInfo>true</GenerateAssemblyInfo>
</PropertyGroup>

<ItemGroup>
  <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
  <_Parameter1>MyProject.Tests</_Parameter1>
  </AssemblyAttribute>
</ItemGroup>

আশা করি এটি কাউকে সাহায্য করবে!


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