একক ক্লাস পরীক্ষা করার জন্য একক বা একাধিক ফাইল?

Question

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

FWWW, আমি "ইউনিট পরীক্ষা" শুদ্ধ অর্থে উল্লেখ করছি যে সেগুলি একক শ্রেণিকে লক্ষ্য করে হোয়াইট-বাক্স পরীক্ষা, পরীক্ষায় প্রতি একটি দৃser়তা, সমস্ত নির্ভরতা উপহাস ইত্যাদি etc.

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

বা, আমার দুটি পৃথক পরীক্ষার ক্লাস থাকতে পারে: CheckInShouldএবং CheckOutShould। এই ক্ষেত্রে, আমার পরীক্ষার নামগুলি সংক্ষিপ্ত করা হবে তবে সেগুলি সংগঠিত করা হবে তাই নির্দিষ্ট আচরণের (পদ্ধতি) জন্য সমস্ত পরীক্ষা এক সাথে থাকে।

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

Comments

আপনার পরীক্ষার পদ্ধতির নামগুলি অত্যন্ত দীর্ঘ। এগুলিকে সরলীকরণ করুন, এমনকি যদি এর অর্থ কোনও পরীক্ষার পদ্ধতিতে একাধিক মন্তব্য থাকে।

— বার্নার্ড

@ বার্নার্ড: পদ্ধতি অনুসারে একাধিক প্রতিবেদন রাখা খারাপ অভ্যাস হিসাবে বিবেচিত হয়, দীর্ঘ পরীক্ষার পদ্ধতির নামগুলি তবে খারাপ অভ্যাস হিসাবে বিবেচিত হয় না। নামটি নিজেই পদ্ধতিটি যা পরীক্ষা করছে তা আমরা সাধারণত নথি করি। যেমন কনস্ট্রাক্টর_নুলসোমলিস্ট (), সেট ইউজারনেম_উজারনেম আইস নটভালিড () ইত্যাদি ...

— সি_মেকার

@ বার্নার্ড: আমি দীর্ঘ পরীক্ষার নামগুলি (এবং কেবল সেখানে!) ব্যবহার করি। আমি তাদের ভালবাসি, কারণ এটি এতটা পরিষ্কার হয়ে গেছে যে কী কাজ করছে না (যদি আপনার নামগুলি ভাল পছন্দ হয়;))।

— সেবাস্তিয়ান বাউয়ার

একাধিক জোর দেওয়া খারাপ অভ্যাস নয়, যদি সেগুলি একই ফলাফলের পরীক্ষা করে। যেমন। আপনার হবে না testResponseContainsSuccessTrue(), testResponseContainsMyData()এবং testResponseStatusCodeIsOk()। আপনি একটি একক তাদের হবে testResponse(): যা তিনটি দাবি assertEquals(200, response.status), assertEquals({"data": "mydata"}, response.data)এবংassertEquals(true, response.success)

— জুহাকে Untinen

Answer 1

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

Comments

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

— SonOfPirate

Answer 2

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

1. সেট আপ কোডটির সদৃশ (এবং একাধিক সংস্করণ বজায় রাখা) দরকার নেই
2. কোনও আইডিই থেকে কোনও পরীক্ষার শ্রেণিতে তারা গ্রুপে থাকলে সমস্ত শ্রেণীর জন্য পরীক্ষা চালানো আরও সহজ
3. টেস্ট-ক্লাস এবং ক্লাসগুলির মধ্যে এক থেকে এক ম্যাপিংয়ের মাধ্যমে আরও সহজে সমস্যা সমাধান।

Comments

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

— কাজ

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

— SonOfPirate

JUnit যেমন আপনি বিভিন্ন রানার ব্যবহার করে বিভিন্ন জিনিস পরীক্ষা করতে চাইতে পারেন যা বিভিন্ন শ্রেণীর প্রয়োজনের দিকে পরিচালিত করে।

— জোয়াকিম নীলসন

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

— হাঁসকে

Answer 3

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

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

Comments

হায়রে, সত্যিকারের বিশ্বে সমস্ত শ্রেণি এসআরপি এট আল অনুসরণ করে না ... এবং যখন আপনি ইউনিট পরীক্ষামূলক উত্তরাধিকার কোডটি করেন তখন এটি একটি সমস্যা হয়ে দাঁড়ায়।

— পেটার টার্ক

এসআরপি এখানে কীভাবে সম্পর্কিত তা নিশ্চিত নয়। আমার ক্লাসে আমার একাধিক পদ্ধতি রয়েছে এবং তাদের আচরণকে চালিত করে এমন বিভিন্ন প্রয়োজনীয়তার জন্য আমার একক পরীক্ষা লিখতে হবে। পরীক্ষার অধীনে ক্লাসে একটি নির্দিষ্ট পদ্ধতির সাথে সম্পর্কিত 50 টি পরীক্ষার পদ্ধতি সহ 5 টি পরীক্ষা ক্লাস বা 10 টি পরীক্ষা সহ 5 টি পরীক্ষার ক্লাস রাখা কি ভাল?

