শূন্য পদ্ধতিতে ইউনিট পরীক্ষা করা

Question

কোনও অ্যাপ্লিকেশনে একটি বাগ ঠিক করার জন্য, আমি postLoginএকটি বিদ্যমান পদ্ধতিতে কল যুক্ত করে নামকরণের একটি পদ্ধতিটি সংশোধন করেছি getShoppingCart।

কোড

protected void postLogin() {
  getShoppingCart();
}

তবে, আমি নিশ্চিত নই যে ইউনিট পরীক্ষা লেখার সর্বোত্তম উপায় postLoginকোনটি।

পদ্ধতির ঘ

পদ্ধতিটি বলা হয়েছিল তা যাচাই করতে মকিতো থেকে যাচাই করুন।

verify(mock).getShoppingCart();

পদ্ধতির ঘ

ব্যবহারকারীর শপিং কার্টের মান আনার মাধ্যমে পদ্ধতির কলটির পার্শ্ব প্রতিক্রিয়াটি পরীক্ষা করুন।

AssertNotNull(user.getShoppingCart());

একটি পদ্ধতির অপর চেয়ে ভাল?

Comments

যেকোনও পরীক্ষাটি বুঝতে সহজ করে তোলে এবং কোডটি পরিষ্কার রাখে। আপনি পরীক্ষা নকশা নিশ্চিত না হলে, যে পারে সেসব আরও নিদর্শন যে কোড নকশা বন্ধ আছে হও। আপনি এই প্রশ্নগুলি জিজ্ঞাসা করছেন তা নিশ্চিত করুন: " কেন এই পদ্ধতি কলটি বাগ সংশোধন করছে? এই বাগটি ঠিক করার সঠিক উপায় কি ?"

— কালেব

আপনার getShoppingCart()পদ্ধতির পার্শ্ব প্রতিক্রিয়া না থাকলে, আপনাকে এটি পরীক্ষা করার দরকার নেই it's যদি এর পার্শ্ব প্রতিক্রিয়া থাকে তবে আপনার নামটি সত্যই পরিবর্তন করা উচিত কারণ getXXX()প্রচলিত পদ্ধতিগুলি আদর্শগত হতে হবে।

— জুলাই

@ জুলস getNextValue? যুক্তিযুক্তভাবে, কেউ বলতে পারেন "এটাকে গেটার বলবেন না; নামটি পরিবর্তন করুন nextValue", তবে আমি getNextআগে ব্যবহার করতে দেখেছি । সম্ভবত এর চেয়ে আরও ভাল উদাহরণ হ'ল ইলেক্ট্রনকে উপস্থাপনকারী একটি বস্তু; আমি ফোন করলে কি হয় getPosition? বা আরও খারাপ,getPosition(); getVelocity();

— হারুন

Answer 1

আমি সাধারণত পদ্ধতি 2 পছন্দ করব।

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

Answer 2

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

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

যদি getShoppingCart একটি ব্যক্তিগত পদ্ধতি যা নিজেই পরীক্ষা করা যায় না, তবে আমি লগইন 2 প্রত্যাশা হিসাবে getShoppingCart এর কাঙ্ক্ষিত কার্যকারিতা বলা হয় তা নিশ্চিত করার জন্য, পদ্ধতির 2 ব্যবহার করব।

Answer 3

কোনও পার্শ্ব প্রতিক্রিয়া রয়েছে এমন কোনও ফাংশন কল (অকার্যকর বা না) পরীক্ষা করার সময়, পার্শ্ব প্রতিক্রিয়াটি কেবল ঘটে না তা পরীক্ষা করা সবচেয়ে সম্পূর্ণ তবে পার্শ্ব প্রতিক্রিয়া (সিস্টেম আউটপুট বা রাষ্ট্র পরিবর্তন) যেটি পছন্দসই তা পরীক্ষা করে।

Comments

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

— জুলাই

Answer 4

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

Answer 5

পোস্টলগিনে আপনার একটি বাগ রয়েছে। সুতরাং আপনার প্রথমটি করা উচিত একটি ইউনিট পরীক্ষা তৈরি করা যা প্রত্যাশিত তথ্যের সেট ছাড়াই পোস্টলগিনকে কল করার পরে "ব্যর্থ" হয়।

উপরের ধারণা থেকে, প্রস্তাবিত 2 টির আর একটি বিকল্প হ'ল প্যারামিটার হিসাবে শপিং কার্ট সম্পর্কিত তথ্য ইনজেকশন করা। আপনার কাছে সঠিক তথ্য না থাকলে আপনি একটি চেক করা ব্যতিক্রম নিক্ষেপ করেন। এটি পরিষ্কার করে দেবে যে সঠিক বিশদ ছাড়াই আপনার পদ্ধতি বিনষ্ট।

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

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