ফাইল সিস্টেম নির্ভরতা সহ ইউনিট টেস্টিং কোড

Question

আমি একটি উপাদান লিখছি যা, একটি জিপ ফাইল দেওয়া দরকার:

1. ফাইলটি আনজিপ করুন।
2. আনজিপড ফাইলগুলির মধ্যে একটি নির্দিষ্ট dll সন্ধান করুন।
3. প্রতিবিম্বের মধ্য দিয়ে যে dll লোড করুন এবং এটিতে কোনও পদ্ধতির ডাক দিন।

আমি এই উপাদানটি পরীক্ষা করতে চাই।

আমি এমন কোড লিখতে প্ররোচিত হলাম যা সরাসরি ফাইল সিস্টেমের সাথে ডিল করে:

void DoIt()
{
   Zip.Unzip(theZipFile, "C:\\foo\\Unzipped");
   System.IO.File myDll = File.Open("C:\\foo\\Unzipped\\SuperSecret.bar");
   myDll.InvokeSomeSpecialMethod();
}

তবে লোকেরা প্রায়শই বলে, "ইউনিট টেস্টগুলি লিখবেন না যা ফাইল সিস্টেম, ডাটাবেস, নেটওয়ার্ক ইত্যাদির উপর নির্ভর করে" "

আমি যদি এটি ইউনিট-পরীক্ষামূলক বন্ধুত্বপূর্ণ উপায়ে লিখি তবে আমি মনে করি এটি এর মতো দেখায়:

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

হ্যাঁ! এখন এটি পরীক্ষাযোগ্য; আমি DoIt পদ্ধতিতে পরীক্ষার দ্বিগুণ (উপহাস) ভোজন করতে পারি। তবে কী দামে? কেবলমাত্র এই পরীক্ষণযোগ্য করতে আমার এখন 3 টি নতুন ইন্টারফেস সংজ্ঞায়িত করতে হয়েছিল। এবং কি, ঠিক, আমি পরীক্ষা করছি? আমি পরীক্ষা করছি যে আমার DoIt ক্রিয়াটি এর নির্ভরতাগুলির সাথে সঠিকভাবে ইন্টারঅ্যাক্ট করে। এটি পরীক্ষা করে না যে জিপ ফাইলটি সঠিকভাবে আনজিপ করা হয়েছিল, ইত্যাদি doesn't

মনে হচ্ছে না আমি আর কার্যকারিতা পরীক্ষা করছি। মনে হচ্ছে আমি কেবল শ্রেণি ইন্টারঅ্যাকশন পরীক্ষা করছি।

আমার প্রশ্নটি হ'ল ফাইল সিস্টেমের উপর নির্ভরশীল এমন কোনও কিছুর ইউনিট পরীক্ষার যথাযথ উপায় কী?

সম্পাদনা করুন আমি। নেট ব্যবহার করছি, তবে ধারণাটি জাভা বা নেটিভ কোডটিও প্রয়োগ করতে পারে।

Comments

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

— ক্রিস্টোফার পেরি

আপনার অবস্থা অংশ মাত্র যে ইউনিট টেস্টিং প্রয়োজন হবে মধ্যে myDll.InvokeSomeSpecialMethod();তুমি কোথায় পরীক্ষা হবে এটি উভয় সাফল্য সঠিকভাবে কাজ করে এবং পরিস্থিতিতে ব্যর্থ তাই আমি ইউনিট পরীক্ষা করবে না DoItকিন্তু DllRunner.Runযে বলেন ডবল যাচাই করুন একটি ইউনিট পরীক্ষা অপব্যবহার যে সমগ্র প্রক্রিয়ার কাজ হবে একটি গ্রহণযোগ্য অপব্যবহার এবং এটি ইউনিট পরীক্ষার

— মুখোমুখি

Answer 1

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

chdir()আপনার পরীক্ষা চালানোর আগে অস্থায়ী ডিরেক্টরিতে প্রবেশ করা ভাল এবং chdir()পরে তারপরেও ভাল ধারণা হবে ।

Comments

