স্থিতিশীল এন্ড-টু-এন্ড (E2E) পরীক্ষার জন্য, আমাদের এমন একটি পরিবেশ প্রয়োজন যা যতটা সম্ভব বাইরে থেকে বিচ্ছিন্ন।
ফ্ল্যাকি পরীক্ষা হল এমন পরীক্ষা যা আপনার কোডের সাথে সম্পর্কহীন কারণে ব্যর্থ হয়। তারা আবেদনের সঠিকতার জন্য একটি নির্ভরযোগ্য পরীক্ষা হিসাবে E2E ব্যবহার করা কঠিন করে তোলে। চরম ক্ষেত্রে, ফ্ল্যাকি পরীক্ষা আপনার দলকে E2E ফলাফল উপেক্ষা করতে শেখাবে। এটি স্বয়ংক্রিয় গুণমান নিয়ন্ত্রণ (QA) এর প্রচেষ্টাকে হত্যা করতে পারে।
এখানে উপস্থাপিত পদ্ধতিটি আপনার পরীক্ষা চালানোর সম্ভাব্য সমস্যার দুটি বড় উত্সকে সম্বোধন করে:
এই পদ্ধতির দ্বারা প্রভাবিত হয় না flakiness অন্যান্য উত্স আছে:
আমার দল এবং আমি একটি ডেডিকেটেড ব্যাকএন্ড কন্টেইনারের বিরুদ্ধে আমার পরীক্ষা চালানোর আগে, আমরা আমাদের একটি অ-উৎপাদন সার্ভার ব্যবহার করেছি। আমাদের E2E সমাধানের পরীক্ষামূলক পর্যায়ে এই পদ্ধতিটি ঠিক ছিল।
যখন মাত্র কয়েকটি পরীক্ষা ছিল, আমরা যেভাবেই হোক সিদ্ধান্ত নিতে পরীক্ষার ফলাফল ব্যবহার করতে পারিনি।
যাইহোক, যেহেতু আমরা আরও পরীক্ষা যোগ করতে থাকি এবং দীর্ঘ কার্যকর করার সময় তৈরি করেছি, এই পদ্ধতিটি বিচ্ছিন্ন হতে শুরু করে। প্রধান সমস্যাগুলি নিম্নরূপ ছিল:
এই সমস্যার একটি সমাধান ছিল প্রতিটি পরীক্ষার কাজের জন্য একটি পৃথক ব্যাকএন্ড সার্ভার এবং ডাটাবেস উৎসর্গ করা। এই পদ্ধতিটি খুব চ্যালেঞ্জিং হবে যদি এটি ডকারের জন্য না হয়।
ডকার কন্টেইনারগুলি চালানোর জন্য একটি অ্যাপ্লিকেশনের জন্য প্রয়োজনীয় সমস্ত কিছু সহ একটি ধারণ পরিবেশ তৈরি করার জন্য একটি নিখুঁত সরঞ্জাম:
আপনার পরীক্ষার জন্য, আপনি একটি ডেডিকেটেড ডাটাবেস ধারক প্রস্তুত করতে পারেন যা অনুমানযোগ্য পরীক্ষার ডেটা সহ আসে। এইভাবে, আপনি প্রতিটি E2E এক্সিকিউশনে ঠিক সূচনা বিন্দুটি পুনরুত্পাদন করতে সক্ষম হবেন—আপনার পরীক্ষাগুলিকে আরও স্থিতিশীল করে তুলবে।
আপনি পরীক্ষার ডাটাবেসের সংস্করণের জন্য আপনার ডকার চিত্রের জন্য বিভিন্ন ট্যাগ ব্যবহার করতে পারেন। একই পরীক্ষার ডাটাবেস একটি উন্নয়ন পরিবেশেও ব্যবহার করা যেতে পারে। বিকাশে ম্যানুয়াল পরীক্ষার জন্য, আপনার স্বয়ংক্রিয় পরীক্ষার মতো অনুরূপ উদাহরণ সত্তা প্রয়োজন।
আপনি যদি ইতিমধ্যে আপনার ব্যাকএন্ড স্থাপনের জন্য ডকার ব্যবহার করেন তবে আপনার E2E চালানোর জন্য একই চিত্রটি পুনরায় ব্যবহার করা বেশ সহজ হবে। আমার দলে, আমরা কন্টেইনার হিসাবে একটি ব্যাকএন্ড স্থাপন করি এবং আমরা পরিবেশ ভেরিয়েবল হিসাবে ডাটাবেস URL এবং শংসাপত্র সরবরাহ করি।
একই কন্টেইনার সংস্করণটি উত্পাদনে স্থাপন করা যেতে পারে বা পরীক্ষা চালানোর জন্য ক্রমাগত ইন্টিগ্রেশন (CI) ব্যবহার করা যেতে পারে — প্রতিটি পরিবেশ DB-তে সংযোগ করার জন্য সঠিক মান সরবরাহ করে।
আপনার স্থাপনার কৌশলের উপর নির্ভর করে, আপনি নিম্নলিখিতগুলির মধ্যে একটি করতে পারেন:
ফ্রন্টএন্ড বিল্ডের অংশ হিসাবে আপনি যে কন্টেইনারগুলি তৈরি করেন তা ব্যবহার করুন।
কম্পাইল করা ফাইলগুলি পান এবং নিশ্চিত করুন যে তারা পরীক্ষার জন্য HTTP এর মাধ্যমে উপলব্ধ।
আমাদের ক্ষেত্রে, আমরা বিকল্প 2 ব্যবহার করি: আমরা অ্যাপ্লিকেশানটিকে স্ট্যাটিক ফাইল হিসাবে স্থাপন করি, তাই আমরা E2E কাজ চলাকালীন বিল্ট ফাইলগুলি পরিবেশন করার জন্য একটি ডেডিকেটেড কন্টেইনার তৈরি করি।
আমরা আমাদের সিআই চালানোর জন্য একটি প্ল্যাটফর্ম হিসাবে গিটল্যাব ব্যবহার করি। গিটল্যাবের প্রতিটি কাজ আপনার পছন্দের একটি চিত্র সহ একটি পাত্রের ভিতরে চালানো হয়। প্রধান ধারক ছাড়াও, আপনি পরিষেবাগুলি সংজ্ঞায়িত করতে পারেন: আপনার পরীক্ষার পাশাপাশি চলমান অতিরিক্ত পাত্রে। কনফিগারেশন যেমন সহজ:
<job-name>: services: - name: <image> alias: <container-url>
উপলভ্য বিকল্পগুলি আপনার ডকার কম্পোজের মতই, তবে সেগুলি আরও সীমিত।
গিটল্যাব কনফিগারেশনে একটি "গোটচা" হল ভেরিয়েবল FF_NETWORK_PER_BUILD
1 এ সেট করা যদি আপনি পরীক্ষা চলাকালীন পরিষেবাগুলিকে একে অপরের অ্যাক্সেসের অনুমতি দিতে চান।
কিছু সময়ে, আমরা একটি কাজের ভিতরে সমান্তরালভাবে সমস্ত পরীক্ষা চালাচ্ছিলাম। সেই সময়ে, আরও শক্তিশালী বিচ্ছিন্নতা প্রয়োগ করা প্রয়োজন ছিল - প্রতিটি পরীক্ষা একই ব্যাকএন্ড এবং ডাটাবেস ব্যবহার করছিল।
এই সমস্যাটি মোকাবেলা করার জন্য, আমরা আমাদের পরীক্ষাগুলিকে আপগ্রেড করেছি যা আমরা প্রাথমিকভাবে পরীক্ষার before
অংশের ভিতরে ইনজেকশন করি এমন র্যান্ডম ডেটার উপর নির্ভর করে। এটি অন্যান্য থ্রেডে ঘটতে থাকা অন্যান্য পরিবর্তনগুলির দ্বারা প্রভাবিত না হয়ে পরীক্ষা চালানোর অনুমতি দেয়।
এই পদ্ধতিটি প্রথমে কিছুটা কঠিন হতে পারে, তবে এটি আপনার পরিস্থিতির উপর নির্ভর করে অর্থপূর্ণ হতে পারে।
যদিও আমরা প্রতিটি পরীক্ষার কাজের জন্য একটি নতুন ডাটাবেস শুরু করি, তবুও আমরা আমাদের পরীক্ষাগুলিকে সেই অবস্থায় রেখে দেওয়ার চেষ্টা করছি যেভাবে তারা এটি পেয়েছে৷ যখন আমরা একটি ভাগ করা পরিবেশে পরীক্ষা চালাচ্ছিলাম তখন হয়তো এটি কিছুটা অবশিষ্ট ছিল।
এটি আর গুরুত্বপূর্ণ নয়, তবে এটি এখনও নিম্নলিখিত ক্ষেত্রে পরীক্ষার বিকাশের সময় সাহায্য করতে পারে:
এমন কিছু ক্ষেত্রে আছে যখন একটি পাত্রে পরিষেবাগুলি সরানো একটি বিকল্প নয়। উদাহরণ স্বরূপ:
উভয় ক্ষেত্রেই, টেস্ট রানগুলিকে আলাদা করার জন্য, আপনি সেই পরিষেবাগুলিতে যাওয়া অনুরোধগুলিকে উপহাস করতে পারেন৷ এটি আপনার পরীক্ষার ফলাফলগুলিকে প্রভাবিত করা থেকে অপ্রত্যাশিত বাহ্যিক পরিষেবাগুলিকে রাখবে৷ এই পদ্ধতির একটি নেতিবাচক দিক হল যে আপনার পরীক্ষাগুলি সেই প্রেক্ষাপট থেকে সংযোগ বিচ্ছিন্ন করবে যেখানে আপনার অ্যাপ্লিকেশনগুলি কাজ করে।
উপহাসের জায়গায়, আপনার পরীক্ষাগুলি সেই ক্ষেত্রে ধরা পড়বে না যখন সেই পরিষেবাগুলির পরিবর্তনগুলি আপনার আবেদনকে প্রভাবিত করবে।
আপনি যদি পরীক্ষা বা অন্যান্য প্রোগ্রামিং-সম্পর্কিত বিষয় সম্পর্কে আরও জানতে আগ্রহী হন, আমি যখন সম্পর্কিত বিষয়বস্তু প্রকাশ করি তখন আপনি আপডেট পেতে এখানে সাইন আপ করতে পারেন।