এমন কি কোনও কারণ আছে যে পরীক্ষাগুলি তাদের পরীক্ষার কোডের সাথে ইনলাইন লিখিত হয় না?

91

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

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

— ক্রিস দেভেরাক্স
সূত্র

33

ডকটেস্ট সহ পাইথনের মতো কিছু প্রোগ্রামিং ল্যাঙ্গুয়েজ আপনাকে এটি করতে দেয়।

— সাইমন বার্গোট

2

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

— JeffO

5

এখানে আর্গুমেন্টের অর্ধেকটি ইনলাইন ডকুমেন্টেশনের ক্ষেত্রেও প্রযোজ্য।

— কোডসইনচাউস

3

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

7

চুক্তি অনুসারে ডিজাইনটি ইনলাইন স্পেসিফিকেশনের জন্য মঞ্জুরি দেয় যা টেস্টিং সোজা করে তোলে।

— Fuhrmanator

89

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

ইনলাইন পরীক্ষার জন্য অবশ্য বেশ কয়েকটি সুস্পষ্ট ত্রুটি রয়েছে:

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

— vaughandroid
সূত্র

9

ইহা আকর্ষণীয়. আমার অনুমান আমি যে সুবিধাটি দেখতে পাচ্ছি তা হ'ল আপনি যখন আপনার "কোডার" টুপিটি চালু করলেন, আপনি পরীক্ষার বিষয়ে চিন্তাভাবনা করতে চান, তবে এটি একটি ভাল বিষয় যে বিপরীতটি সত্য নয়।

— ক্রিস Devereux

2

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

— জিম নট

6

যদি আমি পারতাম এটি কোনওভাবেই কোনও উত্তর কীভাবে? ইমপ্লিমেন্টরা টেস্ট লিখছেন না? পরীক্ষাগুলি এড়ানো লোকেরা কি বাস্তবায়নের বিশদটি দেখুন? "ঠিক খুব শক্ত" বড় ফাইলগুলিতে দ্বন্দ্ব ?? কীভাবে কোনওভাবে কোনও পরীক্ষার প্রয়োগের বিশদ সাথে বিভ্রান্ত হতে পারে ???

— ভরাল

5

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

— ডিফোরে

3

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

— স্টিভ 314

36

আমি কিছু সম্পর্কে চিন্তা করতে পারেন:

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

এখন এই ইস্যুগুলির জন্য সম্ভাব্য কাজের সুযোগ রয়েছে। তবে আইএমও, সেখানে প্রথম স্থানে না যাওয়া সহজ।

এটি লক্ষণীয় যে প্রথম দিনগুলিতে, জাভা প্রোগ্রামাররা এই ধরণের কাজ করতেন; যেমন main(...)পরীক্ষার সুবিধার্থে ক্লাসে একটি পদ্ধতি সহ । এই ধারণাটি প্রায় সম্পূর্ণ অদৃশ্য হয়ে গেছে। এটি কোনও ধরণের পরীক্ষার কাঠামো ব্যবহার করে পৃথকভাবে পরীক্ষাগুলি বাস্তবায়ন করা শিল্প অনুশীলন।

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

— স্টিফেন সি
সূত্র

4

+1 পঠনযোগ্যতা সংক্রান্ত সমস্যাগুলি - বিশেষত ওও ডিজাইনে পরীক্ষার কোডটি প্রয়োগের কোডের তুলনায় আনুপাতিকভাবে বেশি হতে পারে।

— Fuhrmanator

2

পরীক্ষার ফ্রেমওয়ার্ক ব্যবহার করে নির্দেশ করার জন্য +1। প্রোডাকশন কোডের সাথে একযোগে একটি ভাল পরীক্ষার কাঠামো ব্যবহার করা আমি কল্পনা করতে পারি না।

— joshin4colours

1

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

— sixtyfootersdude

1

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

— স্টিফেন সি

1