+1 তবে নোট করুন যে chdir()প্রক্রিয়া-প্রশস্ত তাই আপনার পরীক্ষার কাঠামো বা এর কোনও ভবিষ্যতের সংস্করণ যদি এটিকে সমর্থন করে তবে আপনি সমান্তরালভাবে আপনার পরীক্ষাগুলি চালনার ক্ষমতাটি ভেঙে ফেলতে পারেন।

Answer 2

হ্যাঁ! এখন এটি পরীক্ষাযোগ্য; আমি DoIt পদ্ধতিতে পরীক্ষার দ্বিগুণ (উপহাস) ভোজন করতে পারি। তবে কী দামে? কেবলমাত্র এই পরীক্ষণযোগ্য করতে আমার এখন 3 টি নতুন ইন্টারফেস সংজ্ঞায়িত করতে হয়েছিল। এবং কি, ঠিক, আমি পরীক্ষা করছি? আমি পরীক্ষা করছি যে আমার DoIt ক্রিয়াটি এর নির্ভরতাগুলির সাথে সঠিকভাবে ইন্টারঅ্যাক্ট করে। এটি পরীক্ষা করে না যে জিপ ফাইলটি সঠিকভাবে আনজিপ করা হয়েছিল, ইত্যাদি doesn't

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

Comments

Testable DoItবিবৃত হিসাবে ফাংশন এমনকি পরীক্ষামূলক দরকার নেই। যেমন প্রশ্নকর্তা ঠিক বলেছেন যে পরীক্ষার জন্য তাত্পর্যপূর্ণ কিছুই নেই। এখন এটা বাস্তবায়নের এর IZipper, IFileSystemএবং IDllRunnerযে পরীক্ষার প্রয়োজনে, কিন্তু তারা খুব যে জিনিস পরীক্ষার জন্য আউট ব্যঙ্গ করা হয়েছে!

— আয়ান গোল্ডবি

Answer 3

আপনার প্রশ্নটি বিকাশকারীদের জন্য এটির পরীক্ষার সবচেয়ে শক্ত অংশগুলির মধ্যে একটি উন্মোচিত করে:

"আমি কী পরীক্ষা করবো?"

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

খারাপ পরীক্ষা করা আসলে কোনও পরীক্ষা না করার চেয়ে খারাপ।

আপনার উদাহরণে:

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

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

// Assuming that zipper, fileSystem, and runner are mocks
void testDoIt()
{
  // mock behavior of the mock objects
  when(zipper.Unzip(any(File.class)).thenReturn("some path");
  when(fileSystem.Open("some path")).thenReturn(mock(IFakeFile.class));

  // run the test
  someObject.DoIt(zipper, fileSystem, runner);

  // verify things were called
  verify(zipper).Unzip(any(File.class));
  verify(fileSystem).Open("some path"));
  verify(runner).Run(file);
}

অভিনন্দন, আপনি মূলত আপনার DoIt()পদ্ধতির প্রয়োগের বিশদটি একটি পরীক্ষায় অনুলিপি করেছেন । শুভ রক্ষণাবেক্ষণ

আপনি যখন টেস্ট লিখবেন পরিক্ষা করে দেখতে চান কি এবং কেমন । দেখুন ব্ল্যাকবক্স টেস্টিং দেখুন।

কি আপনার পদ্ধতির নাম (বা অন্তত এটা করা উচিত)। কেমন সব সামান্য বাস্তবায়ন বিবরণ আপনার পদ্ধতি ভিতরে বাস আছে। ভাল পরীক্ষাগুলি আপনাকে WHAT ভঙ্গ না করে HOW পরিবর্তন করতে দেয় ।

এভাবে চিন্তা করুন, নিজেকে জিজ্ঞাসা করুন:

"যদি আমি এই পদ্ধতির প্রয়োগের বিবরণ পরিবর্তন করি (জনসাধারণের চুক্তিটি পরিবর্তন না করে) এটি কি আমার পরীক্ষা (গুলি) ভঙ্গ করবে?"

যদি উত্তর হ্যাঁ হয়, তাহলে আপনি পরীক্ষা কেমন এবং কি ।

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

