টেস্টেবল কোড বনাম জল্পনা-সংক্রান্ত সাধারণতা এড়ানো লেখা


11

আমি আজ সকালে কিছু ব্লগ পোস্ট পড়ছিলাম, এবং এইটি দেখে হোঁচট খেয়েছি :

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

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

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

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

আমি এই বিষয়ে অন্যান্য ব্যক্তির গ্রহণযোগ্যতা পড়তে আগ্রহী - আপনার মতামতের জন্য আগাম ধন্যবাদ।


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

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

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

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

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

উত্তর:


14

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


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

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

আমি আরও যোগ করব, আপনি যখন পরীক্ষাগুলিতে ইন্টারফেসের উপর নির্ভর করছেন তখন সাধারণতা আর অনুমানযোগ্য নয়
পিট

"এটি না করা" (ইন্টারফেস ব্যবহার করে) স্বয়ংক্রিয়ভাবে আপনার ক্লাসগুলি দৃly়ভাবে মিলিত হয় না। এটা ঠিক না। যেমন। নেট ফ্রেমওয়ার্কে একটি Streamশ্রেণি রয়েছে, তবে কোনও সংকোচনের মিল নেই।
লুক পুপলেট

3

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

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

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

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

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

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


1

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

ভিন্ন নোটে সিম্পল ইনটারফেস এবং একমাত্র কমপ্লেক্সথিং যা এটি প্রয়োগ করে তার কারণ থাকতে পারে। কমপ্লেক্সথিংয়ের কিছু টুকরো থাকতে পারে যা আপনি সরলআইনফেরফেস ব্যবহারকারীর কাছে অ্যাক্সেসযোগ্য হতে চান না। এটি সবসময় একটি অতিরিক্ত উত্সাহী OO-ish কোডারের কারণে নয়।

আমি এখনই সরে যাব এবং প্রত্যেককে এই কোডটিতে যে "কোডটি তাদের" দুর্গন্ধযুক্ত "করে তোলে তা লাফিয়ে উঠতে দেব।


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

0

আমি দুটি অংশে উত্তর দেব:

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

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


0

পলিমারফিজমের বাইরে কোনও ইন্টারফেসে আরও প্রোগ্রামিং শুরু করার পর থেকে আমি অনেক সুবিধা দেখেছি।

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

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

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

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

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