টিডিডি ছাড়াই ইউনিট পরীক্ষার অনুভূতি


28

আমাদের নতুন (বেশ বড়) প্রকল্প শুরু হচ্ছে, যা আমরা টিডিডি ব্যবহার করে বিকাশের পরিকল্পনা করেছি।

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

যোগ করা হয়েছে: আমি মনে করি এটি >> এই প্রশ্নের নকল নয় << - আমি ইউটি এবং টিডিডির মধ্যে পার্থক্য বুঝতে পারি। আমার প্রশ্ন হচ্ছে পার্থক্য সম্পর্কে না , কিন্তু জ্ঞান সম্পর্কে TDD- এ ছাড়া ইউনিট পরীক্ষা লেখার।


22
আপনার বন্ধুটির এমন বাজে বক্তব্য সম্পর্কে কী যুক্তিযুক্ত তা আমি
উত্সাহী

11
আমি বাজি রেখেছিলাম যে কয়েকটি ইউনিট পরীক্ষার সংখ্যক প্রকল্পগুলি টিডিডি ব্যবহার করছে না
কেসি

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

2
অভিজ্ঞতার কিছু ব্যবহারিক পরামর্শ হিসাবে, আপনি যদি টিডিডি না করেন তবে সমস্ত কিছু পরীক্ষা করবেন না । কী ধরণের পরীক্ষাগুলি মূল্যবান সে বিষয়ে একটি সংকল্প করুন। আমি খুঁজে পেয়েছি যে খাঁটি ইনপুট / আউটপুট পদ্ধতিতে ইউনিট পরীক্ষাগুলি অসাধারণ মূল্যবান, তবে অ্যাপ্লিকেশনটির একটি খুব উচ্চ স্তরের ইন্টিগ্রেশন পরীক্ষাগুলি (উদাহরণস্বরূপ, ওয়েব অ্যাপ্লিকেশনটিতে ওয়েব অনুরোধ প্রেরণ করা )ও অসাধারণ মূল্যবান। মিড-টায়ার ইন্টিগ্রেশন টেস্ট এবং ইউনিট পরীক্ষার জন্য নজর রাখুন যার জন্য প্রচুর পরিমাণে মক সেটআপ প্রয়োজন। এই ভিডিওটিও দেখুন : youtube.com/watch?v=R9FOchgTtLM
jpmc26

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

উত্তর:


52

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

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


12
"আপনি যদি টিডিডি ব্যবহার না করেন তবে আপনি গ্যারান্টিযুক্ত কোড কভারেজ পাবেন না।": আমি এটি মনে করি না। আপনি দুটি দিনের জন্য বিকাশ করতে পারেন, এবং পরের দুই দিনের জন্য আপনি পরীক্ষা লিখুন। গুরুত্বপূর্ণ বিষয়টি হ'ল আপনি যতক্ষণ না কাঙ্ক্ষিত কোড কভারেজ না হওয়া পর্যন্ত কোনও বৈশিষ্ট্য সমাপ্তি হিসাবে বিবেচনা করবেন না।
জর্জিও

5
@ ডগএম - একটি আদর্শ বিশ্বে সম্ভবত ...
টেলাস্টিন

7
দুঃখজনকভাবে TDD- এ সঙ্গে হাতে-ইন সরাসরি যায় উপহাস এবং যতক্ষণ মানুষ করা বন্ধ সব প্রমাণ করে যে আপনার পরীক্ষার রান যে দ্রুতটিডিডি মারা গেছে। দীর্ঘ লাইভ টেস্টিং।
মিকিডি

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

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

21

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

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