interface StreamFactory {
    OutputStream outStream();
    InputStream inStream();
}

class Base64FileWriter {
    public void write(byte[] contents, StreamFactory streamFactory) {
        OutputStream outputStream = streamFactory.outStream();
        outputStream.write(Base64.encodeBase64(contents));
    }
}

@Test
public void save_shouldBase64EncodeContents() {
    OutputStream outputStream = new ByteArrayOutputStream();
    StreamFactory streamFactory = mock(StreamFactory.class);
    when(streamFactory.outStream()).thenReturn(outputStream);

    // Run the method under test
    Base64FileWriter fileWriter = new Base64FileWriter();
    fileWriter.write("Man".getBytes(), streamFactory);

    // Assert we saved the base64 encoded contents
    assertThat(outputStream.toString()).isEqualTo("TWFu");
}

পরীক্ষায় ByteArrayOutputStreamঅ্যাপ্লিকেশনটিতে একটি (তবে নির্ভরতা ইনজেকশন ব্যবহার করে) ব্যবহার করা হয় (আসল স্ট্রিমফ্যাক্টরি (সম্ভবত ফাইলস্ট্রিমফ্যাক্টরি নামে পরিচিত)) FileOutputStreamথেকে ফিরে আসবে outputStream()এবং এ-তে লিখিত হবে File।

writeএখানে পদ্ধতিটি সম্পর্কে আকর্ষণীয় বিষয়টি হ'ল এটি বেস 64 নথিভুক্ত সামগ্রীগুলি লিখেছিল, তাই আমরা এটির জন্য পরীক্ষিত। আপনার DoIt()পদ্ধতির জন্য, এটি আরও উপযুক্তভাবে একটি সংহতকরণ পরীক্ষার মাধ্যমে পরীক্ষা করা হবে ।

Comments

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

— রনি

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

— ক্রিস্টোফার পেরি

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

— ভিকি চিজওয়ানি

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

— ক্রিস্টোফার পেরি

Answer 4

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

আমার গ্রহণযোগ্যতাটি হ'ল আপনার ইউনিট পরীক্ষাগুলি তাদের যতটা করতে পারে তেমন করবে যা 100% কভারেজ নাও হতে পারে। আসলে, এটি কেবল 10% হতে পারে। মুল বক্তব্যটি হল, আপনার ইউনিট পরীক্ষাগুলি দ্রুত হওয়া উচিত এবং কোনও বাহ্যিক নির্ভরতা নেই have "আপনি এই প্যারামিটারটি বাতিল করতে গেলে এই পদ্ধতিটি একটি আর্গুমেন্টনাল এক্সসেপশন নিক্ষেপ করে" এর মতো কেসগুলি পরীক্ষা করতে পারে।

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

কোড কভারেজ পরিমাপ করার সময়, আমি ইউনিট এবং সংহতকরণ উভয়ই পরিমাপ করি।

Comments

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

— এহুদা গ্যাব্রিয়েল হিমাঙ্গো

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

— ক্রিস্টোফার পেরি

@ খ্রিস্টোফার: আপনার সাদৃশ্যটি বাড়ানোর জন্য, আমি চাই না যে আমার কেকটি কেবল ভিনিলা টুকরো জাতীয় সাদৃশ্যযুক্ত হয় যাতে আমি চিনি ব্যবহার করতে পারি। আমি যতটুকু পরামর্শ দিচ্ছি তা হ'ল ব্যবহারবাদ।

— কেন্ট বুগার্ট

@ খ্রিস্টোফার: আপনার বায়োতে ​​সব কিছু বলা হয়েছে: "আমি একটি টিডিডি জেলিয়ট"। আমি, অন্যদিকে, বাস্তববাদী। আমি যেখানে টিডিডি রাখি যেখানে এটি ফিট করে এবং যেখানে এটি হয় না - আমার উত্তরের কিছুই প্রস্তাব দেয় না আমি টিডিডি করি না, যদিও আপনি মনে করেন এটি এটি করে does এবং এটি টিডিডি হোক বা না হোক, আমি পরীক্ষার সুবিধার্থে বড় আকারের জটিলতার পরিচয় দেব না।

