পরীক্ষার উদ্দেশ্যে কোডটি কঠোরভাবে সংশোধন করা কি খারাপ অভ্যাস?

Question

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

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

আমার সহকর্মীর অভিমত যে শুধুমাত্র পরীক্ষার উদ্দেশ্যে সংশোধন কোড (যা কাজ করে) ভুল is

কেবলমাত্র একটি সাধারণ উদাহরণ, কোডটির এই অংশটি মনে করুন যা কোনও উপাদান দ্বারা ব্যবহৃত হয় (সি # তে লিখিত):

public void DoSomethingOnAllTypes()
{
    var types = Assembly.GetExecutingAssembly().GetTypes();

    foreach (var currentType in types)
    {
        // do something with this type (e.g: read it's attributes, process, etc).
    }
}

আমি প্রস্তাব দিয়েছি যে এই কোডটি অন্য কোনও পদ্ধতিতে কল করার জন্য সংশোধন করা যেতে পারে যা আসল কাজ করবে:

public void DoSomething(Assembly asm)
{
    // not relying on Assembly.GetExecutingAssembly() anymore...
}

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

একটি ভাল এবং সাধারণ অনুশীলন হিসাবে বিবেচনা করা হয়?

Comments

আপনার পরিবর্তিত পদ্ধতিতে Typeপ্যারামিটার হিসাবে নেওয়া উচিত , একটি নয় Assembly।

— রবার্ট হার্ভে

আপনি ঠিক বলেছেন - টাইপ করুন বা অ্যাসেম্বলি, পয়েন্টটি ছিল কোডটি প্যারামিটার হিসাবে সরবরাহের অনুমতি দেওয়া উচিত, যদিও মনে হতে পারে যে এই কার্যকারিতাটি কেবল পরীক্ষার জন্য ব্যবহৃত হতে পারে ...

— লিওর

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

— mattnz

কোডটি "কাজ করে" তার কী আশ্বাস রয়েছে?

— ক্রেইজ

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

— পিটার নর্ডল্যান্ডার

Answer 1

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

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

Comments

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

— জেসন সোয়েট

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

— টেলাস্টিন

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

— লোকালম্যান

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

— সুলতান

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

— আমেরিকানউমলাউট

Answer 2

খেলায় (আপাতদৃষ্টিতে) বিরোধী শক্তি রয়েছে।

• একদিকে আপনি এনক্যাপসুলেশন প্রয়োগ করতে চান
• অন্যদিকে, আপনি সফ্টওয়্যারটি পরীক্ষা করতে সক্ষম হতে চান

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

static void Main(string[] args)

আপনার সহকর্মী কি আপনার কোডটিতে এটি কেবলমাত্র অ্যাক্সেস পয়েন্ট করার প্রস্তাব দিচ্ছে? বাহ্যিক কলারদের দ্বারা অন্য সমস্ত কোডটি অ্যাক্সেসযোগ্য হওয়া উচিত?

কষ্টসহকারে। তারপরে কোন কিছুটি জনসাধারণের কাছে প্রকাশ করা ঠিক আছে? এটি কি শেষ পর্যন্ত বিষয়গত নকশার সিদ্ধান্ত নয়?

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

আমি একটি ব্যক্তিগত পদ্ধতি যে তার invariants রক্ষা করে না এক্সপোজ চাইবেন না, কিন্তু প্রায়ই আপনি এটা পরিবর্তন করতে পারেন যাতে এটি নেই তার invariants রক্ষা করতে, এবং তারপর (জনসাধারণের জন্য এটা এক্সপোজ অবশ্যই, TDD- এ সঙ্গে, আপনি এটা করতে অন্যান্য উপায় কাছাকাছি).

টেস্টিবিলিটির জন্য একটি এপিআই খোলাই ভাল জিনিস , কারণ আপনি যা করছেন তা আসলে ওপেন / ক্লোজড নীতিমালা প্রয়োগ করা ।

আপনার যদি কেবলমাত্র আপনার API এর একক কলার থাকে তবে আপনি জানেন না যে আপনার API টি কতটা নমনীয়। সম্ভাবনাগুলি, এটি বেশ জটিল inf পরীক্ষাগুলি আপনাকে দ্বিতীয় ক্লায়েন্ট হিসাবে কাজ করে , আপনাকে আপনার এপিআইয়ের নমনীয়তার বিষয়ে মূল্যবান মতামত দেয় ।

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

Comments

+1 আপনি যখন সর্বজনীন পদ্ধতিটি সঠিকভাবে এর আক্রমণকারীদের রক্ষা করেন তখন আপনি নিরাপদ বোধ করেন।

— শ্যাবুলেটর

আমি আপনার উত্তর loooove! :) আমি কতবার শুনি: "এনক্যাপসুলেশনটি ব্যক্তিগতকে কিছু পদ্ধতি এবং বৈশিষ্ট্য তৈরি করার প্রক্রিয়া হয়"। এটি যখন আপনি বস্তু ভিত্তিক প্রোগ্রাম করার সময় বলার মতো, এটি কারণ আপনি বস্তুগুলি নিয়ে প্রোগ্রাম করেন। :( আমি অবাক হইনি যে নির্ভরতা ইনজেকশনের মাস্টারের কাছ থেকে এতটা পরিষ্কার উত্তর এসেছে my আমি আমার উত্তরটি আমার পুরানো উত্তরাধিকারের কোডটি সম্পর্কে হাসিখুশি করতে আপনার উত্তরটি কয়েকবার অবশ্যই পড়ব

— স্যামুয়েল

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

— রবার্ট হার্ভে

Answer 3

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

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

Comments

ডিআই প্রধান প্রশ্ন নয় (আমি কেবল একটি উদাহরণ দেওয়ার চেষ্টা করছিলাম), মূল বক্তব্যটি ছিল কেবলমাত্র পরীক্ষার খাতিরে, অন্য কোনও পদ্ধতি প্রদান করা ঠিক হয়েছিল যা মূলত তৈরির উদ্দেশ্যে নয়, তৈরি করা হয়েছিল।

— উদ্বিগ্ন

আমি জানি. আমি ভেবেছিলাম "হ্যাঁ" দিয়ে আমি আমার দ্বিতীয় অনুচ্ছেদে আপনার মূল বিষয়টিকে সম্বোধন করেছি।

— জেসন সোয়েট

Answer 4

এটি একটি মুরগি এবং ডিমের সমস্যা কিছুটা।

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

আমি আপনার সহকর্মীর দৃষ্টিকোণটি দেখতে পাচ্ছি। আপনার কোড রয়েছে যা (সম্ভবত) কাজ করে, এবং যদি আপনি যান এবং এটি পুনরুদ্ধার করেন - যে কোনও কারণেই - এটি ঝুঁকির ঝুঁকি রয়েছে you'll

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

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

অবশ্যই এটি ভাল ব্যবসায়ের অনুশীলন সম্পূর্ণ 'কীটপতঙ্গ নোটার ক্যান ..'

Comments

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

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

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

— শমূয়েল

Answer 5

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

পয়েন্ট যে আপনি নির্ধারণ এই কোড কিছু রক্ষণাবেক্ষণ প্রয়োজন হবে এ যে testability জন্য refactor করার জন্য একটি ভাল সময় হবে তখন। আপনার ব্যবসায়ের ক্ষেত্রে উপর নির্ভর করে, এটি একটি বৈধ ধারণা হতে পারে যে সমস্ত কোডের শেষ পর্যন্ত কিছু রক্ষণাবেক্ষণের প্রয়োজন হবে, সেক্ষেত্রে আমি এখানে অন্যান্য উত্তরগুলির সাথে যে পার্থক্যটি আঁকছি ( যেমন জেসন সোয়েটের উত্তর ) অদৃশ্য হয়ে যায়।

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

(নতুন কোড অবশ্যই সক্রিয়ভাবে রক্ষণাবেক্ষণ করা হচ্ছে, সুতরাং এটি পরীক্ষার জন্য লেখা উচিত))

