কোডের জন্য কেন পরীক্ষাগুলি লিখব যে আমি চুল্লি করব?

Question

আমি একটি বিশাল লিগ্যাসি কোড ক্লাস রিফ্যাক্টর করছি। রিফ্যাক্টরিং (আমার ধারনা) এটিকে সমর্থন করে:

1. উত্তরাধিকার শ্রেণীর জন্য পরীক্ষা লিখুন
2. হেফকে ক্লাস থেকে বের করে দেওয়া

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

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

রিফ্যাক্টরের আগে পরীক্ষা লেখার আসল কারণটি কি - আমাকে কোডটি আরও ভালভাবে বুঝতে সাহায্য করার জন্য? আর একটি কারণ থাকতে হবে!

দয়া করে ব্যাখ্যা করুন!

বিঃদ্রঃ:

এই পোস্টটি রয়েছে: যখন পুরো রিফ্যাক্টরিংয়ের সময় নেই তখন লিগ্যাসি কোডের জন্য টেস্টগুলি লেখার কী অর্থ হয়? তবে এটি "রিফ্যাক্টরের আগে পরীক্ষা লিখুন" বলে, তবে "কেন" বলে না, বা "টেস্ট লেখার ক্ষেত্রে" মনে হয় "ব্যস্ত কাজ যা শীঘ্রই ধ্বংস হয়ে যাবে"

Comments

আপনার ভিত্তিটি ভুল। আপনি আপনার পরীক্ষা পরিবর্তন করবেন না। আপনি নতুন পরীক্ষা লিখবেন। পদক্ষেপ 3 "হ'ল যে কোনও পরীক্ষা এখন বাতিল হয়ে গেছে"।

— পিডিআর

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

— ডেনিস

না, আপনি দ্বিতীয় ধাপটি চলাকালীন নতুন পরীক্ষাগুলি লিখতে চান এবং হ্যাঁ, পদক্ষেপ 1 নষ্ট হয়ে গেছে। তবে কি সময় নষ্ট হয়ে গেল? না, কারণ এটি আপনাকে এক ধরণের আশ্বাস দেয় যে আপনি ২ য় পদক্ষেপের সময় কোনও কিছু ভঙ্গ করছেন না Your আপনার নতুন পরীক্ষাগুলি এটি করে না।

— পিডিআর

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

— ডিএক্সএম

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

— নীল

Answer 1

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

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

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

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

Comments

+1 টি। আমার মন পড়ুন, আমার উত্তর লিখেছেন। গুরুত্বপূর্ণ বিষয়: আপনাকে একই ইউনিট পরীক্ষাগুলি লেখার প্রয়োজন হতে পারে যে রিফ্যাক্টরিংয়ের পরে একই বাগগুলি এখনও রয়েছে!

— david.pfx

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

— ডেনিস

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

— ডেনিস

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

— আমন

রিফ্যাক্টর করার সময় বিভিন্ন ত্রুটিগুলি ঠিক করা থেকে আমি বুঝতে পারি যে আমি পরীক্ষা না করেই কোডটি সহজে সরিয়ে ফেলতাম না। পরীক্ষাগুলি আমাকে আমার কোড পরিবর্তন করে পরিচয় করিয়ে দেওয়া আচরণগত / কার্যকরী "বিচ্ছিন্নতা" সম্পর্কে সতর্ক করে।

— ডেনিস 16

Answer 2

আহ, উত্তরাধিকার ব্যবস্থা বজায় রাখা

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

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

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

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

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

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

Comments

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

— ডেনিস

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

— ফিলিপ

Answer 3

আমার নিজের উত্তর / উপলব্ধি:

রিফ্যাক্টর করার সময় বিভিন্ন ত্রুটিগুলি ঠিক করা থেকে আমি বুঝতে পারি যে আমি পরীক্ষা না করেই কোডটি সহজে সরিয়ে ফেলতাম না। পরীক্ষাগুলি আমাকে আমার কোড পরিবর্তন করে পরিচয় করিয়ে দেওয়া আচরণগত / কার্যকরী "বিচ্ছিন্নতা" সম্পর্কে সতর্ক করে।

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

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

হালনাগাদ

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

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

Comments

রিফ্যাক্টরিংয়ের সাথে আপনি অ্যাপ্লিকেশনটিকে নতুনভাবে নকশাকৃত করার মতো আরও শোনায়।

— জেফো

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

— ডেনিস

Answer 4

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

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

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

Comments

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

— পিডিআর

আমার উত্তর আপডেট।

— মাইকেল ডুরান্ট

Answer 5

