স্বয়ংক্রিয় পরীক্ষা কেন আমার সংস্থায় ব্যর্থ হয়?

Question

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

কয়েকটি পর্যবেক্ষণ এবং প্রশ্ন:

1. অটোমেটেড টেস্টিং আসলে কাজ করে? আমার বেশিরভাগ সহকর্মী যারা অন্য সংস্থাগুলিতে কাজ করতেন তাদের বেশিরভাগ চেষ্টা করেছেন এবং একটি স্বয়ংক্রিয় পরীক্ষার কৌশল প্রয়োগ করতে ব্যর্থ হয়েছেন। আমি এখনও রিয়েল-লাইফ সফ্টওয়্যার সংস্থা দেখিনি যা আসলে এটি ব্যবহার করে এবং কেবল এটি সম্পর্কে কথা বলে না। এতগুলি বিকাশকারী অটোমেটেড টেস্টিংকে এমন কিছু হিসাবে দেখেন যা তত্ত্বের ক্ষেত্রে দুর্দান্ত তবে বাস্তবে কার্যকর হয় না। আমাদের ব্যবসায়ের দল বিকাশকারীদের এটি 30% অতিরিক্ত সময় ব্যয় করেও করতে কমবেশি (অন্তত তারা তাই বলে) say তবে ডেভেলপাররা সংশয়বাদী।

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

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

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

এটি আমাদের পক্ষে কাজ করে না কেন? আপনি কীভাবে এটি আপনার সংস্থায় কাজ করেছেন?

Comments

আপনার প্রযুক্তি স্ট্যাক কি?

— ফ্লোরিয়ান মার্জাইন

ওয়েবফোর্ডগুলি সঠিকভাবে ইউনিট পরীক্ষা করা প্রায় অসম্ভব। আপনি একটি পরীক্ষযোগ্য উপাদানটিতে উপস্থাপনা যুক্তি সরাতে একটি এমভিপি (মডেল / ভিউ / উপস্থাপক) প্যাটার্ন ব্যবহার করতে পারেন।

— পিট

@ ম্যাসনওহিলার: উভয় ক্ষেত্রেই আপনি একটি ভয়ংকর যুক্তি তৈরি করেছেন যা এমন জায়গাটিকে অস্বীকার করে যা প্রথম স্থানে গৃহীত হয় নি: অর্থাৎ, সেই ইউনিট পরীক্ষাগুলি নির্ভুলতা প্রমাণের জন্য উপস্থিত রয়েছে।

— স্টিভেন ইভার্স

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

— অ্যালেক্স

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

Answer 1

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

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

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

এখানে বেশ কয়েকটি সংস্থান রয়েছে যা আমি দরকারী পেয়েছি:

http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf

http://www.agitar.com/downloads/TheWayOfTestivus.pdf

সম্পাদনা:

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

Comments

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

— জাস্টিনসি

এছাড়াও, টিডিডি অ্যান্টি-প্যাটার্নগুলি এড়িয়ে চলুন ।

— গ্যারি রোয়ে

মিসকো হেভির কাছে টেস্টেবল কোড লেখার বিষয়ে ইউটিউবে কিছু দুর্দান্ত ভিডিও রয়েছে যা আমি অমূল্য বলে মনে করি। youtube.com/watch?v=acjvKJiOvXw

— দেশপারটার

"পরীক্ষাগুলি দৃশ্যমানতার একটি স্তর পান কিনা তা নিশ্চিত করুন" - এটি সাফল্যের জন্য গুরুত্বপূর্ণ। যদি কেউ দেখতে না পারে যে কীভাবে আপনার পরীক্ষাগুলি সঞ্চালিত হচ্ছে তারা মান দেখতে পাবে না tests পরীক্ষাগুলি একটি অবিচ্ছিন্ন ইন্টিগ্রেশনের অংশ হিসাবে স্বয়ংক্রিয়ভাবে চেক ইন করা উচিত এবং তারপরে রিপোর্ট করা উচিত। আমি টেস্টল্টস ( tesults.com ) এ কাজ করি এবং এটি উপস্থিত থাকার কারণ হ'ল বিশাল প্রভাব পরীক্ষার দৃশ্যমানতা সরবরাহ করে।

— দক্ষতা এম 2

Answer 2

বিভিন্নভাবে আমি আপনার দলের সাথে একমত।

1. সর্বাধিক ইউনিট পরীক্ষাগুলির মান প্রশ্নবিদ্ধ। যেহেতু বিপুল সংখ্যাগরিষ্ঠ পরীক্ষাগুলি খুব সহজ বলে মনে হচ্ছে।

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

3. প্রকৃত কোডের তুলনায় ইউনিট পরীক্ষার কোডটি লিখতে এটি আরও বেশি সময় নিতে পারে।

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

