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

Question

আমি ধর্মীয়ভাবে টিডিডি অনুসরণ করি। আমার প্রকল্পগুলিতে অর্থবোধক পরীক্ষার ক্ষেত্রে সাধারণত 85% বা আরও ভাল টেস্ট কভারেজ থাকে।

আমি কাজ অনেক কাজ HBase , এবং প্রধান ক্লায়েন্ট ইন্টারফেস, HTable, একটি বাস্তব ব্যথা উপহাস হয়। লাইভ এন্ডপয়েন্ট ব্যবহার করে এমন পরীক্ষাগুলি লেখার চেয়ে আমার ইউনিট পরীক্ষাগুলি লিখতে আমাকে 3 বা 4 গুণ বেশি সময় লাগে।

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

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

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

আপনি সব কি মনে করেন?

Comments

লাইভ এন্ডপয়েন্টটি আসলেই কোনও ইউনিট পরীক্ষা নয়, তাই না? এটি একটি ইন্টিগ্রেশন টেস্ট। তবে শেষ পর্যন্ত সম্ভবত এটি ব্যবহারিকতার প্রশ্ন; আপনি হয় উপহাস লেখার সময় ব্যয় করতে পারেন, বা বৈশিষ্ট্যগুলি লেখার জন্য বা বাগগুলি ঠিক করার জন্য সময় ব্যয় করতে পারেন।

— রবার্ট হার্ভে

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

আপনি খারাপ মানুষ নন। আপনি খুব ভাল লোক খারাপ কাজ করছেন।

— ক্যারলেস

আমি টিডিডিটিকে ধর্মীয়ভাবে অনুসরণ করি হয়তো সমস্যা? আমি মনে করি না এই পদ্ধতি কোন ব্যবস্থা গ্রহণ করা বোঝানো হয় না যে গম্ভীরভাবে। ;)

— হতাশ

ধর্মীয়ভাবে টিডিডি অনুসরণ করার অর্থ আপনি 15% অনাবৃত কোডটি বাতিল করবেন।

— mouviciel

Answer 1

• আমার প্রথম সুপারিশটি হ'ল আপনার নিজের মতো মক ধরণের জিনিসগুলি না রাখাই । আপনি এইচটিএবলকে বিদ্রূপের জন্য সত্যিকারের ব্যথা বলে উল্লেখ করেছেন - সম্ভবত এটির পরিবর্তে আপনাকে এমন অ্যাডাপ্টারে মুড়ে ফেলা উচিত যা আপনার প্রয়োজন এমন HTable এর 20% বৈশিষ্ট্য প্রকাশ করে এবং যেখানে প্রয়োজন সেখানে মোড়ককে বিদ্রূপ করবে।

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

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

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

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

Comments

+1 আমি মক টেস্টের সাথে এজ কেসগুলির সাথে ডাটাবেসকে পপুলেশন করার চেয়ে কিনারা তৈরি করা অনেক সহজ বলে মনে করি find

— রব

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

— সাংফ্রয়েড

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

— সাংফ্রয়েড

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

— সাঙ্গফ্রয়েড

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

— guillaume31

Answer 2

দার্শনিকভাবে, যে পরীক্ষাগুলি মক ব্যবহার করে তাদের লাইভ এন্ডপয়েন্ট ব্যবহার করে এমন পরীক্ষাগুলির চেয়ে অগ্রাধিকার নেওয়া উচিত

আমি খুব অন্তত মনে করি, একটি বিন্দু যে বর্তমান চলমান বিতর্ক TDD- এ প্রবক্তারা মধ্যে।

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

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

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

দুর্ভাগ্যক্রমে, মক-বেসড টেস্টিংয়ের আরও অনেক বেশি সাধারণ ব্যবহার হ'ল পরীক্ষা:

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

এই ধরনের পরীক্ষা অবশ্যই দৃষ্টিতে মুছে ফেলা উচিত।

Comments

আমি এটিকে যথেষ্ট ব্যাক আপ করতে পারি না। আমি বরং ফিলারের 100 পিসি কভারেজের চেয়ে দুর্দান্ত পরীক্ষার সাথে 1 পিসি কভারেজ পাই।

— আয়ান

