উত্তর:
আমি বিশ্বাস করি যেভাবেই ভাবতে পারি এটি একটি ভুল ধারণা।
প্রোডাকশন-কোড পরীক্ষা করে এমন টেস্ট-কোড মোটেও একই রকম নয়। আমি পাইথনে প্রদর্শন করব:
def multiply(a, b):
"""Multiply ``a`` by ``b``"""
return a*b
তারপরে একটি সহজ পরীক্ষা হবে:
def test_multiply():
assert multiply(4, 5) == 20
উভয় ফাংশন একটি একই সংজ্ঞা আছে কিন্তু উভয় খুব ভিন্ন জিনিস। এখানে কোনও সদৃশ কোড নেই। ;-)
এটি এমনও ঘটে যে লোকেরা নকল পরীক্ষাগুলি মূলত পরীক্ষার ক্রিয়াকলাপের জন্য একটি প্রতিবেদন রেখে লিখেন। এটি পাগলামি এবং আমি মানুষকে এটি করতে দেখেছি। এই হল খারাপ অনুশীলন।
def test_multiply_1_and_3():
"""Assert that a multiplication of 1 and 3 is 3."""
assert multiply(1, 3) == 3
def test_multiply_1_and_7():
"""Assert that a multiplication of 1 and 7 is 7."""
assert multiply(1, 7) == 7
def test_multiply_3_and_4():
"""Assert that a multiplication of 3 and 4 is 12."""
assert multiply(3, 4) == 12
1000+ কার্যকর লাইনের কোডের জন্য এটি করার কল্পনা করুন। পরিবর্তে আপনি প্রতি 'বৈশিষ্ট্য' ভিত্তিতে পরীক্ষা করুন:
def test_multiply_positive():
"""Assert that positive numbers can be multiplied."""
assert multiply(1, 3) == 3
assert multiply(1, 7) == 7
assert multiply(3, 4) == 12
def test_multiply_negative():
"""Assert that negative numbers can be multiplied."""
assert multiply(1, -3) == -3
assert multiply(-1, -7) == 7
assert multiply(-3, 4) == -12
এখন যখন বৈশিষ্ট্যগুলি যুক্ত / সরানো হয় তখন আমাকে কেবল একটি পরীক্ষার ফাংশন যুক্ত / সরানোর বিষয়টি বিবেচনা করতে হবে।
আপনি লক্ষ্য করেছেন আমি forলুপ প্রয়োগ করি নি । এটি কারণ কিছু জিনিস পুনরাবৃত্তি ভাল। আমি যখন লুপগুলি প্রয়োগ করতাম তখন কোডটি অনেক খাটো হত। কিন্তু যখন কোনও দৃ f়তা ব্যর্থ হয় তখন এটি অস্পষ্ট বার্তা প্রদর্শন করে আউটপুটকে আটকে দিতে পারে। যদি এটি ঘটে থাকে তবে আপনার পরীক্ষাগুলি কম কার্যকর হবে এবং জিনিসগুলি কোথায় ভুল হয় তা খতিয়ে দেখার জন্য আপনার একটি ডিবাগার লাগবে।
assert multiply(1,3)এক্ষেত্রে ব্যর্থ হবে তবে আপনি ব্যর্থ পরীক্ষার রিপোর্টটিও পাবেন না assert multiply(3,4)।
def test_shuffleদুটি দৃser়তা সম্পাদন করে।
assert multiply(*, *) == *যাতে আপনি কোনও assert_multiplyফাংশন সংজ্ঞায়িত করতে পারেন । বর্তমান পরিস্থিতিতে এটি সারি গণনা এবং পাঠযোগ্যতার দ্বারা গুরুত্বপূর্ণ নয়, তবে দীর্ঘ পরীক্ষার সাহায্যে আপনি জটিল দৃ as়তা, ফিক্সচারগুলি, ফিক্সচার জেনারেটিং কোড ইত্যাদি পুনরায় ব্যবহার করতে পারেন ... আমি জানি না এটি সর্বোত্তম অনুশীলন কিনা, তবে আমি সাধারণত করি এই.
দেখে মনে হচ্ছে পরীক্ষাগুলি মূলত কোড হিসাবে একই জিনিসটি প্রকাশ করে এবং তাই এটি একটি সদৃশ
না, এটা সত্য নয়।
পরীক্ষাগুলির আপনার প্রয়োগের চেয়ে আলাদা উদ্দেশ্য রয়েছে:
ডিআরওয়াইয়ের চূড়ান্ত টার্গেটে কি সমস্ত পরীক্ষার কোড অপসারণ অন্তর্ভুক্ত হবে না?
না, ডিআরওয়াইয়ের চূড়ান্ত টার্গেটটির অর্থ হ'ল সমস্ত উত্পাদন কোডকে বাদ দেওয়া ।
যদি আমাদের পরীক্ষাগুলি সিস্টেমটি কী চায় তার নিখুঁত স্পেসিফিকেশন হতে পারে তবে আমাদের কেবলমাত্র প্রযোজনা কোডের ভিত্তিটি কার্যকরভাবে অপসারণ করে স্বয়ংক্রিয়ভাবে সম্পর্কিত উত্পাদন কোড (বা বাইনারি) তৈরি করতে চাই।
এটি আসলে মডেল-চালিত আর্কিটেকচারের মতো অর্জনের জন্য দাবী করার মতো পদ্ধতির - সত্যের একক মানব-পরিকল্পিত উত্স যা থেকে সমস্ত কিছু গণনার দ্বারা উদ্ভূত হয়।
আমি মনে করি না যে বিপরীতটি (সমস্ত পরীক্ষা থেকে মুক্তি পাওয়া) আকাঙ্ক্ষিত কারণ:
কারণ মাঝে মাঝে নিজেকে পুনরাবৃত্তি করা ঠিক আছে। এই নীতিগুলির কোনওটিই প্রশ্ন বা প্রসঙ্গ ছাড়াই প্রতিটি পরিস্থিতিতে গ্রহণ করা নয়। আমার মাঝে মাঝে একটি অ্যালগরিদমের একটি নির্বোধ (এবং ধীর) সংস্করণের বিরুদ্ধে লিখিত পরীক্ষাগুলি থাকে, যা ডিআরওয়াইয়ের একটি সম্পূর্ণ পরিষ্কার লঙ্ঘন, তবে অবশ্যই উপকারী definitely
যেহেতু ইউনিট-টেস্টিং অনিচ্ছাকৃত পরিবর্তনগুলি আরও শক্তিশালী করার বিষয়ে, তাই এটি কখনও কখনও ইচ্ছাকৃত পরিবর্তনগুলি আরও শক্ত করে তুলতে পারে। এই সত্যটি সত্যই ডিআরওয়াই নীতি সম্পর্কিত।
উদাহরণস্বরূপ, যদি আপনার কোনও ফাংশন থাকে MyFunctionযা কেবলমাত্র এক জায়গায় প্রোডাকশন কোডে ডাকা হয় এবং আপনি এটির জন্য 20 ইউনিট পরীক্ষা লিখে থাকেন তবে সহজেই আপনার কোডটিতে 21 টি জায়গা রয়েছে যেখানে এই ফাংশনটি বলা হয় is এখন যখন আপনাকে স্বাক্ষর MyFunctionবা শব্দার্থবিজ্ঞান বা উভয়কেই পরিবর্তন করতে হবে (কারণ কিছু প্রয়োজনীয়তা পরিবর্তিত হয়), আপনার কেবলমাত্র একটির পরিবর্তে 21 টি স্থান পরিবর্তন করতে হবে। এবং কারণটি সত্যই DRY নীতি লঙ্ঘন: আপনি একই ফাংশন কলটি MyFunction21 বার পুনরাবৃত্তি করেছেন (কমপক্ষে) ।
এই জাতীয় ক্ষেত্রে সঠিক পন্থাটি আপনার টেস্টিং কোডেও DRY নীতিটি প্রয়োগ করে: 20 ইউনিট পরীক্ষা লেখার সময়, MyFunctionআপনার ইউনিট পরীক্ষায় কলগুলি কেবলমাত্র কিছু সহায়ক ফাংশন (আদর্শভাবে কেবল একটি) তে প্রয়োগ করে, যা ব্যবহার করে 20 ইউনিট পরীক্ষা। আদর্শভাবে, আপনি আপনার কোড কলিংয়ে মাত্র দুটি স্থান দিয়ে শেষ করেছেন MyFunction: আপনার উত্পাদন কোড থেকে একটি এবং আপনার ইউনিট পরীক্ষার একটি। সুতরাং যখন আপনাকে MyFunctionপরে স্বাক্ষর পরিবর্তন করতে হবে, আপনার পরীক্ষাগুলিতে পরিবর্তন করার জন্য কেবল কয়েকটি স্থান থাকবে।
"কয়েকটি জায়গা" এখনও "এক জায়গার" চেয়ে বেশি (আপনি কোন ইউনিট পরীক্ষা দিয়ে কিছু পান না) তবে ইউনিট পরীক্ষা করার সুবিধাগুলি পরিবর্তন করার জন্য কম কোড থাকার সুবিধাটিকে ভারী করে তুলতে হবে (অন্যথায় আপনি ইউনিট পরীক্ষা সম্পূর্ণরূপে করছেন) ভুল)।
সফ্টওয়্যার তৈরির ক্ষেত্রে সবচেয়ে বড় চ্যালেঞ্জগুলির একটি হ'ল প্রয়োজনীয়তা ক্যাপচার করা; এটি এই প্রশ্নের উত্তর দেওয়ার জন্য, "এই সফ্টওয়্যারটি কী করবে?" সিস্টেমটি কী করা দরকার তা সঠিকভাবে সংজ্ঞায়িত করার জন্য সফ্টওয়্যারটির যথাযথ প্রয়োজনীয়তা প্রয়োজন, তবে যারা সফ্টওয়্যার সিস্টেম এবং প্রকল্পগুলির প্রয়োজনীয়তা সংজ্ঞায়িত করেন তাদের প্রায়শই এমন লোকদের অন্তর্ভুক্ত থাকে যাদের সফ্টওয়্যার বা ফর্মাল (গণিত) পটভূমি নেই। প্রয়োজনীয়তার সংজ্ঞায় কঠোরতার অভাব সফ্টওয়্যার বিকাশকে সফ্টওয়্যারকে প্রয়োজনীয়তার সাথে বৈধতা দেওয়ার উপায় খুঁজতে বাধ্য করে।
উন্নয়ন টিম একটি প্রকল্পের জন্য চালচলনের বর্ণনা আরও কঠোর প্রয়োজনীয়তার সাথে অনুবাদ করত। সফ্টওয়্যার বিকাশের চেকপয়েন্ট হিসাবে টেস্টিং শৃঙ্খলা একত্রিত হয়েছে, কোনও গ্রাহক যা চান তার যাচাই করে এবং কোন সফ্টওয়্যার বোঝে তারা কী চায় তার মধ্যে ব্যবধান পূরণ করতে পারে। সফটওয়্যার বিকাশকারী এবং মান / পরীক্ষার দল উভয়ই (অনানুষ্ঠানিক) নির্দিষ্টকরণের বোঝার গঠন করে এবং প্রত্যেকে (স্বতন্ত্রভাবে) সফ্টওয়্যার বা পরীক্ষাগুলি তাদের বোধগম্যতা নিশ্চিত করে তা নিশ্চিত করে। প্রয়োজনীয়তাগুলির যথার্থতা আরও বাড়িয়ে তোলার জন্য (অনর্থক) প্রয়োজনীয়তাগুলি বোঝার জন্য অন্য ব্যক্তিকে যুক্ত করা প্রশ্ন এবং বিভিন্ন দৃষ্টিভঙ্গি যুক্ত করেছে।
যেহেতু সর্বদা গ্রহণযোগ্যতা পরীক্ষা ছিল, তাই স্বয়ংক্রিয় এবং ইউনিট পরীক্ষা লেখার জন্য পরীক্ষার ভূমিকাটি প্রসারিত করা স্বাভাবিক ছিল natural সমস্যাটি হ'ল টেস্টিং করার জন্য প্রোগ্রামারদের নিয়োগের অর্থ ছিল এবং আপনি গুণমানের আশ্বাস থেকে শুরু করে প্রোগ্রামিংকারীদের পরীক্ষা করার ক্ষেত্রে দৃষ্টিভঙ্গি সংকুচিত করেছিলেন।
এগুলি সমস্তই বলেছিল, যদি আপনার পরীক্ষাগুলি প্রকৃত প্রোগ্রামগুলির থেকে সামান্য আলাদা হয় তবে আপনি সম্ভবত পরীক্ষার ভুল করছেন। এমএসডি পরামর্শ হ'ল পরীক্ষাগুলিতে কী কী করা উচিত, এবং কীভাবে তার উপর কম।
বিড়ম্বনাটি হ'ল চলাকালীন বর্ণনা থেকে প্রয়োজনীয়তার আনুষ্ঠানিক স্পেসিফিকেশন ক্যাপচার করার পরিবর্তে শিল্পটি পরীক্ষার স্বয়ংক্রিয়করণের কোড হিসাবে পয়েন্ট টেস্টগুলি প্রয়োগ করার সিদ্ধান্ত নিয়েছে। কোন সফ্টওয়্যার উত্তর দেওয়ার জন্য আনুষ্ঠানিক প্রয়োজনীয়তা তৈরি করার পরিবর্তে, গ্রহণযোগ্য পদ্ধতির আনুষ্ঠানিক যুক্তি ব্যবহার করে বিল্ডিং সফটওয়্যারটির চেয়ে কয়েক পয়েন্ট পরীক্ষা করা হয়েছিল। এটি একটি আপস, তবে মোটামুটি কার্যকর এবং তুলনামূলকভাবে সফল।
আপনি যদি মনে করেন যে আপনার পরীক্ষার কোডটি আপনার প্রয়োগের কোডের সাথে খুব সাদৃশ্যপূর্ণ, তবে এটি একটি ইঙ্গিত হতে পারে যে আপনি একটি উপহাস ফ্রেমওয়ার্ককে অতিরিক্ত ব্যবহার করছেন। খুব কম স্তরে মক-ভিত্তিক পরীক্ষা-নিরীক্ষাটি পরীক্ষার পদ্ধতিটির মতো দেখতে অনেকটা পরীক্ষার সেটআপ দিয়ে শেষ হতে পারে। আপনি যদি আপনার প্রয়োগটি পরিবর্তন করেন তবে উচ্চ মাত্রার পরীক্ষাগুলি ভাঙ্গার সম্ভাবনা কম লেখার চেষ্টা করুন (আমি জানি এটি কঠিন হতে পারে, তবে আপনি যদি এটি পরিচালনা করতে পারেন তবে ফলস্বরূপ আপনার আরও কার্যকর টেস্ট স্যুট থাকতে হবে)।
ইউনিট পরীক্ষাগুলিতে পরীক্ষার অধীনে কোডটির সদৃশ হওয়া উচিত নয়, যেমনটি ইতিমধ্যে উল্লেখ করা হয়েছে।
যদিও আমি যুক্ত করব, সেই ইউনিট পরীক্ষাগুলি সাধারণত "উত্পাদন" কোড হিসাবে ডিআরওয়াই হিসাবে হয় না, কারণ সেটআপগুলি পরীক্ষার সময় একই রকম (তবে অভিন্ন নয়) প্রবণতা থাকে ... বিশেষত যদি আপনার উল্লেখযোগ্য সংখ্যক নির্ভরতা থাকে যা আপনি উপহাস করছেন / faking।
এই ধরণের জিনিসটিকে একটি সাধারণ সেটআপ পদ্ধতিতে (বা সেটআপ পদ্ধতির সেট) রূপে রিফ্যাক্টর করা অবশ্যই সম্ভব ... তবে আমি খুঁজে পেয়েছি যে এই সেটআপ পদ্ধতিগুলির দীর্ঘ পরামিতি তালিকা রয়েছে এবং তার চেয়ে ভঙ্গুর হতে পারে।
তাই ব্যবহারিক হতে হবে। যদি আপনি রক্ষণাবেক্ষণের সাথে আপস না করে সেটআপ কোডটি একত্রীকরণ করতে পারেন তবে তা সর্বদা করুন। তবে বিকল্পটি যদি সেটআপ পদ্ধতির একটি জটিল এবং ভঙ্গুর সেট হয় তবে আপনার পরীক্ষার পদ্ধতিগুলিতে কিছুটা পুনরাবৃত্তি ঠিক আছে।
একটি স্থানীয় টিডিডি / বিডিডি প্রচারক এটিকে এইভাবে রাখে:
"আপনার প্রোডাকশন কোডটি DRY হওয়া উচিত But তবে আপনার পরীক্ষাগুলি 'আর্দ্র' হওয়া ঠিক আছে।"
দেখে মনে হচ্ছে পরীক্ষাগুলি মূলত কোড হিসাবে একই জিনিসটি প্রকাশ করে এবং তাই কোডটির একটি সদৃশ (ধারণা হিসাবে, বাস্তবায়ন নয়)।
এটি সত্য নয়, পরীক্ষাগুলি ব্যবহারের কেসগুলি বর্ণনা করে, অন্যদিকে কোডটি একটি অ্যালগরিদম বর্ণনা করে যা ব্যবহারের ক্ষেত্রে পাস করে, যা আরও সাধারণ। টিডিডি দ্বারা আপনি ব্যবহারের কেসগুলি (সম্ভবত ব্যবহারকারী গল্পের উপর ভিত্তি করে) লেখা শুরু করেন এবং তারপরে আপনি এই ব্যবহারের ক্ষেত্রে পাস করার জন্য প্রয়োজনীয় কোডটি প্রয়োগ করেন। সুতরাং আপনি একটি ছোট পরীক্ষা লিখুন, কোডের একটি ছোট অংশ এবং এরপরে পুনরাবৃত্তিগুলি থেকে মুক্তি পাওয়ার জন্য আপনি যদি রিফ্যাক্টরটি করেন। এটি কিভাবে এটি কাজ করে।
পরীক্ষার মাধ্যমে পুনরাবৃত্তিও হতে পারে। উদাহরণস্বরূপ, আপনি ফিক্সচার, ফিক্সচার জেনারেটিং কোড, জটিল দৃser়তা ইত্যাদি পুনরায় ব্যবহার করতে পারেন ... পরীক্ষাগুলিতে বাগগুলি রোধ করার জন্য আমি সাধারণত এটি করি, তবে কোনও পরীক্ষায় সত্যিই ব্যর্থ হয় কিনা তা আমি সাধারণত প্রথমে পরীক্ষা করতে ভুলে যাই, এবং এটি দিনটিকে সত্যই ধ্বংস করতে পারে আপনি যখন অর্ধ ঘন্টা কোডে বাগটি খুঁজছেন এবং পরীক্ষাটি ভুল ... এক্সডি