যখন কোনও বাগ উত্পাদনে পাওয়া যায় তখন আমি কি ইচ্ছাকৃতভাবে বিল্ডটি ভাঙতে পারি?


410

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

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

এই দৃশ্য পরিচালনা করার জন্য কি অন্য কারও কাছে প্রমাণিত কৌশল আছে? আমি বুঝি ইচ্ছাকৃতভাবে বিল্ডটি ভাঙ্গা অন্যান্য দলের সদস্যদের জন্য বিঘ্নজনক হতে পারে, তবে এটি সম্পূর্ণরূপে আপনি কীভাবে শাখা ব্যবহার করছেন তার উপর নির্ভর করে।


75
+1 টি; একটি খুব উত্তেজক প্রশ্ন। আমি উভয় পক্ষের দেখতে পারেন।
কার্ল ম্যানাস্টার

28
আপনি "পরীক্ষা" অন্তর্ভুক্ত করতে "বিল্ড" শব্দটি ব্যবহার করেন যা সর্বজনীন বোঝাপড়া নয়।
জে বাজুজি

19
আপনার করছেন TDD- এ আপনি ব্যর্থ পরীক্ষা লিখতে হবে, তাহলে কোড ঠিক এবং তারপর চেক-ইন । সুতরাং আপনি একটি ভাঙ্গা বিল্ড এড়ানো।
ডায়েটবুদ্ধ

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

উত্তর:


412

আমাদের কৌশলটি হ'ল:

একটি ব্যর্থ পরীক্ষায় চেক করুন, তবে এটি দিয়ে বারণ করুন @Ignore("fails because of Bug #1234")

এইভাবে, পরীক্ষা আছে, কিন্তু বিল্ডটি ভাঙে না।

অবশ্যই আপনি বাগ ডিবিতে উপেক্ষা করা টেস্টটি নোট করুন, সুতরাং @Ignoreপরীক্ষাটি ঠিক হয়ে যাওয়ার পরে এটি সরানো হবে। এটি বাগ বাগের জন্য সহজ চেক হিসাবে কাজ করে।

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

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


150
+1 আমি মনে করি আপনি "সিদ্ধান্ত নির্ধারণ একটি ব্যবসায়ের সিদ্ধান্ত" দিয়ে মাথার পেরেকটি আঘাত করেছেন - একজন বিকাশকারী হিসাবে কোনও বাগটি ভেঙে দেয় কিনা তা সিদ্ধান্ত নেওয়ার সিদ্ধান্ত নেওয়া আমার রায় নয়।
ম্যাটড্যাভি

22
আমি মনে করি এটি একটি খুব বুদ্ধিমান সমাধান। বিশেষ করে যদি পরের লোকটি কিছু ছোটখাটো কোড চেক করে, হঠাৎ করে একটি "ব্যর্থ পরীক্ষা" নোটিশ পেয়ে যায় এবং মনে করে যে সে কিছু করেছে।
হোলার

14
"আমার কাছে, একবার বাগ ডিবিতে একটি বাগ ফাইল করা হলে, এটি আর আমার সমস্যা হয় না" ... +1
জ্যাক বার্গার

20
টনোটায় অ্যান প্রেরিত একটি লাইন কর্মী একটি ত্রুটি দেখেন, তারপরে অ্যান্ডন কর্ডটি টানেন এবং পুরো উদ্ভিদটি থামে এবং পরিচালনা আসে এবং সমস্যাটি স্থির না হওয়া অবধি লাইনটি পুনরায় আরম্ভ করা হয় না। গুগল অ্যান্ডন কর্ড এটি কোনও নতুন ধারণা নয়। দেখুন: startuplessonslearned.com/2008/09/…
ক্রিস্টোফার মহান

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

106

আপনি কেন কোনও ত্রুটিযুক্ত ত্রুটিগুলি সহ কোনও বিল্ডকে সফল হতে দিতে চান?

কারণ মাঝে মাঝে আপনার সময় সীমাবদ্ধতা থাকে। বা বাগটি এতটাই নাবালক যে এটি পরীক্ষা করার জন্য এটি ঠিক করার জন্য কিছু দিনের জন্য পণ্যটির চালানের জন্য বিলম্ব করা সত্যিই উপযুক্ত নয়।

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


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

3
আমার উত্তরের দ্বিতীয় অনুচ্ছেদ দেখুন।
আর্সেনি মরজেনকো