আপনার নির্দিষ্ট ক্ষেত্রে রিফ্যাক্টরিংয়ের লক্ষ্য কী?

আমার উত্তরটি ধরে রাখার উদ্দেশ্যে ধরে নিন যে আমরা সকলেই টিডিডিতে (কিছুটা হলেও) বিশ্বাস করি (টেস্ট-চালিত বিকাশ)।

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

• পরীক্ষাগুলি আপনাকে আপনার নতুন কাজটি আসলে কাজ করে তা নিশ্চিত করতে সহায়তা করবে।

• পরীক্ষাগুলি সম্ভবত এমন ক্ষেত্রেও উদ্ঘাটিত হবে যেখানে মূল কাজটি কাজ করে না ।

তবে আপনি কিছুটা আচরণকে প্রভাবিত না করে কীভাবে কোনও গুরুত্বপূর্ণ রিফ্যাক্টরিং করবেন ?

রিফ্যাক্টরিংয়ের সময় ঘটতে পারে এমন কয়েকটি জিনিসের একটি সংক্ষিপ্ত তালিকা এখানে রয়েছে:

• পরিবর্তনশীল নাম পরিবর্তন
• ফাংশনটির পুনরায় নামকরণ করুন
• ফাংশন যোগ করুন
• ফাংশন মুছুন
• দুটি বা আরও বেশি ফাংশনে বিভক্ত ফাংশন
• দুটি বা তার বেশি ফাংশন এক ফাংশনে একত্রিত করুন
• বিভক্ত শ্রেণি
• ক্লাস একত্রিত করুন
• শ্রেণীর নাম পরিবর্তন করুন

আমি যুক্তি দিতে যাচ্ছি যে এই তালিকাভুক্ত ক্রিয়াকলাপগুলির প্রত্যেকটিই কোনও না কোনওভাবে আচরণ পরিবর্তন করে ।

এবং আমি তর্ক করতে যাচ্ছি যে যদি আপনার রিফ্যাক্টরিং আচরণ পরিবর্তন করে, আপনার পরীক্ষাগুলি এখনও চলছে যাতে আপনি নিশ্চিত হন যে আপনি কোনও কিছু ভাঙ্গেন নি।

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

এই পরিস্থিতি সম্পর্কে:

• ধরুন আপনার আছে function bar()

• function foo() একটি কল করে bar()

• function flee() কাজ করার জন্য একটি কলও করে bar()

• শুধু বিভিন্ন জন্য, flam()একটি কল করেfoo()

• সবকিছু চমত্কারভাবে কাজ করে (দৃশ্যত, কমপক্ষে)।

• তুমি রিফ্যাক্টর ...

• bar() নামকরণ করা হয়েছে barista()

• flee() কল করতে পরিবর্তন করা হয় barista()

• foo()কল করতে পরিবর্তন করা হয় নাbarista()

একথাও ঠিক যে, উভয়ের জন্য আপনার পরীক্ষা foo()এবং flam()এখন ব্যর্থ হয়।

সম্ভবত আপনি প্রথম স্থানে foo()ডেকে বুঝতে পারেন নি bar()। আপনি অবশ্যই বুঝতে পারেনি যে flam()উপর নির্ভরশীল ছিল bar()প্রণালী দ্বারা foo()।

যাই হোক. পয়েন্ট যে আপনার পরীক্ষা উভয়ের সদ্য ভাঙ্গা আচরণ উন্মোচিত হবে foo()এবং flam(), আপনার refactoring কাজ সময় একটি ক্রমবর্ধমান ফ্যাশন।

পরীক্ষাগুলি আপনাকে চুল্লিটিকে ভালভাবে সহায়তা করে।

যদি আপনার কোনও পরীক্ষা না করা হয়।

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

আরেকটি দৃশ্য বিবেচনা করুন।

আপনি একটি বিল্ডিং নির্মাণ করছেন।

সঠিকভাবে বিল্ডিংটি নির্মিত হয়েছে তা নিশ্চিত করতে সহায়তা করার জন্য আপনি একটি স্ক্যাফোল্ডিং তৈরি করেন।

স্ক্যাফোর্ডিং আপনাকে অন্যান্য জিনিসগুলির মধ্যে একটি লিফ্ট শ্যাফ্ট তৈরি করতে সহায়তা করে। এরপরে, আপনি ভারাটি ছিঁড়ে ফেলুন, তবে লিফট শ্যাফ্টটি রয়ে গেছে। আপনি ভারাটিকে নষ্ট করে "মূল কাজ" ধ্বংস করেছেন।

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