5. ইউনিট পরীক্ষা বজায় রাখতে খুব বেশি সময় লাগে। ছোট পরিবর্তনগুলি বড় রিপল প্রভাব ফেলতে পারে। অটোমেটেড ইউনিট পরীক্ষার প্রধান লক্ষ্য হ'ল পরিবর্তনগুলি কোডটি ভঙ্গ করে কিনা to যাইহোক, বিরতিতে শেষ হওয়া সময়ের 99% হ'ল পরীক্ষাগুলি এবং কোড নয়।

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

ইউনিট টেস্টিংয়ের পাঠ্যপুস্তকে না গিয়ে উপরের কয়েকটিকে কিছুটা ডিগ্রিতে আটকানো যেতে পারে।

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

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

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

Comments

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

— ইজকাটা

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

— ড্যান নীলি

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

— ডাঙ্ক

ভাল ইউনিট পরীক্ষার কভারেজ ব্যতীত, আপনি কীভাবে চুল্লি করবেন? বা রিফ্যাক্টরিং ছাড়াই আপনি কীভাবে কোডটিকে ধীরে ধীরে অবিনশ্বরতায় আটকানোর হাত থেকে আটকাবেন?

— কেভিন ক্লিন

@ লিওনার্দো তারা দেয়নি - তারা কোনও কিছু পরিবর্তন করতে খুব ভয় পেয়েছিল। অথবা তারা সমস্ত প্রযুক্তিগত debtণ সাশ্রয় করেছে এবং কয়েক সপ্তাহ / মাস পরে এটিকে একগুচ্ছের সাথে সম্বোধন করার জন্য রেখে দেয়।

— গ্রিম এফ

Answer 3

মূল অপরাধী হ'ল ডেটাবেসকে মজা / স্ট্যাবিং বা সহজ কিছু নয়।

এবং আপনার সমস্যা আছে।

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

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

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

Comments

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

@ ফেনেক - ইউনিট পরীক্ষাগুলি ডাটাবেস পরীক্ষা করার জন্য নেই, তারা কার্যকরী করার জন্য ডাটাবেস মানগুলির উপর নির্ভর করে এমন কোডটি পরীক্ষা করার জন্য রয়েছে।

— টেলাস্টিন

যতক্ষণ না আপনি ডাটাবেসকে পরিচালনা করে এমন কোডটি ইউনিট-টেস্ট না করা পর্যন্ত সমস্ত কিছু ভাল good : পি যা বহু লোকের জন্য তাদের কোড প্রচুর।

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

— টেলাস্টিন

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

— শিক্ষানবিস কিউ

Answer 4

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

অটোমেটেড টেস্টিং ভাল করার জন্য আপনার এমন একজন ব্যক্তির দরকার যিনি একজন সংস্থান এবং প্রচারক এবং উচ্চ স্তরের পরিচালনাগুলি থেকে কেনা।

অন্য স্বয়ংচালিত প্রকল্পের মতো আপনার স্বয়ংক্রিয় পরীক্ষার বিকাশের আচরণ করুন। নিয়মিতভাবে সম্পূর্ণ পরীক্ষাগুলি উত্পাদন করুন।

মন্তব্য থেকে যোগ করা: এটি ম্যানেজমেন্ট সমস্যা of কোডটি ডকুমেন্ট হওয়ার আগেই কি "সম্পন্ন" হিসাবে বিবেচিত হয়? এটি চেক ইন করার আগে? এটি ইউনিট পরীক্ষা অন্তর্ভুক্ত এবং পাস করার আগে?

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

Comments

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

— জর্জিও

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

— হাফম্যান

@ স্কিপহফম্যান আপনার মন্তব্যটি বর্তমান উত্তরের সম্পাদনা হিসাবে যুক্ত করা উচিত।

— রডু ফ্লোরস্কু

Answer 5

এই গ্রাউন্ড বিধি অনুসরণ করুন। পরীক্ষা:

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

2. আপনি এখনও কেবল সফল হতে চলেছেন যদি এই পরীক্ষাগুলি এখন নিয়মিত চলছে, পথে না চলে । যার মাধ্যমে আমরা পরীক্ষার অর্থ:

   ক। তারা যে মান সরবরাহ করে তা চালানোর জন্য (ব্যক্তিগতভাবে) খুব বেশি সময় নিতে হবে না! আপনার পরীক্ষাগুলি দ্রুত জ্বলুন। লোকেরা যাতে পরীক্ষা চালাতে দেয় যা আপনার সময় নষ্ট হতে চলেছে তা চালিয়ে দেওয়ার জন্য!

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

   গ। প্রকৃত কোড পরীক্ষিতের তুলনায় ঠিক করতে এবং বজায় রাখা কঠিন হবে না। আপনার কোডিং বেগটি আপনার কোডবেজে একটি ক্ষুদ্র এক লাইনের পরিবর্তনের জন্য 10 টি পৃথক পরীক্ষা ঠিক করার দরকার আছে তা সত্যিই চুষে চলেছে।