— SonOfPirate

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

— দ্বারস্থ

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

— SonOfPirate

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

— ফিশব্যাসকেট গর্ডো

Answer 4

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

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

Answer 5

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

এখানে এই উদাহরণটি আমার মূল দৃশ্যে কীভাবে প্রয়োগ করা হবে তা এখানে রয়েছে:

public abstract class DocumentTests : TestBase
{
    [TestClass()]
    public sealed class CheckInShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }

    [TestClass()]
    public sealed class CheckOutShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }
}

নিম্নলিখিত পরীক্ষাগুলির ফলাফল পরীক্ষার তালিকায় উপস্থিত রয়েছে:

DocumentTests+CheckInShould.ThrowExceptionWhenUserIsNotAuthorized
DocumentTests+CheckOutShould.ThrowExceptionWhenUserIsNotAuthorized

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

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

Answer 6

এক মিনিটের জন্য অন্যভাবে ভাবতে চেষ্টা করুন।

কেন আপনি প্রতি ক্লাসে শুধুমাত্র একটি পরীক্ষা ক্লাস হবে? আপনি কি ক্লাস টেস্ট করছেন বা ইউনিট টেস্ট করছেন? আপনি এমনকি ক্লাস উপর নির্ভর করে ?

একটি ইউনিট পরীক্ষা একটি নির্দিষ্ট প্রসঙ্গে একটি নির্দিষ্ট আচরণের পরীক্ষা করার কথা রয়েছে। আপনার ক্লাসের ইতিমধ্যে একটি CheckInউপায় রয়েছে এই বিষয়টি এমন একটি আচরণ হওয়া উচিত যা এটির প্রথম স্থানে দরকার।

আপনি এই ছদ্ম-কোড সম্পর্কে কীভাবে ভাববেন:

// check_in_test.file

class CheckInTest extends TestCase {
        /** @test */
        public function unauthorized_users_cannot_check_in() {
                $this->expectException();

                $document = new Document($unauthorizedUser);

                $document->checkIn();
        }
}

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

এক শ্রেণীর জন্য একটি পরীক্ষার ফাইল যখনই আপনার প্রয়োজন হয় কেবল রিফ্যাক্টরকে শক্ত করে তোলে এবং টেস্টগুলি কোডের ডোমেন / যুক্তির ক্ষেত্রেও কম বোঝায়।

Answer 7

সাধারণভাবে আমি কোনও পদ্ধতির চেয়ে ক্লাসের আচরণের পরীক্ষা হিসাবে পরীক্ষা সম্পর্কে চিন্তাভাবনা করার পরামর্শ দেব। অর্থাৎ আপনার কিছু পরীক্ষার জন্য কিছু প্রত্যাশিত আচরণ পরীক্ষা করার জন্য ক্লাসে উভয় পদ্ধতিতে কল করতে হতে পারে।

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

Answer 8

1. কী ভুল হতে পারে তা বিবেচনা করুন

প্রাথমিক বিকাশের সময় আপনি কী করছেন তা মোটামুটি ভালভাবেই জানেন এবং উভয় সমাধানই সম্ভবত ঠিকঠাক কাজ করবে।

অনেক পরে পরিবর্তনের পরে যখন কোনও পরীক্ষা ব্যর্থ হয় তখন এটি আরও আকর্ষণীয় হয়। দুটি সম্ভাবনা রয়েছে:

1. আপনি মারাত্মকভাবে ভেঙে গেছেন CheckIn(বা CheckOut)। আবার, একক-ফাইলের পাশাপাশি দুটি-ফাইল সমাধান ঠিক আছে।
2. আপনি উভয় CheckInএবং CheckOut(এবং সম্ভবত তাদের পরীক্ষা) উভয়কে এমনভাবে সংশোধন করেছেন যা তাদের প্রত্যেকের জন্য অর্থবোধ করে, তবে উভয়ের জন্য একত্রে নয়। আপনি এই জুটির মিলকে ভেঙে ফেলেছেন। সেক্ষেত্রে দুটি ফাইলের মাধ্যমে পরীক্ষাগুলি বিভক্ত করা সমস্যাটি বোঝা আরও শক্ত করে তুলবে।

২. কোন পরীক্ষার জন্য ব্যবহৃত হয় তা বিবেচনা করুন

টেস্ট দুটি প্রধান উদ্দেশ্য করে:

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

তাই?

এই উভয় দৃষ্টিভঙ্গি পরীক্ষা একসঙ্গে রাখা সাহায্য করতে পারে পরামর্শ দেয়, কিন্তু ক্ষতি হবে না।