প্রতিটি পদক্ষেপের জন্য পৃথক পরীক্ষার পদ্ধতি রাখা কি ভাল ধারণা?


10

আমি একটি REST এপিআই পরীক্ষা করছি। ধরা যাক এটি একটি JSON কাঠামো দেয়। সার্ভারটি পরীক্ষা করার জন্য সর্বোত্তম পদ্ধতির কী? প্রতিটি পরীক্ষার পদক্ষেপ কেবল তখনই সফল হতে পারে যদি পূর্ববর্তী সমস্ত সফল হয়।

কাঠামো এ: একবারে সবকিছু পরীক্ষা করুন

- Test method 1:
    - make server request
    - assert http response code was 200
    - assert returned file is not empty
    - assert returned file has valid JSON syntax
    - assert returned JSON contains key X

এটি সেরা সমাধান বলে মনে হচ্ছে।

সুবিধাদি:

  • কেবল একটি সার্ভারের অনুরোধ
  • আমি সামগ্রিকভাবে আচরণের পরীক্ষা নিরীক্ষা করছি "কী সার্ভার কী X এর সাহায্যে কোনও JSON ফেরায়?"

কাঠামো বি: প্রতিটি পরীক্ষায় ধীরে ধীরে সংযোজন যুক্ত করুন

 - Test method 1:
     - make server request
     - assert http response code was 200
 - Test method 2:
     - make server request
     - assert returned file is not empty
 - Test method 3:
     - make server request
     - assert returned file has valid JSON syntax
 - Test method 4:
     - make server request
     - assert returned JSON contains key X

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

কাঠামো সি: একবার অনুরোধ করুন এবং ক্যাশেড প্রতিক্রিয়াতে পৃথক পরীক্ষা পদ্ধতি চালান

- make server request and cache it (allow read-only access)

 - Test method 1:
     - assert http response code was 200 on cached server request
 - Test method 2:
     - assert returned file is not empty on cached server request
 - Test method 3:
     - assert returned file has valid JSON syntax on cached server request
 - Test method 4:
     - assert returned JSON contains key X on cached server request

সুবিধাদি:

  • পুনরাবৃত্তি (ব্যয়বহুল) সার্ভারের অনুরোধ নেই
  • এখনও একক দাবী পরীক্ষা পদ্ধতি আছে

সবচেয়ে বুদ্ধিমান পরীক্ষার কাঠামোটি ব্যবহার করার জন্য কোনটি?


দয়া করে আপনার প্রশ্নটি পরে এমনভাবে পরিবর্তন করা বন্ধ করুন যা বিদ্যমান উত্তরগুলিকে অবৈধ করে দেয়! ধন্যবাদ।
ডক ব্রাউন

আপনার অসুবিধার কারণ হওয়ার জন্য দুঃখিত তবে আপনি কি অন্যথায় প্রস্তাব করবেন?
mrplow

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

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

উত্তর:


3

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

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

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

সুতরাং, আপনাকে নিজেকে জিজ্ঞাসা করতে হবে - "আমার এখানে এই গ্যারান্টিটি সত্যিই দরকার?"

ধরা যাক প্রথম পরীক্ষার ক্ষেত্রে একটি ত্রুটি রয়েছে - HTTP প্রতিক্রিয়া কোডটি নয় 200। সুতরাং আপনি কোডটি হ্যাকিং শুরু করেছেন, আপনার কেন হওয়া উচিত প্রতিক্রিয়া কোডটি কেন পাননি তা খুঁজে বের করুন এবং সমস্যাটি ঠিক করুন। এবং এখন কি?

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

বিবেচনা করার মতো আরও কয়েকটি বিষয় রয়েছে:

জোর নির্ভরতা

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

যদি আপনার কাছে একটি রিএসইটি পরিষেবা (বা অন্য কোনও এইচটিটিপি প্রোটোকল) থাকে যা জেএসএন ফর্ম্যাটে প্রতিক্রিয়া দেখায়, আপনি সাধারণত একটি সাধারণ ক্লায়েন্ট শ্রেণি লিখেন যা আপনাকে নিয়মিত পন্থাগুলি ফিরে আসা নিয়মিত পদ্ধতির মতোই আরআরএসটি পদ্ধতি ব্যবহার করতে দেয়। অনুমান করে যে ক্লায়েন্টের এটির কাজ করে তা নিশ্চিত করার জন্য পৃথক পরীক্ষা রয়েছে, আমি প্রথম 3 টি দৃser়তা খালি করে কেবল 4 রেখে দিতাম!

কেন?

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

সুতরাং আপনাকে এই সমস্ত পরীক্ষা চালানোর দরকার নেই - কেবল চতুর্থ পরীক্ষাটি চালান, এবং বাগগুলি যদি প্রথম তিনটি সনাক্ত করার চেষ্টা করে তবে পরীক্ষাটি সত্যিকারের দৃ actual়তা পাওয়ার আগেই যথাযথ ব্যতিক্রম সহ ব্যর্থ হবে।

