টিডিডিতে পুনরায় নকশার পরে সেই পদ্ধতিটি ব্যক্তিগত হয়ে গেলে পদ্ধতির পরীক্ষা দিয়ে কী ঘটে?

Question

ধরা যাক আমি অন্যান্য চরিত্র এবং সেই ধরণের স্টাফকে আক্রমণ করে এমন অক্ষরগুলির সাথে একটি ভূমিকা গেম বিকাশ করা শুরু করি।

টিডিডি প্রয়োগ করে আমি যুক্তির অভ্যন্তরীণ Character.receiveAttack(Int)পদ্ধতির পরীক্ষার জন্য কয়েকটি পরীক্ষার কেস তৈরি করি । এটার মতো কিছু:

@Test
fun healthIsReducedWhenCharacterIsAttacked() {
    val c = Character(100) //arg is the health
    c.receiveAttack(50) //arg is the suffered attack damage
    assertThat(c.health, is(50));
}

বলুন আমার কাছে 10 টি পরীক্ষার receiveAttackপদ্ধতি রয়েছে। এখন, আমি একটি পদ্ধতি যুক্ত করি Character.attack(Character)(যে receiveAttackপদ্ধতিটি কল করে ), এবং কিছু টিডিডি চক্র পরীক্ষা করার পরে, আমি সিদ্ধান্ত নিই: Character.receiveAttack(Int)হওয়া উচিত private।

আগের দশটি পরীক্ষার ক্ষেত্রে কী ঘটে? আমি তাদের মুছে ফেলা উচিত? publicআমার কি পদ্ধতি রাখা উচিত (আমি তা মনে করি না)?

এই প্রশ্নটি কীভাবে ব্যক্তিগত পদ্ধতিগুলি পরীক্ষা করতে হয় তা নয় তবে টিডিডি প্রয়োগ করার সময় পুনরায় নকশার পরে কীভাবে সেগুলি মোকাবেলা করা যায়

Comments

সম্ভাব্য সদৃশ টেস্টিং ব্যক্তিগত পদ্ধতি সংরক্ষিত যেমন

— মশা

এটি যদি ব্যক্তিগত হয় তবে আপনি এটি পরীক্ষা করেন না, এটি এত সহজ।

— অপসারণকারী

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

— ব্যবহারকারী 9993

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

— মশা

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

— ব্যবহারকারী 9993

Answer 1

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

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

এবং যদি এটি না হয়, তবে এতে কার্যকারিতা রয়েছে receiveAttackযা আর প্রয়োজন হয় না এবং এর আর অস্তিত্ব থাকা উচিত নয়!

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

Comments

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

— ডেভিড আরনো

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

— ম্যাথিউ এম।

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

— ডেভিড আরনো

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

— আরএম

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

— ডেভিড আরনো

Answer 2

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

public class X {
  private int complexity(...) {
    ...
  }
  public void somethingElse() {
    int c = complexity(...);
  }
}

করুন:

public class Complexity {
  public int calculate(...) {
    ...
  }
}

public class X {
  private Complexity complexity;
  public X(Complexity complexity) { // dependency injection happiness
    this.complexity = complexity;
  }

  public void something() {
    int c = complexity.calculate(...);
  }
}

এক্স.কম্পলেক্সটির জন্য বর্তমান পরীক্ষাটি জটিলতা টেস্টে সরান। তারপরে জটিলতাটিকে ঠাট্টা করে এক্স টেক্সট করুন।

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

Comments

আপনার উত্তরটি আরও বেশি স্পষ্টভাবে সেই ধারণাটি ব্যাখ্যা করে যা আমি ওপির প্রশ্নের বিষয়ে আমার মন্তব্যে ব্যাখ্যা করার চেষ্টা করছিলাম। চমৎকার উত্তর.

— ব্যবহারকারী 9993

আপনার উত্তরের জন্য ধন্যবাদ. আসলে, রিসিভএট্যাক পদ্ধতিটি বেশ সহজ ( this.health = this.health - attackDamage)। এই মুহুর্তের জন্য সম্ভবত এটি অন্য শ্রেণিতে নিষ্কাশন করা একটি অতিমাত্রায়িত সমাধান।

— হেক্টর

এটি অবশ্যই ওপি'র পক্ষে অতিরিক্ত ওভারকিল - তিনি দোকানে চালনা করতে চান, চাঁদে উড়তে চান না - তবে সাধারণ ক্ষেত্রে একটি ভাল সমাধান।

যদি ফাংশনটি সহজ হয় তবে এটি খুব বেশি পরিমাণে বোঝা যায় যে এটি এমনকি প্রথম স্থানে একটি ফাংশন হিসাবে সংজ্ঞায়িত করা হয়েছে।

— ডেভিড কে

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

— স্টিফেন

Answer 3

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

এখানে মনে রাখার মতো কিছু হ'ল আপনি যে সিদ্ধান্তটি নিচ্ছেন তা হ'ল এপিআই থেকে কোনও পদ্ধতি অপসারণ করা । পিছনের সামঞ্জস্যের সৌজন্য পরামর্শ দেয়

1. আপনার যদি এটি অপসারণের প্রয়োজন না হয় তবে এটি এপিআইতে রেখে দিন
2. যদি আপনার এখনও এটি অপসারণের প্রয়োজন না হয় , তবে এটিকে অবহিত হিসাবে চিহ্নিত করুন এবং যদি জীবনের শেষটি ঘটবে তখন সম্ভব নথি হিসাবে চিহ্নিত করুন
3. আপনার যদি এটি অপসারণের দরকার হয় তবে আপনার কাছে একটি বড় সংস্করণ পরিবর্তন রয়েছে

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

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

Comments

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