মক-ভিত্তিক পরীক্ষাগুলি 2 টি অবজেক্টের সাথে একসাথে কথা বলার জন্য ব্যবহৃত চুক্তিকে বর্ণনা করে তবে তারা জাভার মতো ভাষার টাইপ সিস্টেম কী করতে পারে তার চেয়ে অনেক বেশি এগিয়ে যায়। এটি কেবল পদ্ধতি স্বাক্ষর সম্পর্কিত নয়, তারা আর্গুমেন্ট বা প্রত্যাবর্তিত ফলাফলের জন্য মানগুলির বৈধ ব্যাপ্তিগুলিও নির্দিষ্ট করতে পারে, যেগুলি ব্যতিক্রমগুলি গ্রহণযোগ্য, কোন ক্রমে এবং কতবার পদ্ধতিগুলি কল করা যেতে পারে ইত্যাদি etc. তাদের মধ্যে পরিবর্তন হয়। সে অর্থে আমি ভাবি না যে তারা মোটেও অতিরিক্তহীন। মোক -ভিত্তিক পরীক্ষাগুলি সম্পর্কে আরও তথ্যের জন্য infoq.com/preferencesations/integration-tests-scam দেখুন ।

— guillaume31

... সম্মত হন মানে ইন্টারফেস কলটির চারদিকে যুক্তি পরীক্ষা করা

— রব

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

— soru

"তাদের স্পেসিফিকেশন অন্তর্নিহিত": আপনি যদি আপনার ইন্টারফেসের জন্য চুক্তি পরীক্ষাগুলি লিখেন না ( blog.thecodewhisperer.com/2011/07/07/contract-tests-an-example ) এবং বিদ্রূপ স্থাপনের সময় সেগুলিতে লেগে থাকুন ।

— guillaume31

Answer 3

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

Answer 4

আমি গুইলিউম ৩১ এর প্রতিক্রিয়াতে সম্পূর্ণরূপে একমত, আপনার নিজের মতো নয় এমন প্রকার কখনও উপহাস করবেন না !.

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

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

আয়ানের কুপারের এই টক ফর্মটি একবার দেখুন: http://vimeo.com/68375232 , তিনি ষড়ভুজ আর্কিটেকচার এবং পরীক্ষার বিষয়ে কথা বলেছেন, কখন এবং কী উপহাস করবেন সে সম্পর্কে তিনি কথা বলেন, সত্যই অনুপ্রাণিত একটি কথা যা সত্যিকারের টিডিডি সম্পর্কে আপনার মতো অনেক প্রশ্নের সমাধান করে talk ।

Answer 5

টিএল; ডিআর - আমি এটি যেভাবে দেখছি, এটি নির্ভর করে যে আপনি পরীক্ষাগুলিতে ব্যয় কতটা করেছেন এবং তার পরিবর্তে আপনার প্রকৃত সিস্টেমে আরও বেশি ব্যয় করা ভাল ছিল কিনা তার উপর নির্ভর করে।

দীর্ঘ সংস্করণ:

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

উদাহরণস্বরূপ, আমি পরীক্ষাগুলি থেকে প্রাপ্ত কয়েকটি প্রধান মান হ'ল:

• নির্ভরযোগ্যতা (এবং সেইজন্য উন্নয়নের গতি): রিফ্যাক্টর কোড / একটি নতুন কাঠামো সংহত করে / একটি উপাদান / পোর্টকে অন্য প্ল্যাটফর্মে অদলবদল করে, আত্মবিশ্বাসী হন যে স্টাফগুলি এখনও কাজ করে
• নকশা প্রতিক্রিয়া: ক্লাসিক টিডিডি / বিডিডি আপনার নিম্ন / মধ্য স্তরের ইন্টারফেসের জন্য "আপনার কোড ব্যবহার করুন" প্রতিক্রিয়া

লাইভ এন্ডপয়েন্টের বিরুদ্ধে পরীক্ষা করা এখনও এই সরবরাহ করা উচিত।

লাইভ এন্ডপয়েন্টের বিরুদ্ধে পরীক্ষার জন্য কিছু ত্রুটি:

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

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

Answer 6

একটি পরীক্ষার দৃষ্টিকোণ থেকে কিছু প্রয়োজনীয়তা যা পরম অবশ্যই:

• পরীক্ষার (ইউনিট বা অন্যথায়) কখনই উত্পাদন ডেটা স্পর্শ করার উপায় থাকতে হবে না
• একটি পরীক্ষার ফলাফলগুলি কখনই অন্য পরীক্ষার ফলাফলগুলিকে প্রভাবিত করে না
• আপনার অবশ্যই সর্বদা একটি পরিচিত অবস্থান থেকে শুরু করা উচিত

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

• ইউনিট পরীক্ষা চলাকালীন টেস্ট কনফিগারেশন স্বয়ংক্রিয়ভাবে নির্বাচিত হয়েছিল
• চলমান ইউনিট পরীক্ষার শুরুতে ডাটাবেসটি তৈরি এবং সূচনা করা হয়েছিল
• ইউনিট পরীক্ষা চালানোর পরে ডাটাবেসটি মুছে ফেলা হয়েছিল
• যদি স্কেললাইট ব্যবহার করা হয়, পরীক্ষার কনফিগারেশনটিতে একটি র‌্যাম ডাটাবেস ব্যবহার করা হয়েছে

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

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

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