এবং পরিশেষে, নিয়ম সংখ্যা ৩. টেস্টগুলি কেবল নেতিবাচক মান প্রদান করতে ব্যর্থ হবে না, নিয়ম 2 হিসাবে তাদের অবশ্যই ইতিবাচক মান প্রদান করতে হবে। টেস্ট ...

3. তারা যখন ব্যর্থ হয় তখন অবশ্যই আপনাকে অবশ্যই সে সম্পর্কে কিছু বলছে ! (অস্পষ্ট ত্রুটি বার্তাগুলির সাথে কোনও পরীক্ষা নেই, বা কেবল 'আপনি উইন্ডোজ ২০০ machine মেশিনে পরীক্ষা চালাতে ভুলে গেছেন)' এর মতো হাস্যকর অভিযোগ দেয় না দয়া করে!)।

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

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

• যদি পরীক্ষাগুলি টেকসই না হয় তবে সেগুলি ব্যবহারের মধ্যে পড়ে এবং এর ফলে নষ্ট হয়ে যায়
• যদি পরীক্ষাগুলি টেকসই না হয়, আপনি পরীক্ষা করা বন্ধ করুন, এবং আপনার দল পরীক্ষা করার সময় আরও ভাল হওয়া বন্ধ করে দিয়েছে! এবং, চূড়ান্ত বিষয়:

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

Answer 6

1. এটা কি সত্যিই কাজ করে?

হ্যাঁ, এটি করে - যদি সঠিকভাবে করা হয়। মুল বক্তব্যটি হল ইঞ্জিনিয়াররা নতুন বৈশিষ্ট্যগুলি প্রয়োগ করার পরে পরীক্ষকদের তাদের স্বয়ংক্রিয় স্ক্রিপ্টগুলি সামঞ্জস্য করতে এবং প্রসারিত করতে হবে।

2. কেউ সত্যই অভিজ্ঞ নয় বা কীভাবে সঠিকভাবে স্বয়ংক্রিয় পরীক্ষণ করতে হয় তা জানে না।

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

3.আমাদের সাথে 20 টি ভাল অভিজ্ঞ বিকাশকারী এটি নিয়ে কাজ করে একটি বড় প্রকল্প আছে। সুতরাং ইউনিট টেস্টিং / ইন্টিগ্রেশন টেস্ট চালু করার জন্য এটি দুর্দান্ত পরিবেশ হওয়া উচিত। এটি আমাদের পক্ষে কাজ করে না কেন? আপনি কীভাবে এটি আপনার সংস্থায় কাজ করেছেন?

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

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

Comments

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

— ডাব

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

— ডাঙ্ক

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

— নোহ ইয়েটার

"ইউনিট পরীক্ষায় সময় নষ্ট করবেন না": "" অকেজো ইউনিট পরীক্ষায় সময় নষ্ট করবেন না "হিসাবে আমি এটি পুনরায় লিখব। অন্ধভাবে ইউনিট টেস্টিংয়ের ফলে সময় ব্যয় হয়।

— জর্জিও

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

— এরিক রেপেন

Answer 7

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

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

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

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

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

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

Comments

Introduce automated tests on the unit test level and build automated integration tests on a solid foundation of unit tests.+1

— c69

Answer 8

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

এটি যেটি নেমে আসে তা হ'ল পরীক্ষাগুলির স্যুটটি দল বা একজন পৃথক বিকাশকারীকে উপকৃত করে , বেশিরভাগ সময় পরীক্ষাটি লেখার পক্ষে ব্যয় হয়।

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

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

Answer 9

এটি আকর্ষণীয় যে ব্যবসায়টি ডেভলপারদের চেয়ে প্রো-টেস্টিং! আমার কাছে মনে হচ্ছে আপনার সবচেয়ে বড় চ্যালেঞ্জ হ'ল আপনার বিকাশকারীদের প্রতিরোধের প্রতিরোধকে পরাভূত করা; ইউনিট পরীক্ষার অন্তর্ভুক্ত করার জন্য তাদের তাদের কাজের বোঝার পুনঃ-সংজ্ঞা দেওয়া দরকার।

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

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

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

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

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

Comments

"পরিবর্তনের প্রতি আপনার বিকাশকারীদের প্রতিরোধকে কাটিয়ে উঠুন": প্রতিটি প্রতিরোধ কারণ ছাড়াই হয় না এবং "পরিবর্তনের প্রতিরোধ" আর্গুমেন্টটি ব্যবহার করে সৎ আলোচনা এড়ানো উচিত নয়।

— জর্জিও

Answer 10

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

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

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

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

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

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

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

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

Comments

