টিডিডি করার সময় আমাদের কি লগিং দরকার?


40

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

তবে লগিংয়ের কী হবে?

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

সুতরাং আমার প্রশ্নগুলি হ'ল:

  1. আমরা যদি টিডিডি করি তবে লগ করার দরকার কি? একটি ব্যর্থ পরীক্ষা আবেদনটির সাথে কী ভুল প্রকাশ করবে না?
  2. আমাদের প্রতিটি ক্লাসে প্রতিটি পদ্ধতিতে লগিং প্রক্রিয়াটির জন্য পরীক্ষা যুক্ত করা উচিত?
  3. উদাহরণস্বরূপ, যদি কিছু লগের স্তর উত্পাদন পরিবেশে অক্ষম থাকে, তবে এটি পরীক্ষা এবং পরিবেশের মধ্যে নির্ভরতা প্রবর্তন করবে না?
  4. লগগুলি কীভাবে ডিবাগিং সহজতর করে সে সম্পর্কে লোকেরা কথা বলে, তবে টিডিডি সম্পর্কে একটি প্রধান সুবিধা হ'ল আমি সবসময় জানি যে একটি ব্যর্থ পরীক্ষার কারণে কী ভুল।

আমি কি এখানে কিছু মিস করছি?


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

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

উত্তর:


50

1) আমরা টিডিডি করছি যদি আমাদের লগ করা প্রয়োজন? একটি ব্যর্থ পরীক্ষা আবেদনটির সাথে কী ভুল প্রকাশ করবে না?

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

2) আমাদের প্রতিটি ক্লাসে প্রতিটি পদ্ধতিতে লগিং প্রক্রিয়ার জন্য পরীক্ষা যুক্ত করা উচিত?

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

3) উদাহরণস্বরূপ, যদি কিছু লগের স্তর উত্পাদন পরিবেশে অক্ষম করা হয়, তবে তা পরীক্ষা এবং পরিবেশের মধ্যে নির্ভরতার পরিচয় দেবে না?

মানুষ (এবং লগ এগ্রিগেটর) লগগুলির উপর নির্ভর করে, পরীক্ষাগুলি তাদের উপর নির্ভর করে না। সাধারণত বেশ কয়েকটি লগের স্তর রয়েছে এবং কিছু উত্পাদনে ব্যবহৃত হয় এবং কিছু অতিরিক্ত স্তরগুলি বিকাশে ব্যবহৃত হয়:

"রেল লগ স্তর হ'ল তথ্য এবং উত্পাদন এবং পরীক্ষার ডিবাগ মোডে তথ্য" - http://guides.rubyonrails.org/debugging_rails_applications.html

অন্যান্য অ্যাপ্লিকেশন একই ধরণের পদ্ধতির ব্যবহার করে।

৪) লোকেরা লগগুলি কীভাবে ডিবাগিং সহজতর করে সে সম্পর্কে কথা বলেন, তবে টিডিডি সম্পর্কে একটি প্রধান সুবিধা হ'ল আমি সবসময় জানি যে একটি ব্যর্থ পরীক্ষার কারণে কী ভুল।

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


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

34

কোনও অ্যাপ্লিকেশনটির ব্যতিক্রমী আচরণ ব্যাখ্যা করার জন্য লগিং দরকারী :

সিস্টেমের ক্রিয়াকলাপ বোঝার জন্য এবং সমস্যাগুলি নির্ণয়ের জন্য ব্যবহার করা যেতে পারে এমন একটি নিরীক্ষণ ট্রেল সরবরাহ করার জন্য ইভেন্ট লগগুলি সিস্টেমের প্রয়োগে ঘটে যাওয়া ইভেন্টগুলি রেকর্ড করে । জটিল সিস্টেমগুলির ক্রিয়াকলাপগুলি বোঝার জন্য এগুলি প্রয়োজনীয়, বিশেষত অল্প ব্যবহারকারীর ইন্টারঅ্যাকশন (যেমন সার্ভার অ্যাপ্লিকেশন) সহ অ্যাপ্লিকেশনগুলির ক্ষেত্রে ...