আমার একটি নির্দিষ্ট ডেটা স্ট্রাকচার দরকার ছিল যা আমাকে একটি বিপরীতে সংখ্যক বিট ট্র্যাক করতে দেয়। যেহেতু প্রকল্পটি জাভাতে রয়েছে, তাই আমি জাভা বেছে নিয়েছিলাম BitSetএবং এটি কিছুটা সংশোধন করেছি (আমারও 0অগ্রণীদের ট্র্যাক করার দক্ষতার প্রয়োজন ছিল যা জাভা এর বিটসেট কোনও কারণে না করে .....)। ~ 93% কভারেজ পৌঁছানোর পরে আমি কিছু পরীক্ষা লিখতে শুরু করেছি যা আসলে আমার লেখা সিস্টেমটিকে চাপ দেবে। আমার শেষের প্রয়োজনীয়তার জন্য এগুলি যথেষ্ট দ্রুত হবে তা নিশ্চিত করার জন্য আমার কার্যকারিতার কয়েকটি দিকগুলি বেঞ্চমার্ক করা দরকার। আশ্চর্যজনকভাবে, BitSetবড় বিট সেটগুলির সাথে লেনদেন করার সময় আমি ইন্টারফেস থেকে যে কাজগুলিকে ওভাররাইড করেছিলাম সেগুলির মধ্যে একটি অযৌক্তিকভাবে ধীর ছিল (এই ক্ষেত্রে লক্ষ লক্ষ বিট) in অন্যান্য ওভাররাইড ফাংশনগুলি এই একটি ফাংশনের উপর নির্ভর করে, তাই এটি ছিল বিশাল বোতল ঘাড়।

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

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

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

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


7

আপনি কোডটি প্রায় 4 টি বিভাগে বিভক্ত করতে পারেন:

  1. সহজ এবং খুব কমই পরিবর্তন হয়।
  2. সহজ এবং ঘন ঘন পরিবর্তন হয়।
  3. জটিল এবং খুব কমই পরিবর্তিত হয়।
  4. জটিল এবং ঘন ঘন পরিবর্তন হয়।

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

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


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

1

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

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

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

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

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


0

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

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


0

প্রকৃতপক্ষে চাচা বব তার ক্লিন কোডার ভিডিওগুলির মধ্যে একটি খুব আকর্ষণীয় বিষয় উল্লেখ করেছিলেন। তিনি বলেছিলেন যে রেড-গ্রিন-রিফ্যাক্টর চক্রটি 2 উপায়ে প্রয়োগ করা যেতে পারে।

প্রথমটি হ'ল প্রচলিত টিডিডি উপায়। একটি ব্যর্থ পরীক্ষা লিখুন তারপরে পরীক্ষার পাস এবং শেষ পর্যন্ত রিফ্যাক্টর করুন।

২ য় উপায় হ'ল উত্পাদন কোডের একটি খুব ছোট টুকরো লিখতে এবং তত্ক্ষণাত তার ইউনিট পরীক্ষার পরে তা রিফেক্টর অনুসরন করে।

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

আবার আমি পুনরাবৃত্তি করলাম (এবং এটি আঙ্কেল বব দ্বারা জোর দেওয়া হয়েছিল) ধারণাটি হ'ল খুব ছোট পদক্ষেপে চলে যাওয়া এবং তত্ক্ষণাত সবে যুক্ত হওয়া কোড কোডটির টুকরো পরীক্ষা করা test


"... ধারণাটি হ'ল খুব ছোট পদক্ষেপে চলে যাওয়া এবং অবিলম্বে যে প্রযোজনীয় কোডটি যুক্ত করা হয়েছিল তার টুকরোটি অবিলম্বে পরীক্ষা করা।": আমি সম্মত নই। আপনি কী করতে চান এবং আপনি কী করতে চান সে সম্পর্কে আপনার ইতিমধ্যে একটি পরিষ্কার ধারণা থাকলে আপনি কী বর্ণনা করেন এবং বিশদটি নিয়ে কাজ করতে চান, তবে আপনাকে প্রথমে বড় চিত্রটি পাওয়া দরকার। অন্যথায়, খুব ছোট পদক্ষেপে (পরীক্ষা, বিকাশ, পরীক্ষা, বিকাশ) আপনি বিশদে হারিয়ে যেতে পারেন। "আপনি কোথায় যাচ্ছেন তা যদি আপনি না জানেন তবে আপনি সেখানে যেতে পারবেন না।"
জর্জিও
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.