8
আমি বুঝতে পেরেছি, আমি মনে করি আপনার প্রথম অনুচ্ছেদে বিন্দুটি সংক্ষিপ্ত করা হয়েছে - এটি বাগের গাম্ভীর্যতা বিচার করা বা এটি কোনও শো-স্টপার কিনা, এটি বিস্তৃত ব্যবসায়ের সিদ্ধান্ত it's
ম্যাটডি ডেভি

4
প্রশ্ন এই বাগের অগ্রাধিকার কি? এটি এখনই একটি ওএমজি ফিক্স আইটি হতে পারে এটি হ্যাঁ বিরক্তিকর হতে পারে আমরা একে একে ঠিক করা উচিত এটি মাঝামাঝি কিছু হতে পারে। তবে সমস্ত বাগগুলি সেই বর্ণালীতে একই জায়গায় আঘাত করবে না।
জাচারি কে

55

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


20
"ব্যর্থ পরীক্ষার
তালিকাগুলি

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

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

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

@ ওয়ারেনপি, মাঝে মাঝে অন্যান্য সমস্যাও রয়েছে তবে আসুন পরিষ্কার হয়ে যাক, অযত্নতা বিরতি কেন প্রথম কারণ break যদি আপনি জানেন যে কোনও কিছু বিল্ডটি ভেঙে দেয় তবে কেন এটি পরীক্ষা করে দেখুন?
এপ্রোগ্রামার

23

"বিল্ডটি ভাঙ্গুন" এর অর্থ একটি বিল্ডটিকে সফলভাবে শেষ হতে বাধা দেওয়া । একটি ব্যর্থ পরীক্ষা এটি করে না। এটি একটি ইঙ্গিত যে বিল্ডটি ত্রুটিগুলি সনাক্ত করেছে, যা ঠিক সঠিক।

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


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

2
বিল্ডটি ব্যর্থ হয়েছে বলে আমি সর্বদা একটি ব্যর্থ পরীক্ষা বিবেচনা করি।
জন স্যান্ডার্স 19

@ জনসন্ডার্স: তবে এর অর্থ এটি নয়। আমি আমার উত্তরে যেমন বলেছিলাম, এর অর্থ "বিল্ডটি ত্রুটিগুলি জানেছে"।
বেন ভয়েগট

1
@ কে বলেছিল কোন পরীক্ষা নেই? আপনি এটি কোথায় পাবেন? আমি বোঝাতে চাইছি বাগটি খুঁজে পাওয়ার পরে আমার প্রথম পদক্ষেপটি বিল্ডটিকে সফল হতে আটকাতে নয়, বরং একটি বিশদ বাগ রিপোর্ট তৈরি করা। বাগটি ঠিক করা হচ্ছে, প্রথমে একটি ব্যর্থ ইউনিট পরীক্ষা করা উচিত।
জন স্যান্ডার্স

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

16

আমি যুক্তি দিয়ে বলব যে ব্যর্থ পরীক্ষাটি যুক্ত করা উচিত, তবে "ব্যর্থ পরীক্ষা" হিসাবে স্পষ্টভাবে নয়।

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

এই পরিস্থিতিতে নিজেকে যা জিজ্ঞাসা করা উচিত তা হ'ল,

পরীক্ষাগুলি সম্পাদন বলতে কী বোঝায়?

যদি পরীক্ষাগুলি কেবলমাত্র কোড সম্পর্কে প্রত্যেককে ভাল মনে করার জন্য থাকে তবে কোড সম্পর্কে সবাইকে খারাপ মনে করার জন্য একটি ব্যর্থ পরীক্ষা যুক্ত করা ফলপ্রসূ মনে হয় না। তবে তারপরে, পরীক্ষাগুলি প্রথম স্থানে কতটা উত্পাদনশীল?

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

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

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

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

এটিকে অন্যভাবে বলতে ... বিল্ডটি ইতিমধ্যে ভেঙে গেছে। আপনি যে সমস্ত সিদ্ধান্ত নিচ্ছেন তা হ'ল এই সত্যটির দিকে মনোযোগ দিন।


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