অ্যাপ্লিকেশনটি কীভাবে পরীক্ষা করা হয়েছিল এবং ব্যতিক্রমগুলি কতটা ভালভাবে লগ করা হয়েছে তা বিবেচনা না করেই এর ব্যবহারকারীরা জিজ্ঞাসা করতে পারেন,

আপনার প্রোগ্রামটির আউটপুট 0 হবে যখন আমরা এটি 1 হওয়ার প্রত্যাশা করছিলাম, তা কেন?

অ্যাপ্লিকেশন কনফিগারেশন, প্যারামিটার এবং অন্যান্য রানটাইম বিশদটি এর (অ-ব্যতিক্রমী) আচরণটি ব্যাখ্যা করতে যাচাই করতে আপনাকে লগিং করতে হবে need

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

অ্যাপ্লিকেশনটি কী করে লগইন করে অন্য কেউ কোডটি খনন না করে এবং বিকাশকারীদের বিরক্ত না করে কী চলছে তা ব্যাখ্যা করার জন্য অনুরোধ করে প্রোগ্রামের আচরণ বুঝতে পারে।


5
"সহায়তায় লগিং আরও ভিত্তিক" এর জন্য +1। সত্যিই মাথায় পেরেকটি আঘাত করুন।
টিবিস

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

উদ্ধৃতি -এর @logc উৎস এখানে প্রথম শব্দ লিঙ্কের মাধ্যমে উল্লেখ করা হয়, "লগিং" - যদি আপনি এটি ক্লিক করুন, আপনার উইকিপিডিয়া প্রবন্ধ আনতে হবে: en.wikipedia.org/wiki/Logfile
মশা

16

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

অবশ্যই একটি পারফরম্যান্স সমালোচনা সিস্টেম কিছু অপারেশনাল ড্যাশবোর্ডে কী পারফরম্যান্স মেট্রিক সরবরাহ করতে পারে / উচিত, তবে "ক্লাসিক" লগিং বিভিন্ন স্তরের বিশদ সরবরাহ করতে পারে।


2
অডিট ট্রেইল উদ্দেশ্যে লগিং সম্পর্কে ভুলবেন না। বা বিলিং বা বিভিন্ন ধরণের পরিসংখ্যান। বা অন্যান্য সিস্টেমের অন্যান্য ধরণের পরিসংখ্যানের সাথে মিলে যাওয়ার জন্য ইভেন্ট লগিং।
প্লাজমাএইচএইচ

লগইন না করে আপনি এমন কিছু প্রোফাইলিং করছেন না? বা আপনি কি কেবল বোঝাতে চেয়েছেন যে আপনি ক্রমাগত প্রোফাইলিংয়ের ফলাফলগুলি লগ করতে পারেন?
বার্গি

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

@ বার্গি প্রোফাইলিং বিকাশের ক্ষেত্রে ঘটে তবে লাইভ সিস্টেমে এগুলির প্রভাবগুলি মনে রাখা হয়, ডিস্ক ব্যবহার করা ধীর হয়ে যেতে পারে, সিপিইউ আরও বেশি লোড হতে পারে, পরিষেবাগুলি সময় মতো প্রতিক্রিয়া জানাতে পারে না, সমান্তরাল থ্রেডগুলি লকিং ইস্যুতে চালিত হতে পারে ...
johannes

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

8

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

যেহেতু আপনি আপনার সিস্টেমে আপনার ভুল আচরণ করবে কিনা তা আপনি জানেন না, সম্ভবত বিরল পরিস্থিতিতে, লগিং একটি দরকারী সরঞ্জাম যা যখন অনিবার্যভাবে ভুল হয়ে যায় তখন কী ভুল তা বুঝতে সাহায্য করতে পারে।

লগিং এবং টিডিডি বিভিন্ন উদ্বেগের সমাধান করে।


