ইউনিট এবং ইন্টিগ্রেশন টেস্টিং: এটি কীভাবে প্রতিবিম্বিত হতে পারে


27

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

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

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

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

আমার প্রশ্নটি নিম্নলিখিত: আপনি কি এমন কোন পদ্ধতি ব্যবহার করেছেন যা দলের অভ্যন্তরে গতিশীল / গতিবেগ তৈরি করতে সহায়তা করে, যাঁরা স্বাভাবিকভাবেই এই পরীক্ষাগুলি তৈরি এবং বজায় রাখতে চান?


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

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

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

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

উত্তর:


13

আসল কোড হিসাবে একই সময়ে ইউনিট পরীক্ষা না লিখলে আমাদের মধ্যে কেউই আসলে খারাপ লাগে না।

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

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


সংস্কৃতি পরিবর্তনের জন্য +1, এবং উদাহরণস্বরূপ আপনাকে নেতৃত্ব দেওয়ার জন্য আমার কাছে আরও একটি +1 দেওয়ার ইচ্ছা আছে। চমৎকার উত্তর.
এরিক ডায়েটারিচ

5

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

সমস্যাটি প্রকৃতপক্ষে স্বতন্ত্র প্রেরণার একটি এবং দলগত প্রেরণার মতো নয়। এমন একটি সময় আসে যখন স্পষ্টতার মুহূর্তটি আপনার কাছে পৌঁছে যায়, এমন কিছুর ফলস্বরূপ যা আপনি অবশেষে বুঝতে পেরেছিলেন বা কোনও নতুন সরঞ্জাম বা কোনও অন্য বিষয়গত কারণে যা গড় প্রোগ্রামারকে সবকিছু ফেলে দেয় এবং প্রক্রিয়াটিকে পুরোপুরি বদলে দেয়। আপনার কাজ - আপনি এটি বাদে বেছে নেওয়া উচিত - এটি হ'ল আপনার বা দলের পক্ষে কোনও পৃথক দলের সদস্যের জন্য কোন বিষয়গুলি স্পষ্টতার কারণ হয়ে উঠবে তা খুঁজে বের করার কোনও উপায় আছে কিনা তা দেখার জন্য।

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

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

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


3

আসল কোড হিসাবে একই সময়ে ইউনিট পরীক্ষা না লিখলে আমাদের মধ্যে কেউই আসলে খারাপ লাগে না

আপনি "একই সাথে" বলতে চাইছেন তা নিশ্চিত নন, তবে আসল কোডের আগে সেগুলি কীভাবে লিখবেন ?

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

আমার অভিজ্ঞতায় টেস্ট-ফার্স্ট (টিডিডি স্টাইল) তবে আপনি দ্রুত আসক্ত হতে পারেন এমন কারণ এটির জন্য কমপক্ষে 2 টি তাত্ক্ষণিক, স্পষ্ট, অ্যান্ডোরফিন-থেকে মুক্তি সুবিধা রয়েছে:

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

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

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


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

0

প্রথমে আপনাকে নিশ্চিত করা দরকার যে একটি পরীক্ষা লেখা এবং এটি চালানো সহজ, বর্তমান প্রকল্পগুলিতে কাঠামো স্থাপন করা এবং ভবিষ্যতের প্রকল্পগুলিতে অন্তর্ভুক্ত করার জন্য সেট-আপ পদ্ধতিটিকে সহজ করে তোলা

এইভাবে কোনও প্রোগ্রামার যখন কোনও নতুন বৈশিষ্ট্যটি ইউনিটেট করতে চায় যখন সে ডিবাগ করার চেষ্টা করছে তখন তাকে সঠিকভাবে পরীক্ষা চালানোর জন্য এক ডজন হুপের মধ্য দিয়ে ঝাঁপিয়ে পড়তে হবে না

আরও অদ্ভুত কিছু করার সম্ভাবনা কম হ'ল এটি আপনি এর অভ্যাসটি তৈরি করে ফেলবেন


0

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

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


0

এমন একদল প্রোগ্রামার রাখা যাতে প্রাকৃতিকভাবে সবাই কিছু করতে চায় তা হ'ল একটি ইউটিপি (বিশেষত কোনও বৃহত্তর গ্রুপের কথা বলার সময়)।

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

এটি আপনার নিজের কোড এবং ব্যবহারের আকাঙ্ক্ষার উপর নির্ভর করে না, কোডিং এবং টেস্টিং স্ট্যান্ডার্ডগুলি থাকা দরকার যা প্রত্যেকে ভাল জিনিস তৈরি করতে ব্যবহার করে এবং যে কোনও প্রোগ্রামারকে এটি বুঝতে হবে।

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

মান এবং নিয়ম যুক্ত করা এই মুহুর্তে যদি শক্ত হয় তবে কমপক্ষে ভবিষ্যতের প্রকল্পগুলিতে সেগুলি যুক্ত করার কথা ভাবুন।

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