— কেন্ট বুগার্ট

@ ক্রিস্টোফেরপেরি কীভাবে আপনি ওডি'র মূল সমস্যাটি টিডিডি উপায়ে সমাধান করবেন তা ব্যাখ্যা করতে পারেন? আমি এই সব সময় চালানো; আমাকে একটি ফাংশন লিখতে হবে যার একমাত্র উদ্দেশ্য এই প্রশ্নের মতো একটি বাহ্যিক নির্ভরতা সহ একটি ক্রিয়া সম্পাদন করা। এমনকি টেস্ট-প্রথম-লেখার দৃশ্যে, সেই পরীক্ষাটি কী হবে?

— ডেক্স ফোহল

Answer 5

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

যদি আপনার ইন্টিগ্রেশন পরীক্ষাগুলি চালাতে খুব বেশি সময় নেয় তবে এগুলি আলাদা করুন যাতে তারা আপনার দ্রুত ইউনিট পরীক্ষার মতো প্রায়শই চালাচ্ছে না।

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

Comments

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

— এহুদা গ্যাব্রিয়েল হিমাঙ্গো

আসলে তা না. তবে যদি বিকাশকারীরা স্থানীয়ভাবে সমস্ত ইউনিট টেস্টগুলি দ্রুত চালাতে চান তবে এটি করার সহজ উপায় থাকার জন্য এটি দুর্দান্ত।

— জে.সি.

Answer 6

একটি উপায় হ'ল ইনপুট স্ট্রিমগুলি নিতে আনজিপ পদ্ধতিটি লেখা। তারপরে ইউনিট পরীক্ষা বাইটআরআই ইনপুট স্ট্রিম ব্যবহার করে বাইট অ্যারে থেকে এ জাতীয় ইনপুট স্ট্রিম তৈরি করতে পারে। সেই বাইট অ্যারের সামগ্রীগুলি ইউনিট পরীক্ষার কোডে একটি ধ্রুবক হতে পারে।

Comments

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

— এহুদা গ্যাব্রিয়েল হিমাঙ্গো

Answer 7

এটি তাত্ত্বিকভাবে পরিবর্তিত হতে পারে এমন একটি নির্দিষ্ট বিশদ (ফাইল সিস্টেম) এর উপর নির্ভরশীল হওয়ায় এটি আরও একীকরণের পরীক্ষা বলে মনে হচ্ছে।

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

Answer 8

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

Comments

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

— এহুদা গ্যাব্রিয়েল হিমাঙ্গো

@JudahHimango। এই অংশগুলি অগত্যা পরীক্ষামূলক হতে পারে না। আপনি সব কিছু পরীক্ষা করতে পারবেন না। অ-পরীক্ষামূলক উপাদানগুলি তাদের নিজস্ব কার্যকরী ব্লকে বিমূর্ত করুন এবং ধরে নিন যে তারা কাজ করবে। এই ব্লকটি যেভাবে কাজ করে আপনি যখন কোনও বাগ জুড়ে আসেন তখন তার জন্য একটি পরীক্ষা করুন এবং ভয়েলা। ইউনিট পরীক্ষার অর্থ এই নয় যে আপনাকে সমস্ত কিছু পরীক্ষা করতে হবে। কিছু পরিস্থিতিতে 100% কোডের কভারেজ অবাস্তব।

— জোড়ান পাভলভিক

Answer 9

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

Answer 10

ইউনিট পরীক্ষার জন্য আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি পরীক্ষার ফাইলটি আপনার প্রকল্পে অন্তর্ভুক্ত করুন (EAR ফাইল বা সমতুল্য) তারপরে ইউনিট পরীক্ষায় একটি আপেক্ষিক পথ ব্যবহার করুন অর্থাৎ "../testdata/testfile"।

আপনার ইউনিট পরীক্ষার চেয়ে যতক্ষণ আপনার প্রকল্পটি সঠিকভাবে রফতানি / আমদানি করা উচিত।

Answer 11

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

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