7
  1. আপনার যদি 100% পরীক্ষার কভার থাকে না, যা সাধারণত হয় না, আপনি জানতে পারবেন না যে আপনার সফ্টওয়্যারটি কখনই ক্রাশ হবে না (EDIT: এবং - মন্তব্যে যেমন বলা হয়েছে - এমনকি যদি এটি হয় তবে আপনার সফ্টওয়্যার থেকে আলাদা কিছু হতে পারে একটি দুর্ঘটনা); এটি ভাবনার মতোই আপনি এমন কোনও সফ্টওয়্যার করতে পারেন যাতে কোনও বাগ নেই (এমনকি নাসা এটিও করতে পারে না)। সুতরাং খুব কমপক্ষে, আপনার প্রোগ্রামটি ক্রাশ হওয়ার ক্ষেত্রে আপনাকে সম্ভাব্য ব্যর্থতাগুলি লগ করতে হবে যাতে আপনি জানতে পারবেন কেন।

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

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

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


3
এমনকি যদি আপনার কাছে 100% কভারেজ থাকে তবে এটি ঘটতে পারে এমন প্রতিটি জিনিসের জন্য কি আপনার কাছে রয়েছে? আপনার ডাটাবেসের সাথে নেটওয়ার্ক সংযোগ নিচে গেলে কী হবে? আপনার পরীক্ষা কি তা বলবে?
জাচারি কে

আপনার 100% কভারেজ থাকলে আপনি কখনই জানতে পারবেন না আপনার সফ্টওয়্যার কখনই ইভেন ক্র্যাশ হবে না। ১০০% কভারেজ, যখন আকাঙ্ক্ষিত, ততটুকু সঠিকতার চেয়ে কম তথ্য দেয় যা মনে হয়।
আন্দ্রেস এফ।

হ্যাঁ, আপনি এটি সম্পর্কে ঠিক বলেছেন। মুল বক্তব্যটি হ'ল ক্র্যাশ হওয়ার কোনও সম্ভাবনা থাকা সম্ভব নয়। আমি সম্পাদনা করব।
পিয়ের আরলাড

1
সম্পাদনাটি এখনও ভুল। আপনার যদি 100% পরীক্ষার কভারেজ থাকে তবে আপনার কোডে একটি বাগ থাকতে পারে (বাহ্যিক কারণগুলির জন্য দোষ দেওয়ার প্রয়োজন নেই)। টেস্টগুলি আপনার কোডের কাজ বোঝায় না; তারা যে কোনও দৃty়তার সাথে বোঝায় কেবল তা হ'ল আপনি কোনও পরীক্ষা লিখতে ব্যর্থ হয়েছেন যা বাগ খুঁজে পেয়েছে :) পরীক্ষার কভারেজ একটি গুরুত্বপূর্ণ মেট্রিক, তবে বাগগুলির অনুপস্থিতির সাথে সরাসরি সম্পর্কিত নয়।
আন্দ্রেস এফ।

3
"100% পরীক্ষার কভারেজ যা পাস! = বাগ বিনামূল্যে" তা প্রমাণ করা তুচ্ছ। পাল্টা নমুনা: add(x, y) = 2(সর্বদা 2 প্রদান করে) নিম্নলিখিত পরীক্ষা পাসের এবং সম্পূর্ণ কভারেজ উপলব্ধ: assert(2 == add(1,1))। বগি ফাংশনের জন্য 100% পরীক্ষার কভারেজ :)
আন্দ্রেস এফ।

5

হ্যাঁ, সাধারণ ক্ষেত্রে আপনার লগিং দরকার।

লগিং ডিবাগিং সম্পর্কে নয়। ঠিক আছে, লগিংয়ের একটি অংশটি কখনও কখনও ডিবাগিং সম্পর্কে হয় এবং আপনি যদি সেই অংশটি বিকাশের সময় প্রয়োজন না হয় তবে আপনি এড়িয়ে যেতে পারেন।