@ জনবুকানন: যাচাই করার জন্য পরীক্ষাগুলি কী বোঝায়, যদি না হয় যে সফ্টওয়্যারটি যা করার কথা বলেছে তা করছে? (এটি হ'ল এটি প্রয়োজনীয়তাগুলি মেটায় state) আপনি যেমন উল্লেখ করেছেন ইউনিট পরীক্ষার বাইরেও অন্যান্য রূপ রয়েছে tests তবে আমি ইউনিট পরীক্ষাগুলির মান দেখতে ব্যর্থ হয়েছি যা সফ্টওয়্যারটি ব্যবসায়ের প্রয়োজনীয়তা পূরণ করে তা যাচাই করে না।
ডেভিড

1
@ জনবুকানান - তিনি বলেননি "পরীক্ষাগুলি ব্যবসায়ের প্রয়োজনীয়তার প্রতিচ্ছবি", তিনি বলেছিলেন "হওয়া উচিত"। যা সত্য তবে বিতর্কযোগ্য। আপনি দাবী করে ঠিক বলেছেন যে এটি সর্বদা হয় না - কিছু লোক এমন ইউনিট পরীক্ষা লিখেন যা ব্যবসায়ের প্রয়োজনীয়তার মানচিত্র দেয় না - যদিও (আমার মতে) তারা এটি করা ভুল wrong আপনি যদি দাবি করতে চান যে ডেভিডের দৃser় বক্তব্য ভুল, আপনি কেন এমনটি মনে করেন সে সম্পর্কে আপনি কিছু বলতে পারেন।
দাউদ ইবনে কেরেম

13

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


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

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

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

7

আপনারা জানেন এমন একটি পরীক্ষা লিখতে যতক্ষণ না বাগটি স্থির হয় ততক্ষণ পর্যন্ত ব্যর্থ হবে এটি টিডির ভিত্তি।

বিল্ড ভাঙা একটি খারাপ ধারণা। কেন? কারণ এর অর্থ হ'ল এটি স্থির না হওয়া পর্যন্ত কিছুই চলতে পারে না। এটি মূলত উন্নয়নের অন্যান্য সমস্ত দিককে অবরুদ্ধ করে।

উদাহরণ 1
যদি আপনার অ্যাপ্লিকেশনটি বিভিন্ন উপাদান সহ বড় আকারের হয়? কী যদি সেই উপাদানগুলি অন্যান্য দলগুলি তাদের নিজস্ব প্রকাশের চক্র নিয়ে কাজ করে? শক্ত! তাদের আপনার বাগ ফিক্সের জন্য অপেক্ষা করতে হবে!

উদাহরণ 2
যদি প্রথম বাগটি ঠিক করা শক্ত হয় এবং আপনি একটি উচ্চ অগ্রাধিকার সহ অন্য বাগটি খুঁজে পান তবে কী হবে ? আপনি কি দ্বিতীয় বাগের জন্য বিল্ডটি ভেঙে দেন? উভয় স্থির না হওয়া পর্যন্ত আপনি নির্মাণ করতে পারবেন না । আপনি একটি কৃত্রিম নির্ভরতা তৈরি করেছেন।

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


5

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


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

@ সালস্ক যে আদর্শ হবে, আমি কেবল নিশ্চিত হতে চাই যে ব্যর্থতা উপেক্ষা করে স্বয়ংক্রিয়ভাবে সাফল্যে পরিণত হয় না
প্রুশওয়ান

ইয়েলও বিল্ডস নেই? (লাল / সবুজ / হলুদ) হডসন / জেনকিন্স, ক্রুজ কন্ট্রোল এবং অন্যান্য সমস্ত বিগিজিতে?
ওয়ারেন পি

@ ওয়ারেন পি এটি কাজ করে যখন লোকেরা পরীক্ষাগুলি সঠিকভাবে উপেক্ষা করে, কিন্তু কেউ কেউ পরীক্ষাগুলিকে সবুজ করে উপেক্ষা করে
প্রসওয়ান

5

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

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

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


5

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

আপনি আপনার দলটিকে সেই মানসিকতায় আসতে সহায়তা করতে চান না।

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


1
আপনার পরীক্ষার সফ্টওয়্যারটি আপনাকে জানাতে হবে যখন কখন নতুন কিছু ভেঙে গেছে, বনাম এমন একটি পরীক্ষা যা আগে ব্যর্থ হয়েছিল।
বেন ভয়েগট

4

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

অতএব আমি বলব যে এটি একটি মুলতুবি পরীক্ষা হিসাবে প্রতিশ্রুতিবদ্ধ করা আরও ভাল, এবং পরীক্ষাটি মুলতুবি না করে এটিকে আপনার দলে অগ্রাধিকার দিন।


4

অন্য বিকল্পটি হ'ল ব্যর্থ পরীক্ষাটি আপনার উত্স নিয়ন্ত্রণ সিস্টেমের একটি পৃথক শাখায় পরীক্ষা করা। আপনার অনুশীলনের উপর নির্ভর করে এটি व्यवहार्य হতে পারে বা নাও হতে পারে। আমরা মাঝে মধ্যে চলমান কাজের জন্য একটি নতুন শাখা খুলি, যেমন কোনও ত্রুটিযুক্ত নয় এমন কোনও বাগ সংশোধন করা।

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