Answer 6

আমি মনে করি আপনার সহকর্মীটি ভুল।

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

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

আপনার বৈশিষ্ট্যটি আপনার কোম্পানির / গ্রাহককে উপকৃত করবে এমন নতুন বৈশিষ্ট্যগুলিতে কাজ করার তুলনায় রিফ্যাক্টরিংয়ের সিদ্ধান্ত নেওয়া অগত্যা আপনার জায়গা নয়।

Answer 7

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

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

Answer 8

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

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

সমস্যাটি অবশ্যই টেস্ট টুলিংয়ের প্রকৃতির।

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

উত্তর দেওয়ার জন্য: আপনার সহকর্মী সঠিক, তবে সম্ভবত ভুল কারণে। পরীক্ষার জন্য কোড পরিবর্তন করবেন না, আপনার পরীক্ষার সরঞ্জামটি পরিবর্তন করুন (বা এই জাতীয় সূক্ষ্ম পরীক্ষার পরিবর্তে আরও একীকরণ-শৈলীর ইউনিট পরীক্ষা করার জন্য আপনার সম্পূর্ণ টেস্ট কৌশল)।

মার্টিন ফাউলারের এই নিবন্ধটি সম্পর্কে ম্যাক্টিন স্টাবস নয় তার নিবন্ধে এই বিষয়ে আলোচনা হয়েছে