তবে লগিংয়ের আরও গুরুত্বপূর্ণ অংশটি রক্ষণাবেক্ষণযোগ্যতা সম্পর্কে। সু-নকশিত লগিং নিম্নলিখিত প্রশ্নের উত্তর দিতে পারে:

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

এই সমস্ত লগ ইন দ্বারা অর্জন করা যেতে পারে। এবং হ্যাঁ, এটি পরিকল্পনা করা এবং ডিজাইন করা এবং পরীক্ষিত হওয়া উচিত, পছন্দের স্বয়ংক্রিয়।

লগিং এমন একটি বৈশিষ্ট্য যা অন্যান্য বৈশিষ্ট্যের মতো চিকিত্সার দাবি রাখে।


4

টিএল; ডিআর: লগিং এবং টিডিডি অরথোগোনাল। একজনের অপরটির প্রয়োজনের কোন ফল নেই aring

আমরা যদি টিডিডি করি তবে লগ করার দরকার কি? একটি ব্যর্থ পরীক্ষা আবেদনটির সাথে কী ভুল প্রকাশ করবে না?

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

এই লগগুলি ইন্টিগ্রেশন পয়েন্টগুলিতে মূলত সমস্যা সমাধানের ক্ষেত্রে সহায়তা করে। এটি নেটওয়ার্ক পরিষেবাদি (ডাটাবেস, সাবান, ইত্যাদি), স্থানীয় সংস্থানসমূহ (ডিস্ক, মেমরি ইত্যাদি), খারাপ ডেটা (গ্রাহক ইনপুট, খারাপ / দুর্নীতিগ্রস্থ ডেটা উত্স, ইত্যাদি) ইত্যাদির ব্যতিক্রম ক্যাপচারিং, লগিং ত্রুটিগুলি এবং এমনকি তথ্যবহুল লগিংও করতে পারে (সেটিংস, কনফিগারেশন ইত্যাদি) সমস্যার সমাধানে সমস্ত সহায়তা করতে পারে।

আমাদের প্রতিটি ক্লাসে প্রতিটি পদ্ধতিতে লগিং প্রক্রিয়াটির জন্য পরীক্ষা যুক্ত করা উচিত?

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

উদাহরণস্বরূপ, যদি কিছু লগের স্তর উত্পাদন পরিবেশে অক্ষম থাকে, তবে এটি পরীক্ষা এবং পরিবেশের মধ্যে নির্ভরতা প্রবর্তন করবে না?

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


3

টিডিডি সাধারণত কোডিং বাগগুলি হ্রাস করতে সহায়তা করে। স্পেসিফিকেশন বা জিনিসগুলি কীভাবে কাজ করে সে সম্পর্কে কেবল ভুল বোঝাবুঝি সহ বাগগুলি নিয়ে এটি অনেক কম সহায়তা করে।

"ওহ? আপনি নিশ্চিত হয়ে যাবার আগে আপনি একটি ডেটা বার্তা পেতে পারেন লগন সফল হয়েছিল? আমি কখনই জানতাম না, এটি এটি পরিচালনা করবে না!" ... এই জাতীয় জিনিস। সফ্টওয়্যারটি যা করার চেষ্টা করেছিল তা আপনাকে বলার জন্য লগিং খুব দরকারী so


2

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

যদিও টিডিডি করার সময় (বা সম্ভবত টেস্ট-যখনই) আমি নিজেকে অনেক কম লগ স্টেটমেন্ট যুক্ত করতে দেখি। এর পরিবর্তে এর অর্থ কম এলওসি এবং (সর্বদা নয়) পারফরম্যান্সকে প্রভাবিত করতে পারে।

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

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


আপনি ফাংশনগুলির জন্য প্রবেশ-বহিরাগত লগগুলি যুক্ত করার কারণে দয়া করে প্রসারিত করতে পারেন? এটি আপনার সংস্থায় কেন প্রয়োজনীয়?
জিনাত

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