আমি এই মুহুর্তে এমন একটি প্রকল্পে কাজ করছি যা কোনও ফাইল-সিস্টেমের বিষয়বস্তুর উপর ভিত্তি করে একটি সারণী তৈরি করে (অন্যান্য জিনিসের মধ্যে) তৈরি করে এবং ফলস্বরূপ এটি সন্ধান করে এমন কিছু মেটা-ডেটা পরিবর্তন করে ifications প্রশ্নটি হল: পরীক্ষাগুলি কীভাবে এই চারপাশে লেখা উচিত, বা সেট আপ করা উচিত? এটি উপহাস করার কোন সহজ উপায় আছে? নাকি আমার একটি "স্যান্ডবক্স" সেটআপ করা উচিত?
উত্তর:
আপনি যেমন সর্বদা বাহ্যিক সংস্থানাসহ টিডিডিতে করেন: আপনি আপনার ফাইল সিস্টেমের ক্রিয়াকলাপে এক বা একাধিক ইন্টারফেস তৈরি করেন এবং "এগুলি উপহাস করুন"। আপনি নিজের "টেবিল জেনারেটর" এবং আপনার মেটা-ডেটা পরিবর্তন কোডটি পরীক্ষা করতে চান, নিজে ফাইল সিস্টেম অপারেশন নয় (সম্ভবত সম্ভবত আপনি ফাইল সিস্টেমে অ্যাক্সেসের জন্য তৈরি গ্রন্থাগার প্রয়োগগুলি ব্যবহার করছেন)।
"পরীক্ষা" ফাইল সিস্টেম থাকাতে কী ভুল?
একটি টেম্পলেট ফোল্ডার / ডিরেক্টরি কাঠামো তৈরি করুন যাতে আপনার ক্রিয়াকলাপ পরীক্ষা করার জন্য পর্যাপ্ত সামগ্রী রয়েছে।
আপনার ইউনিট পরীক্ষার সেটআপ করার সময় এই প্রাথমিক কাঠামোটি অনুলিপি করুন (আপনাকে টেমপ্লেটটি জিপ আপ করতে এবং আপনার পরীক্ষার ক্ষেত্রটিতে আনজিপ করার পরামর্শ দিবে)। আপনার পরীক্ষা চালান। টিয়ার ডাউন করার সময় পুরো জিনিসটি মুছুন।
উপহাসের সমস্যাটি হ'ল প্রথমে ফাইল সিস্টেম, ওএস এবং ডেটাবেস যা আপনার প্রকল্পের অন্তর্গত তা বাহ্যিক সংস্থান হিসাবে সত্যই যোগ্যতা অর্জন করে না এবং দ্বিতীয়ত নিম্ন স্তরের সিস্টেম কলকে উপহাস করা সময়সাপেক্ষ এবং ত্রুটিযুক্ত উভয় প্রবণতা।
আপনার অবশ্যই ইন্টিগ্রেশন টেস্টের এটি অবশ্যই প্রয়োজন, কারণ রিয়েল-ওয়ার্ল্ড ফাইল সিস্টেমে সব ধরণের অদ্ভুত আচরণ রয়েছে (যেমন উইন্ডোজ কোনও ফাইল মুছে ফেলতে দেয় না, যদি মুছে ফেলা সহ কোনও প্রক্রিয়া খোলা থাকে)।
সুতরাং টিডিডি পদ্ধতির প্রথমে ইন্টিগ্রেশন টেস্ট লিখতে হবে (টিডিডি, কঠোরভাবে বলতে গেলে, 'ইউনিট টেস্ট' এবং 'ইন্টিগ্রেশন টেস্ট' এর স্বতন্ত্র ধারণা নেই; এগুলি কেবল পরীক্ষা)। বেশ সম্ভবত যথেষ্ট হবে; তাই কাজ শেষ, স্টপ, বাড়ি যাব ।
যদি তা না হয় তবে কিছু অভ্যন্তরীণ জটিলতা থাকবে যা ফাইলগুলি সাজিয়ে পর্যাপ্তভাবে পরীক্ষা করা সহজ নয়। কোন ক্ষেত্রে, আপনি কেবল সেই জটিলতাটি সরিয়ে ফেলেন, এটিকে একটি শ্রেণিতে রাখুন এবং সেই শ্রেণীর জন্য ইউনিট পরীক্ষা লিখুন । বেশ সম্ভবত আপনি দেখতে পাবেন যে সাধারণ ক্লাসটি ডাটাবেস, এক্সএমএল ফাইল, ইত্যাদিতে ব্যবহারযোগ্য।
কোনও ক্ষেত্রেই আপনি যে কোডটি লিখছেন তার মৌলিক মূলটি গ্রহণ করবেন না এবং পরীক্ষার অধীনে থাকা ইউনিটটি ভুল কিনা তা পাস করবে এমন পরীক্ষাগুলি লিখতে এটি 'বিদ্রূপ' করবে out
'unit test' and 'integration test'; they are just tests.রেখেছিল - আমি বাস্তববাদীভাবে মনে করি, এটি আমার মামলার সেরা সমাধান হতে চলেছে - আমার প্রান্তের ক্ষেত্রে যে ফাইল সিস্টেমের লাইব্রেরিগুলি ব্যবহার করছি তা পরীক্ষা করতে হবে এবং অ্যাপ্লিকেশনটি কীভাবে সাড়া দিতে হবে সেগুলো. আমি যদি অন্য কোনও ফাইল সিস্টেমের লাইব্রেরিতে স্যুইচ করি তবে নতুন লাইব্রেরির সাথে কাজ করার জন্য আমার একগুচ্ছ মক / টেস্ট কোডটি পুনরায় লিখতে হবে না, তবে একটি পরীক্ষার ফোল্ডার কাঠামো এবং ইন্টিগ্রেশন টেস্ট থাকা এত সহজ করে তুলবে।
আমি আপনার প্রশ্নটিকে "ফাইল সিস্টেমের ক্রিয়াকলাপের উপর নির্ভর করে এমন একটি শ্রেণীর পরীক্ষা করার ভাল / গ্রহণযোগ্য উপায়" হিসাবে বুঝতে পারি। আমি অনুমান করি না যে আপনি নিজের ওএসের ফাইল সিস্টেম পরীক্ষা করতে চান।
@ আপনার ফাইল সিস্টেমের ক্রিয়াকলাপগুলিতে ইন্টারফেসগুলি রাখার প্রচেষ্টা চালিয়ে যাওয়ার জন্য এবং "এগুলি উপহাস" হিসাবে @ ডক ব্রাউন উত্তর যতটা ছোট প্রস্তাবিত হয়েছে জাভা বাইনারি স্ট্রিম বা পাঠ্য পাঠক (অথবা সি # বা তার সমতুল্য) ব্যবহার করা ভাল ধারণা আপনি যে প্রোগ্রামিং ল্যাঙ্গুয়েজটি ব্যবহার করছেন তা পরিবর্তে ফাইল ফাইলের নাম সহ ফাইলগুলি আপনার টিডিডি-ডেভেলপড ক্লাসে ব্যবহার করার পরিবর্তে ।
উদাহরণ:
জাভা ব্যবহার করে আমি CsvReader ক্লাস প্রয়োগ করেছি
public class CsvReader {
private Reader reader;
public CsvReader(Reader reader) {
this.reader = reader;
}
}
পরীক্ষার জন্য আমি মেমরির মতো ডেটা ব্যবহার করেছি
String contentOfCsv = "TestColumn1;TestColumn2\n"+
"value1;value2\n";
CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));
বা সংস্থানগুলিতে টেস্টডেটা অন্তর্ভুক্ত করুন
CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));
প্রযোজনায় আমি ফাইল সিস্টেমটি ব্যবহার করি
CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));
এইভাবে আমার CsvReader ফাইল সিস্টেমের উপর নির্ভর করে না তবে একটি বিমূর্ত "রিডার" এর উপর নির্ভর করে যেখানে ফাইল সিস্টেমের প্রয়োগ রয়েছে।