Answer 9

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

Answer 10

আপনার উদাহরণগুলির মধ্যে কিছু গুরুতর পার্থক্য রয়েছে। ক্ষেত্রে DoSomethingOnAllTypes(), একটি ইঙ্গিত যে do somethingবর্তমান সমাবেশ প্রকারের প্রযোজ্য। তবে DoSomething(Assembly asm)স্পষ্টভাবে ইঙ্গিত দেয় যে আপনি যে কোনও সমাবেশ এটিতে পাস করতে পারেন ।

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

Answer 11

আপনার প্রশ্নটি তেমন প্রসঙ্গ দেয়নি যাতে আপনার সহকর্মী তর্ক করেছিলেন তাই অনুমানের অবকাশ আছে

"খারাপ অনুশীলন" বা না উপর নির্ভর করে কিভাবে এবং যখন পরিবর্তনগুলি করা হয়।

আমার মতামতটিতে একটি পদ্ধতি উত্তোলনের জন্য আপনার উদাহরণটি DoSomething(types)ঠিক আছে।

তবে আমি কোডটি দেখেছি যা এর মতো ঠিক নয় :

public void DoSomethingOnAllTypes()
{
  var types = (!testmode) 
      ? Assembly.GetExecutingAssembly().GetTypes() 
      : getTypesFromTestgenerator();

  foreach (var currentType in types)
  {
     if (!testmode)
     {
        // do something with this type that made the unittest fail and should be skipped.
     }
     // do something with this type (e.g: read it's attributes, process, etc).
  }
}

এই পরিবর্তনগুলি কোডটিকে বোঝার জন্য আরও জটিল করে তুলেছে কারণ আপনি সম্ভাব্য কোড-পাথের সংখ্যা বাড়িয়েছেন।

কীভাবে এবং কখন আমি এর অর্থ :

যদি আপনার একটি কার্যকরী বাস্তবায়ন হয় এবং "টেস্টিং-ক্ষমতা প্রয়োগের" প্রয়োগের স্বার্থে আপনি পরিবর্তনগুলি করেন তবে আপনাকে আপনার আবেদনটি পুনরায় পরীক্ষা করতে হবে কারণ আপনি নিজের DoSomething()পদ্ধতিটি ভঙ্গ করেছেন ।

if (!testmode)বুঝতে আরো difficulilt এবং নিষ্কাশিত পন্থার চেয়ে পরীক্ষা।