ইঙ্গিত: টিএল রাখুন; ডিআর: শীর্ষে - আমাকে আপনার পোস্টটি পড়তে হবে কেবল এটিতে! (যা

— কিন্ডাটি

Answer 11

• আপনার সংস্থায় এমন কেউ আছেন যে স্বয়ংক্রিয় পরীক্ষার জন্য বিস্তৃত অভিজ্ঞতা আছে?

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

• কারও কি নেতৃত্বের ক্ষমতা আছে? তারা কি পরিবর্তন দাবি করতে সক্ষম?

যদি কেউ কান না দেয়, তারা বলছেন যে পরীক্ষাটি ভাল নয়। (দ্রষ্টব্য যে নেতৃত্বের শক্তিটি আনুষ্ঠানিক হতে হবে না care এমন একটি দল থাকা যা যত্নশীল good

• উন্নয়ন চক্রের প্রয়োগ ও সংহতকরণের জন্য স্বয়ংক্রিয় পরীক্ষাকে সহজ করার জন্য আপনি কি সরঞ্জাম এবং প্রক্রিয়াগুলি বিকাশ করছেন?

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

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

Comments

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

— স্যাম

Answer 12

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

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

আপনি তা এড়াতে চান।

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

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

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

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

Comments

আমি কোডটি পছন্দ করি যা কোডের চেয়ে আমি আরও ভালভাবে পড়তে পারি যে কারওর মতো মিনটিয়ায় সরাসরি পরীক্ষা করার প্রয়োজন বলে মনে হয়েছে।

— এরিক রেপেন

আমি যে সুন্দর সবুজ রঙের টিক্সগুলি অনুভব করি তা সমস্যা - এটি কোনও ধরণের গেমের পরীক্ষা করে তোলে।

— gbjbaanb

Answer 13

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

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

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

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

Answer 14

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

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

Answer 15

এটি আমার দৃ strong় মতামত যে ইউনিট পরীক্ষাগুলির মান অনেকগুলি কারণ দ্বারা অনেক দল দ্বারা মূলত অবমূল্যায়ন করা হয়, অনেকেই ইতিমধ্যে উত্তরে হাইলাইট করেছেন।

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

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

তবে এর ব্যতিক্রমও রয়েছে

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

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

বিকাশকারীদের আরও ইউনিট পরীক্ষা-প্রবণ করার জন্য

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

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

Answer 16

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

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

• পরীক্ষাগুলি চলমান রয়েছে তা আপনার নিশ্চিত করা দরকার।
• আপনাকে পরীক্ষা করে চালানো হয়নি যেহেতু পরীক্ষাগুলি অপসারণ করা হবে না তা আপনাকে নিশ্চিত করতে হবে
• আপনার পরীক্ষা মেট্রিকগুলি আপনাকে শেষ বিল্ড এবং এই বিল্ডটিতে কী দৌড়েছিল তা দেখাতে হবে। আপনার # পরীক্ষার কেস কমছে না তা নিশ্চিত করার জন্য।
• পরীক্ষার কেসগুলি যেমন উন্নয়ন হয় তা নিশ্চিত করার জন্য বিকাশের মতো পর্যালোচনা করা দরকার যে লোকেরা গোলযোগ সৃষ্টি করছে না, টাইপ করে কেবল 1 টি পরীক্ষা 2-এ বিভক্ত করার জন্য (কিছু সময় পরীক্ষা আউটসোর্স করা হয়, তাই এই ট্র্যাকিংটি গুরুত্বপূর্ণ)
• দেব এবং পরীক্ষার মধ্যে আরও অনেক "স্বাস্থ্যকর" যোগাযোগ গুরুত্বপূর্ণ
• রাখা non-functionalপরীক্ষার পৃথক, এবং তাদের এটা দৈনন্দিন চালানোর আশা করবেন না, এটা এই uptodate, এবং ভাল রাখার সময় লাগে। তবে হাল ছেড়ে দেবেন না, নিশ্চিত করুন যে তারা বজায় রয়েছে।

আপনি এই কারণে ব্যর্থ হন

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

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

Comments

ইউনিট- এবং ইন্টিগ্রেশন-পরীক্ষার ক্ষেত্রে, পরীক্ষাগুলি লেখার লোকেরা বিকাশকারী, পৃথক "পরীক্ষার প্রকৌশলী" নয়। (প্রশ্নটিতে লেখা হিসাবে, কিউএ, অর্থাৎ পরীক্ষার প্রকৌশলীরা প্রকৃতপক্ষে ইতিমধ্যে স্বয়ংক্রিয় ইউআই পরীক্ষাগুলি ব্যবহার করেছেন

— ŭ

বাস্তবিকভাবে বলতে গেলে, স্বয়ংক্রিয় পরীক্ষাগুলি লেখার যে কোনও ব্যক্তির বিকাশের দক্ষতা থাকতে হবে।

— সিদ্ধার্থ