আপনি কীভাবে প্রতিবেদনগুলি পেতে চান?

ধরা যাক আপনি একটি পরীক্ষার সার্ভার থেকে ইমেল পান না, তবে এর পরিবর্তে QA বিভাগ পরীক্ষা চালায় এবং আপনাকে ব্যর্থ পরীক্ষাগুলি সম্পর্কে অবহিত করে।

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

তারপরে জেন QA থেকে আসে এবং বলে যে তৃতীয় পরীক্ষার পদ্ধতিটি ব্যর্থ হয়েছে - REST পদ্ধতিটি প্রতিক্রিয়া সংস্থায় কোনও বৈধ JSON ফেরত দেয় না। আপনি তাকে বলছেন যে আপনি ইতিমধ্যে সেই পদ্ধতিটি দেখছেন, এবং আপনি বিশ্বাস করেন যে একই জিনিসটি এটির কারণে খারাপ প্রস্থান কোডটি ফিরে আসে এবং এটি এমন কোনও কিছু ফেরত দেয় যা বৈধ JSON নয় এবং এটি একটি ব্যতিক্রম স্ট্যাক ট্রেসের মতো দেখায়।

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

আপনি এমনকি কারণটিও সন্ধান করতে পারবেন না কারণ আপনার কাছে কম্পিউটারের স্ক্রিন না থাকলে কোডটি দেখা শক্ত। জিম যদি খুব তাড়াতাড়ি হয় তবে সে সময়মতো ঝাঁপিয়ে পড়ে থাকতে পারে ...

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


3

আপনি যদি নিরাপদে ধরে নিতে পারেন যে একই প্যারামিটারগুলির সাথে একটি সার্ভার অনুরোধ করা সর্বদা একই আচরণ করে, পদ্ধতি বি প্রায় অর্থহীন - যখন একটি কল পর্যাপ্ত হয় তখন কেন একই প্রতিক্রিয়ার ডেটা পেতে চারবার একই পদ্ধতিতে কল করা উচিত?

এবং যদি আপনি নিরাপদে এটি ধরে না নিতে পারেন এবং এটি পরীক্ষার অংশ করতে চান তবে আপনি একাধিকবার পরীক্ষা চালিয়ে যাওয়ার চেয়ে ভাল।

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

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

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


0

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

যদি আপনার সার্ভারটি রাষ্ট্রহীন থাকে তবে আপনি একবারে পুরো বার্তাটি পরীক্ষা করার জন্য প্রত্যাশিত প্রতিক্রিয়াটির সাথে প্রকৃত প্রতিক্রিয়াটির তুলনা করে অনুকূলিত করতে পারেন। স্পষ্টতই তা পঠনযোগ্যতার ব্যয়ে হবে।

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


0

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


কোনও কোড লেখার সময় (বা সম্ভবত অন্য কোনও কিছু তৈরি করার সময়) নিজেকে সর্বদা জিজ্ঞাসা করুন: "কেন এমন অনুশীলন রয়েছে?"
কেন আমরা বলি যে প্রত্যেক কিছুর জন্য আলাদা আলাদা পরীক্ষা করা উচিত?

আপনার যখন এটির প্রয়োজন হয় তখন দুটি মামলা রয়েছে:

  1. আপনি যখন "নির্ভর করতে পারবেন না প্রতিটি পরীক্ষার ধাপ কেবল তখনই সফল হতে পারে যদি সমস্ত পূর্ববর্তী সমস্ত সফল হত"
  2. যখন আপনার পরীক্ষাগুলিতে বর্ণনামূলক ম্যাসেজ থাকে না

আপনি এই মামলাগুলির মুখোমুখি হওয়ার দুটি কারণ রয়েছে:

  1. "প্রতিটি পরীক্ষার পদক্ষেপ কেবল তখনই সফল হতে পারে যদি সমস্ত পূর্ববর্তী সমস্ত সফল হয়" আপনার পণ্য বৈশিষ্ট্যের জন্য সত্যই প্রযোজ্য নয়
  2. অভিজ্ঞতা বা সময় বা অপ্রতিরোধ্য পণ্যের জটিলতার অভাবে আপনার কাছে পণ্য সম্পর্কে পর্যাপ্ত জ্ঞান নেই

আপনি যদি কোনও কারণে এই জায়গাগুলির অন্তত কোনও কারণ সুনির্দিষ্টভাবে ঘোষণা করতে না পারেন তবে কেবল কাঠামো B কে অন্ধভাবে নিয়ে যান ।


তা না হলে (আমি তুমি এখানে আশা করি) আপনার চয়ন করা একটি


এছাড়াও আপনি এই প্রশ্নটি সফটওয়্যার কোয়ালিটি আশ্বাস এবং টেস্টিং স্ট্যাকেক্সচেঞ্জ সাইটে জিজ্ঞাসা করতে পারেন ।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.