1) আপনি আমার উত্তরটির প্রথম অংশটি মিস করেছেন যেখানে আমি তিনটি প্রকৃত কারণ দিয়েছি? সেখানে কিছু "সমালোচনামূলক চিন্তা" জড়িত ছিল .... ২) আপনি যে দ্বিতীয় অংশটি বলেছিলেন যে জাভা প্রোগ্রামাররা এটি করতেন, কিন্তু এখন তা করেন না? এবং স্পষ্ট প্রভাবটি যা প্রোগ্রামাররা এটি বন্ধ করে দিয়েছিল ... সঙ্গত কারণে?

— স্টিফেন সি

14

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

মাইকেল ফিচারগুলির এটি সম্পর্কে একটি উপস্থাপনা রয়েছে এবং আপনি কোডের মান উন্নত করতে পারেন এমন অনেক উপায়ে তিনি উল্লেখ করেছেন।

— ড্যানিয়েল কাপলান
সূত্র

13

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

সৃষ্টি: টেস্ট এবং কোড বিভিন্ন সময়ে বিভিন্ন ব্যক্তি দ্বারা লেখা হতে পারে।

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

পুনরায় ব্যবহারযোগ্যতা: আপনি যদি পরীক্ষাগুলি ইনলাইন করে রাখেন তবে আপনি সেগুলি অন্য কোনও কোডের সাহায্যে ব্যবহার করতে পারবেন না।

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

নির্বাচনযোগ্যতা: পরীক্ষাগুলি কোড থেকে পৃথক রাখা আপনার কোন পরীক্ষা চালাতে চান তা চয়ন করা আরও সহজ করে তোলে makes

উদাহরণস্বরূপ, আপনার কাছে টেস্টের একটি ছোট স্যুট থাকতে পারে যা আপনি বর্তমানে কাজ করছেন এমন কোডের সাথে সম্পর্কিত এবং একটি বৃহত্তর স্যুট যা পুরো প্রকল্পটি পরীক্ষা করে।

— কালেব
সূত্র

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

— Andres F.

1

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

— কালেব

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

— ব্যবহারকারী 1852503

10

আমি ভাবতে পারি এমন আরও কিছু কারণ রয়েছে:

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

— ডক ব্রাউন
সূত্র

5

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

— mhr
সূত্র

9

অসম্ভব না. এলপির মতো এটির জন্য অতিরিক্ত প্রিপ্রোসেসিং পর্বের প্রয়োজন হবে। এটি সি, বা একটি সংকলন-জেএস ভাষায় সহজেই করা যেতে পারে।

— ক্রিস দেভেরাক্স

আমার কাছে এটি নির্দেশ করার জন্য +1। আমি প্রতিনিধিত্ব করতে আমার উত্তর সম্পাদনা করেছি।

— mhr

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

— জুমালাইফগার্ড

5

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

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

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

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

— commenter8
সূত্র

4

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

সি # এর ক্ষেত্রে (আমি সি ++ তেও বিশ্বাস করি, আপনি কী সংকলকটি ব্যবহার করছেন তার উপর ভিত্তি করে সিনট্যাক্সটি কিছুটা আলাদা থাকতে পারে) আপনি কীভাবে এটি করতে পারেন।

#define DEBUG //  = true if c++ code
#define TEST /* can also be defined in the make file for c++ or project file for c# and applies to all associated .cs/.cpp files */

//somewhere in your code
#if DEBUG
// debug only code
#elif TEST
// test only code
#endif

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

— জন
সূত্র

2

আমরা আমাদের পার্ল কোড সহ ইনলাইন পরীক্ষা ব্যবহার করি। টেস্ট :: ইনলাইন একটি মডিউল আছে , যা ইনলাইন কোড থেকে পরীক্ষার ফাইল উত্পন্ন করে।

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

উত্থাপিত উদ্বেগের কয়েকটির প্রতিক্রিয়া:

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

রেফারেন্সের জন্য:

— MLA
সূত্র

1

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

— মার্ক রেন্ডেল
সূত্র

1

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

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

— হ্যান্স-পিটার স্টার
সূত্র

0

এটা সত্য নয়। প্রোডাকশন কোডটি যখন বিশেষত উত্পাদনের রুটিন খাঁটি থাকে তখন আপনার ইউনিট-পরীক্ষাগুলি উত্পাদন কোডের পাশে রাখাই আরও ভাল।

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

— zumalifeguard
সূত্র