আপনি কি সুবিধার্থে একই প্রকল্পে ইউনিট পরীক্ষা রেখেছেন বা এগুলি আলাদা কোনও সমাবেশে রেখেছেন?
যদি আপনি তাদের মতো আলাদা আলাদা সমাবেশে রাখেন তবে আমরা সমাধানে অনেকগুলি অতিরিক্ত প্রকল্প শেষ করব। কোডিং করার সময় এটি ইউনিট পরীক্ষার জন্য দুর্দান্ত তবে আপনি কীভাবে এই সমস্ত অতিরিক্ত সমাবেশগুলি ছাড়াই অ্যাপ্লিকেশনটি প্রকাশ করবেন?
উত্তর:
আমার মতে, ইউনিট পরীক্ষাগুলি উত্পাদন কোড থেকে পৃথক সমাবেশে স্থাপন করা উচিত। উত্পাদনের কোড হিসাবে একই অ্যাসেম্বলি বা অ্যাসেমব্লিতে ইউনিট পরীক্ষা দেওয়ার কয়েকটি মাত্র কনস এখানে রয়েছে:
আমি আসলে কোন উপকার সম্পর্কে জানি না। একটি অতিরিক্ত প্রকল্প (বা 10) থাকা কোনও শঙ্কা নয়।
সম্পাদনা করুন: বিল্ড এবং শিপিংয়ের আরও তথ্য
আমি আরও সুপারিশ করব যে কোনও স্বয়ংক্রিয় বিল্ড প্রক্রিয়া উত্পাদন এবং ইউনিট পরীক্ষা বিভিন্ন স্থানে রাখে। আদর্শভাবে, ইউনিট পরীক্ষা বিল্ড প্রক্রিয়াটি কেবল তখন চালিত হয় যদি প্রোডাকশন কোড তৈরি হয় এবং পণ্য ফাইলগুলি ইউনিট পরীক্ষার ডিরেক্টরিতে অনুলিপি করে। এইভাবে এটি করার ফলে প্রকৃত বিটগুলি শিপিং ইত্যাদির জন্য পৃথক হয়ে যায়। অতিরিক্তভাবে, নির্দিষ্ট ডিরেক্টরিতে সমস্ত পরীক্ষায় এই সময়ে স্বয়ংক্রিয় ইউনিট পরীক্ষা চালানো মোটামুটি নগণ্য।
সংক্ষিপ্তসার হিসাবে, এখানে একটি বিট এবং অন্যান্য ফাইলগুলির প্রতিদিনের বিল্ডিং এবং পরীক্ষার এবং শিপিংয়ের সাধারণ ধারণাটি রয়েছে:
#if। আপনার সিআই সফ্টওয়্যার স্ক্রিপ্টগুলিতে সংকলক কমান্ড-লাইন প্যারামিটার ব্যবহার করে এই কাস্টম প্রতীকটি টগল করা যেতে পারে। এমএসডিএন.মাইক্রোসফটকম /en-us/library/4y6tbswk.aspx দেখুন ।
পৃথক প্রকল্প, কিন্তু একই সমাধানে। (আমি টেস্ট এবং উত্পাদন কোডের জন্য পৃথক সমাধান সহ পণ্যগুলিতে কাজ করেছি - এটি ভয়াবহ। আপনি সর্বদা দুজনের মধ্যে স্যুইচ করছেন))
পৃথক প্রকল্পের কারণগুলি অন্যরা বলেছেন। নোট করুন যে আপনি যদি ডেটা-চালিত পরীক্ষাগুলি ব্যবহার করে থাকেন, তবে আপনি যদি পরীক্ষামূলকভাবে সমাবেশে পরীক্ষাগুলি অন্তর্ভুক্ত করেন তবে আপনি যথেষ্ট পরিমাণে ফোলা শেষ করতে পারেন।
আপনি উৎপাদন কোডের অভ্যন্তরীণ সদস্যদের অ্যাক্সেস প্রয়োজন করেন, ব্যবহার InternalsVisibleTo ।
[assembly:InternalsVisibleTo("UnitTestProjectName")]জন্য এটি আপনার প্রকল্পের AssemblyInfo.csফাইলটিতে যুক্ত করা।
প্রোডাকশন কোড সহ পরীক্ষা নিযুক্ত করার বিষয়ে আমি বারবার আপত্তি বুঝতে পারি না। আমি একটি ছোট মাইক্রোক্যাপে একটি দলকে নেতৃত্ব দিয়েছি (14 থেকে 130 জন বেড়েছে)। আমাদের কাছে অর্ধ-ডজন বা তাই জাভা অ্যাপ্লিকেশন ছিল এবং আমরা নির্দিষ্ট জায়গায় পরীক্ষা চালানোর জন্য ক্ষেত্রের মধ্যে পরীক্ষা স্থাপন করা অত্যন্ত মূল্যবান বলে মনে করিমেশিন যা অস্বাভাবিক আচরণ প্রদর্শন করে। মাঠে এলোমেলো সমস্যা দেখা দেয় এবং শূন্য খরচের সাথে রহস্যের জন্য কয়েক হাজার ইউনিট পরীক্ষা নিক্ষেপ করতে সক্ষম হওয়া অমূল্য ছিল এবং প্রায়শই কয়েক মিনিটের মধ্যে সমস্যাগুলি নির্ণয় করা হয় ... ইনস্টলেশন সমস্যা, ফ্ল্যাঙ্ক র্যাম সমস্যা, মেশিন-নির্দিষ্ট সমস্যা, ফ্লকি নেটওয়ার্ক সমস্যা সহ, ইত্যাদি ইত্যাদি আমার মনে হয় ক্ষেত্রের মধ্যে পরীক্ষা দেওয়া অবিশ্বাস্যরূপে মূল্যবান। এছাড়াও, এলোমেলো সমস্যা এলোমেলো সময়ে পপ আপ হয় এবং ইউনিট টেস্টগুলি ইতিমধ্যে সেখানে বসে একটি মুহুর্তের বিজ্ঞপ্তিতে মৃত্যুদন্ড কার্যকর করার জন্য অপেক্ষা করা ভাল। হার্ড-ড্রাইভের জায়গাটি সস্তা। ঠিক যেমন আমরা ডেটা এবং ফাংশনগুলি একসাথে রাখার চেষ্টা করি (ওও ডিজাইন), আমি মনে করি কোড এবং পরীক্ষাগুলি একসাথে রাখার জন্য মূলত মূল্যবান কিছু রয়েছে (ফাংশন + টেস্ট যা ফাংশনগুলিকে বৈধতা দেয়)।
আমি একই প্রকল্পে আমার পরীক্ষাগুলি সি # /। নেট / ভিজ্যুয়াল স্টুডিও ২০০৮-তে রাখতে চাই, তবে আমি এখনও এটি অর্জনের জন্য তদন্ত করতে পারি নি।
FooTest.cs হিসাবে একই প্রকল্পে Foo.cs রাখার একটি বড় সুবিধা হ'ল বিকাশকারীরা ক্রমাগত স্মরণ করিয়ে দেওয়া হয় যখন কোনও শ্রেণি একটি ভাইবোন পরীক্ষা মিস করে না! এটি আরও ভাল পরীক্ষা-চালিত কোডিং অনুশীলনকে উত্সাহ দেয় ... গর্তগুলি আরও স্পষ্ট।
আরও ভাল এনক্যাপসুলেশন অর্জনের জন্য কোড হিসাবে একই প্রকল্পে ইউনিট পরীক্ষা করুন।
আপনি সহজেই অভ্যন্তরীণ পদ্ধতিগুলি পরীক্ষা করতে পারেন, যার অর্থ আপনি অভ্যন্তরীণ হওয়া উচিত এমন পদ্ধতিগুলি সর্বজনীন করে তুলবেন না।
এছাড়াও আপনি যে কোডটি লিখছেন তার কাছাকাছি ইউনিট পরীক্ষা করে রাখা খুব সুন্দর। আপনি যখন কোনও পদ্ধতি লিখেন আপনি সহজেই সম্পর্কিত ইউনিট পরীক্ষাগুলি আবিষ্কার করতে পারেন কারণ এটি একই প্রকল্পে রয়েছে। আপনি যখন ইউনিট টেস্ট অন্তর্ভুক্ত এমন কোনও অ্যাসেমব্লি তৈরি করেন, ইউনিট টেস্টের যে কোনও ত্রুটি আপনাকে একটি সংকলক দেবে, সুতরাং আপনাকে কেবলমাত্র বিল্ডিংয়ের জন্য আপনার ইউনিটেস্টকে আপ-টু-ডেট রাখতে হবে। একটি পৃথক প্রকল্পে ইউনিটেট থাকা, কিছু বিকাশকারীদের ইউনিট-প্রকল্পের বিল্ডিং ভুলে যেতে পারে এবং কিছুক্ষণের জন্য ভাঙা পরীক্ষার অনুপস্থিত হতে পারে।
এবং আপনি সংকলন ট্যাগ (যদি # ডেবেগ) ব্যবহার করে উত্পাদন কোড থেকে ইউনিট পরীক্ষাগুলি সরিয়ে ফেলতে পারেন।
স্বয়ংক্রিয় ইন্টিগ্রেশন টেস্টগুলি (iNUnit বানানো) একটি পৃথক প্রকল্পে হওয়া উচিত কারণ সেগুলি কোনও একক প্রকল্পের নয়।
Release বিল্ডে এবং কয়েকটি "হাইসেনব্যাগস" এর মধ্যে পড়তে পারে।
InternalsVisibleToআপনাকে পৃথক পরীক্ষার প্রকল্প থেকে অভ্যন্তরীণ পদ্ধতিগুলি পরীক্ষা করতে দেয়
Debug, Approvalএবং Release; এবং সমস্ত মুক্তি অপ্টিমাইজেশান সহ অনুমোদনের সংকলন। এছাড়াও, সাধারণত ইউনিট পরীক্ষাগুলি প্রথম স্থানে (আমার অভিজ্ঞতাতে) হিজেনবगগুলি সনাক্তকরণে দুর্দান্ত নয়। এগুলির জন্য আপনার নির্দিষ্ট ইন্টিগ্রেশন রিগ্রেশন টেস্টগুলির প্রবণতা রয়েছে - এবং আপনি সেইগুলি পাশাপাশি রাখতে পারেন।
টাইপস্ক্রিপ্ট প্রকল্পগুলিতে কিছু সময় ব্যয় করার পরে, যেখানে টেস্টগুলি কোডগুলি টেস্টিংয়ের পাশাপাশি প্রায়শই একটি ফাইলে রাখা হয়, সেগুলি আলাদা রাখার চেয়ে আমি এই পদ্ধতির পছন্দ করতে বাড়িয়েছিলাম:
সুতরাং যখন আমি একটি নতুন। নেট কোর প্রকল্পটি সম্প্রতি শুরু করেছি তখন আমি দেখতে চেয়েছিলাম চূড়ান্ত প্রকাশের সাথে পরীক্ষাগুলি বা পরীক্ষা অ্যাসেম্বলিকে শিপিং না করে কোনও সি # প্রকল্পে এই কাঠামোর অনুকরণ করা সম্ভব কিনা কিনা।
প্রকল্পের ফাইলে নিম্নলিখিত লাইনগুলি লাগানো এখন পর্যন্ত ভালভাবে কাজ করছে বলে মনে হচ্ছে:
<ItemGroup Condition="'$(Configuration)' == 'Release'">
<Compile Remove="**\*.Tests.cs" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' != 'Release'">
<PackageReference Include="nunit" Version="3.11.0" />
<PackageReference Include="NUnit3TestAdapter" Version="3.12.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
</ItemGroup>উপরেরটি নিশ্চিত করে যে Release কনফিগারেশনে সমস্ত ফাইলের নাম নিশ্চিত করে*.Tests.cs সংকলন থেকে বাদ দেওয়া হয়েছে এবং প্রয়োজনীয় ইউনিট পরীক্ষার প্যাকেজ রেফারেন্সগুলি সরানো হয়েছে।
যদি আপনি এখনও তাদের মুক্তির কনফিগারেশনে ক্লাস পরীক্ষা করতে সক্ষম হতে চান তবে আপনি কেবল নতুন জাতীয় কনফিগারেশন তৈরি Releaseকরতে পারেন যা কিছু বলা হয়ReleaseContainingTests ।
আপডেট: কিছুক্ষণ এই কৌশলটি ব্যবহার করার পরেও আমি খুঁজে পেয়েছি পরীক্ষাগুলি (এবং অন্যান্য জিনিসগুলি) এক্সপ্লোরার ফলকে আরও কিছুটা দাঁড় করানোর জন্য ভিএস কোডে আপনার আইকনগুলি কাস্টমাইজ করা সহায়ক:
এটি করার জন্য, উপাদান আইকন থিম এক্সটেনশনটি ব্যবহার করুন এবং আপনার ভিএস কোড পছন্দসমূহ JSON এ নিম্নলিখিতগুলির মতো কিছু যুক্ত করুন:
"material-icon-theme.files.associations": {
"*.Tests.cs": "test-jsx",
"*.Mocks.cs": "merlin",
"*.Interface.cs": "yaml",
}আমার ইউনিট পরীক্ষা সর্বদা একটি পৃথক প্রকল্পে যায়। আসলে, আমার সমাধানে আমার প্রতিটি প্রকল্পের জন্য একটি পৃথক পরীক্ষার প্রকল্প রয়েছে যা এটির সাথে চলে along পরীক্ষার কোডটি অ্যাপ্লিকেশন কোড নয় এবং এটির সাথে মিলিত হওয়া উচিত নয়। তাদের পৃথক প্রকল্পে রাখার একটি সুবিধা - কমপক্ষে টেস্টড্রিভন.নেট ব্যবহার করে - তা হচ্ছে আমি কোনও পরীক্ষার প্রকল্পে ডান ক্লিক করতে পারি এবং সেই প্রকল্পের সমস্ত পরীক্ষা চালাতে পারি, এক ক্লিকে অ্যাপ্লিকেশন কোডের একটি সম্পূর্ণ লাইব্রেরি পরীক্ষা করে testing
যদি নুনিট কাঠামো ব্যবহার করা হয়, একই প্রকল্পে পরীক্ষা দেওয়ার অতিরিক্ত কারণ রয়েছে। ইউনিট পরীক্ষার সাথে মিশ্রিত উত্পাদন কোডের নিম্নলিখিত উদাহরণটি বিবেচনা করুন:
public static class Ext
{
[TestCase(1.1, Result = 1)]
[TestCase(0.9, Result = 1)]
public static int ToRoundedInt(this double d)
{
return (int) Math.Round(d);
}
}এখানে ইউনিট পরীক্ষাগুলি পরীক্ষিত কোডের ডকুমেন্টেশন এবং স্পেসিফিকেশন হিসাবে কাজ করে। স্বতন্ত্র-ডকুমেন্টিংয়ের এই প্রভাবটি কীভাবে অর্জন করতে হয় তা আমি পৃথক প্রকল্পে অবস্থিত পরীক্ষাগুলির সাথে জানি না। এই পরীক্ষার কেসগুলি দেখতে ফাংশনের ব্যবহারকারীর পরীক্ষার জন্য অনুসন্ধান করতে হবে, এটি অসম্ভব is
আপডেট : আমি জানি যে TestCaseগুণাবলীর এ জাতীয় ব্যবহারের বিষয়টি নুনিটের বিকাশকারীরা করেননি, তবে কেন নয়?
আমি একই প্রকল্প এবং বিভিন্ন প্রকল্পের মধ্যে ওঠানামা করি।
যদি আপনি পরীক্ষার কোডটি উত্পাদন কোড দিয়ে প্রকাশ করে একটি লাইব্রেরি প্রকাশ করেন তবে এটি একটি সমস্যা, অন্যথায় আমি দেখতে পাই এটি সাধারণত হয় না (যদিও আপনি চেষ্টা করার আগে একটি দৃ psych় মানসিক বাধা রয়েছে)।
একই প্রকল্পে পরীক্ষা দেওয়ার সময় আমি পরীক্ষাগুলি এবং তাদের পরীক্ষিত কোডের মধ্যে স্যুইচ করা সহজ এবং তাদের চারপাশে রিফ্যাক্টর / সরানো আরও সহজ মনে করি।
আমি তাদের আলাদা প্রকল্পে রেখেছি। সমাবেশের নামটি আমাদের জন্য একটি সাধারণ নিয়ম হিসাবে নামস্থানগুলিকে আয়না দেয়। সুতরাং যদি Company.Product.Feature.sln নামে একটি প্রকল্প থাকে তবে এর Company.Product.Feature.dll এর একটি আউটপুট (সমাবেশ নাম) রয়েছে। পরীক্ষার প্রকল্পটি হ'ল Company.Product.Feature.Tests.sln, উত্পাদনকারী Company.Product.Feature.Tests.dll।
আপনি তাদের একক সমাধানে সেরা রাখছেন এবং কনফিগারেশন ম্যানেজারের মাধ্যমে আউটপুট নিয়ন্ত্রণ করছেন। আমাদের ডিফল্ট ডিবাগ এবং প্রকাশের পরিবর্তে প্রতিটি প্রধান শাখার (উন্নয়ন, সংহতকরণ, উত্পাদন) জন্য একটি নামকরণ কনফিগারেশন রয়েছে। একবার আপনার কনফিগারেশন সেটআপ হয়ে গেলে আপনি কনফিগারেশন ম্যানেজারের "বিল্ড" চেকবক্সটি ক্লিক করে এগুলি অন্তর্ভুক্ত বা বাদ দিতে পারেন। (কনফিগারেশন ম্যানেজার পেতে, সমাধানটিতে ডান ক্লিক করুন এবং কনফিগারেশন ম্যানেজারে যান)) দ্রষ্টব্য, আমি ভিজ্যুয়াল স্টুডিওতে মুখ্যমন্ত্রীকে মাঝে মধ্যে বগি হতে দেখি। বেশ কয়েকবার, এটি তৈরি করা লক্ষ্যগুলি পরিষ্কার করতে আমাকে প্রকল্পে এবং / অথবা সমাধান ফাইলগুলিতে যেতে হয়েছিল।
অতিরিক্তভাবে, আপনি যদি টিম বিল্ড ব্যবহার করেন (এবং আমি নিশ্চিত যে অন্যান্য। নেট বিল্ড সরঞ্জামগুলি একই) তবে আপনি বিল্ডটিকে কোনও নামী কনফিগারেশনের সাথে সংযুক্ত করতে পারেন। এর অর্থ হ'ল যদি আপনি আপনার "উত্পাদন" বিল্ডের জন্য ইউনিট পরীক্ষাগুলি না তৈরি করেন, উদাহরণস্বরূপ, বিল্ড প্রকল্পটি এই সেটিং সম্পর্কেও সচেতন হতে পারে এবং সেগুলি তৈরি করার কারণে সেগুলি তৈরি না করে।
এছাড়াও, আমরা বিল্ড মেশিনের XCopy ড্রপগুলি ব্যবহার করতাম। স্ক্রিপ্টটি *। টেস্ট.ডল নামক যে কোনও কিছু অনুলিপি করা বাদ দিবে deployed এটি ছিল সহজ, কিন্তু কাজ।
আমি বলব তাদের আলাদা রাখুন।
উল্লিখিত অন্যান্য কারণগুলির উপরে, কোড এবং পরীক্ষাগুলি একসাথে টেস্ট কভারেজের সংখ্যাগুলিকে স্কিউ করে। যখন আপনি ইউনিট পরীক্ষা কভারেজের প্রতিবেদন করেন - রিপোর্ট করা কভারেজটি বেশি কারণ আপনি ইউনিট পরীক্ষা চালানোর সময় পরীক্ষাগুলি কভার করা হয়। আপনি যখন ইন্টিগ্রেশন টেস্ট কভারেজ সম্পর্কে প্রতিবেদন করবেন তখন রিপোর্ট করা কভারেজটি কম কারণ ইন্টিগ্রেশন টেস্টগুলি ইউনিট পরীক্ষা চালায় না।
আমি রবার্ট লোপেজের বন্যা এনএন গ্রন্থাগারের ইউনিট টেস্টিং কাঠামোর দ্বারা সত্যই অনুপ্রাণিত হয়েছি । এটি প্রতিটি একক পরীক্ষিত শ্রেণীর জন্য একটি পৃথক প্রকল্প ব্যবহার করে এবং এর মধ্যে একটি সমাধান রয়েছে যা এই সমস্ত প্রকল্পগুলিকে ধারণ করে, পাশাপাশি একটি মূল প্রকল্প যা সমস্ত পরীক্ষা সংকলন করে এবং চালায়।
ঝরঝরে জিনিসটি প্রকল্পের বিন্যাসও। উত্স ফাইলগুলি একটি ফোল্ডারে রয়েছে তবে তারপরে ভিএস প্রকল্পের ফোল্ডারটি নীচে রয়েছে। এটি আপনাকে বিভিন্ন সংকলকের জন্য আলাদা আলাদা সাবফোল্ডার তৈরি করতে দেয়। সমস্ত ভিএস প্রকল্পগুলি কোড সহ প্রেরণ করা হয়, সুতরাং যে কোনও একক বা সমস্ত ইউনিট পরীক্ষা চালানো যে কারও পক্ষে খুব সহজ।
আমি জানি এটি একটি খুব পুরানো প্রশ্ন, তবে আমি সেখানে আমার অভিজ্ঞতা যুক্ত করতে চাই আমি সম্প্রতি ইউনিট পরীক্ষার অভ্যাসটি পৃথক প্রকল্প থেকে একই প্রকল্পে পরিবর্তন করেছি।
কেন?
প্রথম আমি পরীক্ষার প্রকল্পের সাথে মূল প্রকল্পের ফোল্ডারের কাঠামো একই রাখার প্রবণতা রাখি। সুতরাং, আমার কাছে যদি একটি ফাইল থাকেProviders > DataProvider > SqlDataProvider.cs তবে আমি আমার ইউনিট পরীক্ষার প্রকল্পগুলির মতো একই কাঠামো তৈরি করছিProviders > DataProvider > SqlDataProvider.Tests.cs
তবে প্রকল্পটি আরও বড় হয়ে ওঠার পরে একবার আপনি ফাইলগুলি এক ফোল্ডার থেকে অন্য ফোল্ডারে ঘুরে দেখেন, বা একটি প্রকল্প থেকে অন্য প্রকল্পে নিয়ে যান, তারপরে ইউনিট পরীক্ষার প্রকল্পগুলির সাথে এটি সমন্বয় করার জন্য খুব জটিল কাজ হচ্ছে।
দ্বিতীয়ত, ইউনিট পরীক্ষার শ্রেণিতে পরীক্ষার জন্য শ্রেণি থেকে নেভিগেট করা সর্বদা খুব সহজ নয়। এটি জাভাস্ক্রিপ্ট এবং পাইথনের পক্ষে আরও শক্ত।
সম্প্রতি, আমি অনুশীলন শুরু করেছি যে, আমার তৈরি প্রতিটি ফাইল (উদাহরণস্বরূপ SqlDataProvider.cs) আমি টেস্ট প্রত্যয় সহ আরও একটি ফাইল তৈরি করছি, যেমনSqlDataProvider.Tests.cs
শুরুতে মনে হচ্ছে এটি ফাইল এবং গ্রন্থাগারের তথ্যসূত্রগুলি প্রস্ফুটিত করে দেবে, তবে দীর্ঘমেয়াদে, আপনি প্রথম নজরে চলন্ত ফাইল সিন্ড্রোমকে সরিয়ে ফেলবেন, এবং আপনি এটিও নিশ্চিত করবেন, পরীক্ষিত প্রার্থীদের প্রত্যেকটি ফাইলের একটি জোড় ফাইল থাকবে সঙ্গে .Tests প্রত্যয়এটি আপনাকে পৃথক প্রকল্পের পরিবর্তে পরীক্ষার ফাইলে ঝাঁপিয়ে পড়া সহজে দেয় (কারণ এটি পাশাপাশি রয়েছে)।
এমনকি আপনি প্রকল্পের মাধ্যমে স্ক্যান করতে এবং বিজনেস বিধিগুলি লিখতে পারেন যা ক্লাস শনাক্ত করতে পারে না T টেস্ট ফাইল, এবং সেগুলি মালিককে প্রতিবেদন করুন। এছাড়াও আপনি সহজেই .Testsক্লাস টার্গেট করতে আপনার পরীক্ষা রানারকে বলতে পারেন ।
বিশেষত জে এবং পাইথনের জন্য আপনাকে বিভিন্ন রেফারেন্স থেকে আপনার রেফারেন্স আমদানি করতে হবে না, আপনি পরীক্ষার জন্য লক্ষ্য ফাইলের একই পথটি ব্যবহার করতে পারেন।
আমি এই অনুশীলনটি কিছু সময়ের জন্য ব্যবহার করছি এবং আমি মনে করি প্রকল্পের বনাম রক্ষণাবেক্ষণযোগ্যতা এবং প্রকল্পে নতুন আগতদের জন্য শেখার বক্ররেখার মধ্যে এটি খুব যুক্তিসঙ্গত বাণিজ্য বন্ধ is
অন্যরা যেমন উত্তর দিয়েছে - আলাদা প্রকল্পে পরীক্ষা দেয়
একটি জিনিস যা উল্লেখ করা হয়নি তা হ'ল আপনি আসলে ফাইল ব্যতীত nunit3-console.exeঅন্য কিছুতে চালাতে পারবেন না .dll।
আপনি যদি টিমসিটির মাধ্যমে আপনার পরীক্ষা চালানোর পরিকল্পনা করছেন, এটি একটি সমস্যা তৈরি করবে।
ধরা যাক আপনার কাছে একটি কনসোল অ্যাপ্লিকেশন প্রকল্প রয়েছে। আপনি যখন কম্পাইল, এটি একটি এক্সিকিউটেবল ফেরৎ .exeকরার binফোল্ডার।
থেকে nunit3-console.exe আপনি সেই কনসোল অ্যাপ্লিকেশনটিতে সংজ্ঞায়িত কোনও পরীক্ষা চালাতে পারবেন না।
অন্য কথায়, একটি কনসোল অ্যাপ্লিকেশন একটি exeফাইল এবং একটি শ্রেণিকাল গ্রন্থাগার ফেরত দেয়dll ফাইলগুলি ।
আমি আজ এই দ্বারা কিছুটা পেলাম এবং এটি স্তন্যপান :(
প্রকল্পগুলি পৃথক করুন, যদিও আমি নিজের সাথে বিতর্ক করি যে তাদের একই এসএনএন ভাগ করা উচিত। এই মুহুর্তে, আমি তাদের আলাদা আলাদা এসএনএন সংগ্রহস্থল দিচ্ছি, যার নাম
"মাইপ্রজেক্ট" - নিজেই প্রকল্পের জন্য
এবং একজন ডেকে আনে
"মাইপ্রজেক্ট টেস্টস" - মাইপ্রজেক্টের সাথে সম্পর্কিত পরীক্ষাগুলির জন্য।
এটি মোটামুটি পরিষ্কার এবং সুবিধা রয়েছে যা প্রকল্পে প্রতিশ্রুতি দেয় এবং পরীক্ষাগুলিতে প্রতিশ্রুতি দেয় যা বেশ আলাদা। এর অর্থ হ'ল আপনি যদি পরীক্ষা না করেই ছাড়েন তবে প্রয়োজনে প্রকল্পের এসএনএন হস্তান্তর করতে পারেন। এর অর্থ হল আপনার পরীক্ষা এবং আপনার প্রকল্পের জন্য আপনার শাখা / ট্রাঙ্ক / ট্যাগ ডিরেক্টরি থাকতে পারে।
তবে আমি প্রতিটি প্রকল্পের জন্য একটি একক এসএনএন সংগ্রহস্থলে নীচের মতো কিছু করার ঝোঁক করছি।
আমার প্রকল্প
| \ ট্রাঙ্ক
| | \ কোড
| \ টেস্ট
| \ ট্যাগ্স
| | \ 0.1
| | | \ কোড
| | \ টেস্ট
| \ 0.2
| | \ কোড
| \ টেস্ট
\শাখা
\ MyFork
| \ কোড
\ টেস্ট
এই সমাধান সম্পর্কে অন্যান্য ব্যক্তিরা কী ভাবছেন তা জানতে আগ্রহী হব।