Android TDD আয়ত্ত করুন: Test-Driven Development-এর একটি প্র্যাক্টিক্যাল গাইড

লেখক: Siamak Mahmoudi

TDD, বা Test-Driven Development, একটি সফটওয়্যার ডেভেলপমেন্ট পদ্ধতি যেখানে আসল কোড ইমপ্লিমেন্ট করার আগে টেস্ট লিখা হয়।

এই প্রজেক্ট/ফিচারের প্রয়োজনীয়তায় "কী" এবং "কীভাবে" সম্পর্কে একটি স্পষ্ট বোঝাপড়া প্রয়োজন।

TDD কম, কিন্তু পর্যাপ্ত কোড লিখতে সাহায্য করে। এটি সাধারণ সফটওয়্যার ডেভেলপমেন্ট ভুলগুলো প্রতিরোধ করতে সাহায্য করে, যেমন ওভার-ইঞ্জিনিয়ারিং, অতিরিক্ত টেস্ট কভারেজ, মূল প্রয়োজনীয়তা মিস করা, খুব বড় ফাংশন এবং ক্লাস, এবং খুব জটিল কোড স্টেটমেন্ট।

সারসংক্ষেপে, এটি একটি সংক্ষিপ্ত, ইতিমধ্যে ইউনিট-টেস্ট কভারড, ক্লিন কোডবেস পেতে সাহায্য করে। সময়ের সাথে সাথে, এটি ডেভেলপমেন্ট এবং কোড মেইনটেনেন্স খরচও বাঁচায়।

এই আর্টিকেলে আমরা TDD-কে একশনে আলোচনা করব।

কনটেক্স্ট হলো একটি Android ডেভেলপমেন্ট এনভায়রনমেন্ট, তাই আমরা Kotlin এবং JUnit5 ব্যবহার করব একটি স্যাম্পল প্রজেক্টের সাথে ধাপগুলো প্রদর্শন করার জন্য।

তবে, এখানে দেওয়া নির্দেশনা এবং টেকনিকগুলো অন্যান্য প্রোগ্রামিং ল্যাঙ্গুয়েজেও অনুশীলন করা যাবে।

পূর্বশর্ত

• Kotlin-এর বেসিক জ্ঞান
• ইউনিট টেস্ট লিখার বেসিক জ্ঞান
• Mocks এবং assertions-এর জ্ঞান

আমরা Kotlin ব্যবহার করব প্রোগ্রামিং ল্যাঙ্গুয়েজ হিসেবে এবং JUnit5 ইউনিট টেস্ট লিখার জন্য।

Mockito ব্যবহার করা হবে mocks এবং spys-এর সাথে কাজ করার জন্য।

টার্গেট অডিয়েন্স যেকোনো সফটওয়্যার ডেভেলপার যারা তাদের ক্যারিয়ারে একটি নতুন অধ্যায় খুঁজছেন।

যদিও কনটেক্স্ট Android, কনটেন্টটি প্ল্যাটফর্ম-স্পেসিফিক প্রোপার্টি সম্পর্কে কথা বলে না। বরং, আমরা TDD-তে ডেভেলপ করার টেকনিক, নোটস এবং চ্যালেঞ্জের ওপর ফোকাস করব।

যদি উপরের সব ঠিক থাকে, চলুন শুরু করি।

Test Driven Development কীভাবে কাজ করে

TDD Cycle

ডেভেলপমেন্ট প্রক্রিয়াটি একটি সাইকেল ফলো করে:

1. একটি ব্যর্থ টেস্ট লিখা (গুলাবি বর্গ)।
2. টেস্ট পাস করার জন্য কোড ইমপ্লিমেন্ট করা (সবুজ বর্গ)
3. প্রয়োজন অনুযায়ী কোড রিফ্যাক্টর করা (নীল বর্গ) নিশ্চিত করে যে টেস্টগুলো পাস করছে (হালকা সবুজ বর্গ)।
4. একটি নতুন ব্যর্থ টেস্ট লিখা (ফ্লো পুনরায় শুরু করা)

একটি ব্যর্থ টেস্ট লিখা (গুলাবি বর্গ)

এই ধাপে, আপনি শুরু করুন আপনি আপনার কোড কী করবে সেটি বর্ণনা করে।

কল্পনা করুন আপনি আপনার কোডকে একটি টেস্ট দিচ্ছেন চেক করতে যে এটি সঠিকভাবে behave করছে কিনা। এই টেস্টটি আপনার কোড থেকে একটি প্রশ্ন করার মতো, যেমন "তুমি কি এই টাস্কটি করতে পারো?"

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

এই স্টেজ শেষ হলে, JUnit5 আপনার তৈরি করা টেস্টগুলো থেকে একটি বিস্তারিত রিপোর্ট জেনারেট করবে। এই টেস্টগুলো আপনার কাজের একটি मूর্ত প্রতিনিধিত্ব হিসেবে দাঁড়াবে।

এখন কল্পনা করুন আপনার প্রজেক্ট ম্যানেজার এই টেস্ট কেসগুলো পড়ছেন যেন সেগুলোর কভারেজ এবং আপনার ফিচার বা প্রোডাক্টের ওপর ধারণার নির্ভুলতা आँকা যায়। এই পের্সপেক্টিভ গ্রহণ করলে এই ডেভেলপমেন্ট ফেজের তাৎপর্য পরিষ্কার হয়ে উঠে।

তাত্ত্বিক জটিলতা থেকে ফোকাস শিফ্ট করুন সফটওয়্যারের আচরণের ওপর।

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

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

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

কিছু কেসে, আপনি প্রতিটি কম্পোনেন্টের জন্য কিছু تعداد টেস্ট কেস দিয়ে শেষ করতে পারেন (যেটিই উদ্দেশ্য: কম কাজ কিন্তু টার্গেটেড) এবং এটিই ঠিক আছে, যতক্ষণ না আপনি প্রজেক্টের সব behavioural requirements কভার করেন।

টিপস

• নির্দিষ্ট হোন: স্পষ্ট এবং নির্দিষ্ট টেস্ট কেস লিখুন যা আপনার কোডের আচরণের একটি দিকে ফোকাস করে।
• সহজ থেকে শুরু করুন: যে সিম্পল টেস্ট কেসটি বেসিক ফাংশনালিটি কভার করে সেটি থেকে শুরু করুন।

@Test fun `a sum is calculated from two input numbers`() {} 

• অর্থবহ নাম ব্যবহার করুন: আপনার টেস্টগুলোর বর্ণনামূলক নাম দিন যাতে কেউ পড়লে বুঝতে পারে টেস্টটি কী চেক করছে।

@Test fun `Font Ratio is fetched from data source INITIALLY`() {} 

সাধারণ ভুলগুলো এড়াতে

• একসাথে খুব বেশি টেস্ট করা: একক টেস্টে একাধিক জিনিস টেস্ট করা এড়ান। এটা ব্যর্থতা কী তা চিহ্নিত করা কঠিন করে দেয়।

// Don't do this @Test fun `pixelSize fits the standart sizes while fontSize is bigger than minumum supported font size but matches the list of special levels of size`() {} 

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

// Don't do this @Test fun `pixelSize is Long and Non-Null and fits the standart sizes then calculated font size is non-null and of type Dimention`() {} 

টেস্ট পাস করার জন্য কোড ইমপ্লিমেন্ট করা (সবুজ বর্গ)

এখন যেহেতু আপনার টেস্টটি জায়গা পেয়েছে, আপনার কোডকে শেখানোর সময় যাতে সেটি টাস্কটি সঠিকভাবে করতে পারে।

আপনি আসল কোড লিখবেন যা টেস্টটি পাস করাতে পারে এবং আপনার কোড প্রশ্নটির সঠিক जवাব দিতে পারে।

যখন আপনার কোড টেস্ট পাস করে, সেটি একটি সবুজ বাতির মতো, "হ্যাঁ, আমি এখন টাস্কটি করতে পারি!"।

এই ধাপটি নিশ্চিত করার জন্য যে আপনার কোড সমস্যাটি বুঝতে এবং সমাধান করতে পারে।

টিপস

• ন্যূনতম কোড লিখুন: সিম্পলেস্ট কোড লিখুন যা ব্যর্থ টেস্টটি পাস করাবে। ওভার-ইঞ্জিনিয়ারিং এড়াতে এখানে পড়তে পারেন।

// Test Case @Test fun `Storage stores font ratio in key-value`() { // Given val fontRatio = 2.0f val mockEditor = mockk<SharedPreferences.Editor>(relaxed = true) every { mockSharedPreference.edit() } returns mockEditor every { mockEditor.putFloat(any(), any()) } returns mockEditor every { mockEditor.apply() } just Runs // When storage.saveFontRatio(fontRatio) // Then verify(exactly = 1) { mockEditor.apply() } } // Correct Implementation - Avoid extra implementation class SharedPreferenceHelper( private val sharedPreferences: SharedPreferences ) { fun saveFontRatio(fontRatio: Float) { sharedPreferences.edit().putFloat("font-ratio", fontRatio).apply() } } // Wrong Implementation class SharedPreferenceHelper( private val sharedPreferences: SharedPreferences ) { fun saveFontRatio(fontRatio: Float) { if (fontRatio <= 0.0f) throw IllegalArgumentException("Font ratio must be greater than 0.0f") storeValue(key = FONT_RATIO_KEY, value = fontRatio) } private fun storeValue(key: String, value: Float){ val editor = sharedPreferences.edit() editor.putFloat(key, value) editor.apply() } fun getFontRatio(): Float { return sharedPreferences.getFloat("font_ratio", 1.0f) } } 

• ডুপ্লিকেশন এড়ান: কোড রিপিট করবেন না। আপনি যদি একই লজিক একাধিক জায়গায় লিখতে পান, তবে রিফ্যাক্টর করার কথা চিন্তা করুন। এই প্রাথমিক কোড উন্নতিটি এই ফেজে করা যাবে, কিন্তু যদি মডিফিকেশনের সাইড-ইফেক্ট হতে পারে তবে এটিকে উপেক্ষা করুন।

class ... { override fun getDefaultFontSize(): Float { val zoomRatio = DEFAULT_SSPEED * DEFAULT_FONT_RATIO / deviceDensity val fontSize = zoomRatio * standardFontSize return fontSize } override fun getFontSizeBySSpeed(speed: Int): Float { val zoomRatio = speed * DEFAULT_FONT_RATIO / deviceDensity val fontSize = zoomRatio * standardFontSize return fontSize } } 

class ... { override fun getDefaultFontSize(): Float = calculate(DEFAULT_AGE) override fun getFontSizeByAge(age: Int): Float = calculate(age) private fun calculate(age: Int): Float { val zoomRatio = age * DEFAULT_FONT_RATIO / deviceDensity val fontSize = zoomRatio * standardFontSize return fontSize } } 

সাধারণ ভুলগুলো এড়াতে:

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

কোড রিফ্যাক্টর করা (নীল বর্গ) এবং টেস্ট সাফল্য নিশ্চিত করা (হালকা সবুজ বর্গ)

একবার আপনার কোড টেস্ট পাস করলে, জিনিসগুলো পরিষ্কার করার সময়।

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

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

আপনি এই অংশটিকে একটি আলাদা কোড মেইনটেনেন্স ফেজ হিসেবে বিতর্ক করতে পারেন।

ধরুন আপনাকে পুরনো কোড পরিষ্কার করে টিম কোড কোয়ালিটি গাইডলাইন এবং প্রোডাক্ট রিকোয়ারমেন্ট অনুসরণ করার টাস্ক দেওয়া হয়েছে।

এই প্রক্রিয়া 전반ে, কী হলো একটি সতর্ক ব্যালেন্স বজায় রাখা - রিফাইন করা면서 নিশ্চিত করা যে আপনার টেস্টগুলো সফল হতে থাকে।

রিফ্যাক্টরিং ফেজের জন্য কিছু আইডিয়া এবং স্ট্র্যাটেজি:

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

নোট করুন যে TDD কোড সেলফ-এক্সপ্রেসিং হওয়া উচিত এবং ডকুমেন্টেশনের ওপর স্বাধীন।

মনে রাখবেন, রিফ্যাক্টরিং করার সময়, আপনার সব টেস্ট চালিয়ে রাখা গুরুত্বপূর্ণ নিশ্চিত করতে যে সেগুলো পাস করতে থাকে।

টিপস

• টেস্টগুলো ব্যাপক রাখুন: নিশ্চিত করুন আপনার টেস্টগুলো বিভিন্ন সিনেরিও কভার করে যাতে রিফ্যাক্টরিং-এর সময় অনিচ্ছাকৃত সাইড-ইফেক্ট ধরা পড়ে।
• ক্রমাগত রিফ্যাক্টর করুন: আপনার কোডে ছোট ছোট পরিবর্তন আনুন এবং টেস্টগুলো ঘন ঘন চালান যাতে রিগ্রেশন জলদে ধরা পড়ে।

সাধারণ ভুলগুলো এড়াতে:

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

একটি নতুন ব্যর্থ টেস্ট লিখা (ফ্লো পুনরায় শুরু করা)

এখন, আপনি আপনার কোডের পরবর্তী কী করতে চান সেটি চিন্তা করুন।

আপনি একটি নতুন টেস্ট লিখে শুরু করবেন যা ফেল করা উচিত কারণ আপনার কোড এখনো না জানে নতুন টাস্কটি কীভাবে করতে হয়। এটা আপনার কোডকে একটি নতুন চ্যালেঞ্জ দেয়ার মতো।

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

এভাবে, আপনি সারাবার অগ্রসর হচ্ছেন এবং আপনার কোড ধাপে ধাপে বানাচ্ছেন।

টিপস

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

ফিডব্যাক লüp কীভাবে কাজ করে:

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

ফিডব্যাক লুপ নিশ্চিত করে যে আপনার ডেভেলপমেন্ট আপনার সফটওয়্যারের উদ্দেশ্য লক্ষ্যগুলোর সাথে টাইটলি সৈলendu।

সাধারণ ভুলগুলো এড়াতে:

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

এখানে কেন আপনাকে ব্যর্থ টেস্ট ধাপটি স্কিপ করা উচিত নয় এমনকি আপনি আত্মবিশ্বাসী থাকলে:

• ইচ্ছার স্পষ্টতা: একটি ব্যর্থ টেস্ট লিখা আপনার ফিচারের জন্য ইচ্ছা স্পষ্ট করে। এটি আপনাকে বাধ্য করে সঠিক আচরণ এবং ফলাফল বিবেচনা করার জন্য ইমপ্লিমেন্টেশনে ডুবতে আগে।
• অনুমান যাচাই: এমনকি আপনি মনে করেন আপনি ফিচারটি বুঝছেন, একটি টেস্ট তৈরি করা নিশ্চিত করে আপনার অনুমানগুলো বৈধ। আপনার বোঝাপড়া সঠিক হতে পারে, কিন্তু টেস্টটি এটিকে যাচাই করে।
• সেফটি নেট: একটি ব্যর্থ টেস্ট লিখে, আপনি একটি সেফটি নেট স্থাপন করছেন যা ভবিষ্যতে রিগ্রেশন প্রতিরোধ করে। এটি ফিচারের একটি স্পেসিফিকেশন হিসেবে কাজ করে এবং অনিচ্ছাকৃত সাইড-ইফেক্ট ধরা পড়াতে সাহায্য করে।
• ইনক্রিমেন্টাল ডেভেলপমেন্ট: TDD ইনক্রিমেন্টাল ডেভেলপমেন্ট অনুপ্রেরণা করে। প্রতিটি নতুন ফিচার ধাপে ধাপে বিল্ড হয়, একটি স্পষ্ট প্রগ্রেশন 실패 টেস্ট থেকে ওয়ার্কিং ইমপ্লিমেন্টেশনে। এই ধাপটি স্কিপ করলে সেই প্রগ্রেশন ভাঙে।
• ডকুমেন্টেশন: ব্যর্থ টেস্ট ফিচারের প্রত্যাশিত আচরণ ডকুমেন্ট করে। এই ডকুমেন্টেশন আপনার এবং আপনার টিমের জন্য মূল্যবান, বিশেষ করে ভবিষ্যতে কোড পুনর্বিবেচনা করার সময়। মনে রাখুন যে আপনার সব টেস্ট কোড লিস্ট করে প্রোডাক্ট ম্যানেজার এবং QA-র জন্য রিপোর্ট জেনারেট করার সিস্টেম রয়েছে। সেই রিপোর্টগুলো আপনি প্রোডাক্টে যা চিহ্নিত করেছেন সেগুলো এক্সপোজ করে, তাই, চেষ্টা করুন সেগুলোককে মনে করানো যে আপনি পয়েন্টটি ভালোভাবে বুঝেছেন।

TDD ব্যবহার করে কীভাবে ডেভেলপ করবেন

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

কিন্তু আমরা কীভাবে এটিকে প্র্যাক্টিসে আনব? এটি ট্রাই করে এবং ধীরে ধীরে অভ্যস্ত হয়ে।

চলুন TDD ট্রাই করি একটি নতুন ফিচার ডেভেলপ করে দেখানোর জন্য কীভাবে আমরা এটি রিয়েল ওয়ার্ল্ডে ব্যবহার শুরু করতে পারি।

আমরা একটি ফন্ট সাইজ অটো সেটিং ফিচার ইমপ্লিমেন্ট করব।

আমাদের একটি নিউজ অ্যাপ আছে এবং একজন ব্যবহারকারী নিউজ ফিডের জন্য অটো-স্ক্রোল-স্পিড সেট করতে পারে।

আমরা একটি ফিচার ইমপ্লিমেন্ট করতে চাই যা User Profile পেজে সেট করা স্ক্রোল স্পিড থেকে স্ক্রিন ফন্ট সাইজ অ্যাসজাস্ট করবে।

ব্যবহারকারী যদি স্ক্রোল স্পিড ০ থেকে ১ সেট করে, তবে ফন্ট সাইজ ১.৩ বাড়বে।

১ এর উপর যেকোনো স্ক্রোল স্পিড ইনক্রিমেন্ট ফন্ট সাইজ ১.২ বাড়াবে।

এই ফিচারটি ব্যবহারকারীদের খবর পড়ার সময় ভালো অভিজ্ঞতা দিতে দেয়।

আমি এই আর্টিকেলে এক্সপ্লোর করা কোডটি এই GitHub রিপোজিটরিতে শেয়ার করেছি।

ফিল ফ্রি টু ক্লোন অ্যান্ড প্লে উইড ইট।

আমরা ডেভেলপমেন্টে যেন প্রগ্রেস করছি সেটি ফলো করার চেষ্টা করুন। এটি আপনাকে TDD-এর কনটেক্স্টে টেকনিক এবং চিন্তা করার পদ্ধতি বুঝতে সাহায্য করবে।

তাহলে, Android Studio খুলুন এবং একটি নতুন প্রজেক্ট তৈরি করুন।

Font Size Auto Setting Feature Data Flow Chart

একটি android অ্যাপে স্যাম্পল ফিচারের DFD

উপরে সেটি হলো ডেটা ফ্লো কেমন দেখাবে শেষে।

এখানে প্রতিটি জড়িত কম্পোনেন্টের আউटलাইন:

AutoScrollSettingsUseCase ক্লাসটি সিলেক্ট করা Scroll Speed-এর ভিত্তিতে FontRatio ক্যালকুলেট এবং স্টোর করার লজিক হ্যান্ডেল করবে।

এই ইউজ কেসের UserRepository ওপর একটি ডিপেন্ডেন্সি থাকবে FontRatio ভ্যালু স্টোর করার জন্য।

UserRepository-এ, FontRatio ভ্যালু স্টোর এবং রিট্রিভ করার মেথড রয়েছে Storage মেকানিজম ব্যবহার করে। যতক্ষণ একটি নতুন FontRatio স্টোরেজে পাঠানো হয়, যেকোনো অবজার্বেবলস লেটেস্ট ভ্যালু সহ একটি ইমিশন পাবে।

UserProfileViewModel-এ, একটি AutoScrollSettingsUseCase ইনস্ট্যান্স রয়েছে যা কল হয় যতক্ষণ ব্যবহারকারী Scroll Speed আপডেট করে। এটি FontRatio রিক্যালকুলেশন ট্রিগার করবে এবং সেটি রিপোজিটরি দিয়ে স্টোর হবে।

আমাদের ইউজার সেটিং সেকশনে প্রয়োজনীয় UI কম্পোনেন্ট থাকবে যেন ব্যবহারকারী তাদের পছন্দের স্ক্রোল স্পিড ইনপুট দিতে পারে। এটি স্ট্যান্ডার্ড Android UI এলিমেন্ট যেমন NumberPicker বা কাস্টম UI কম্পোনেন্ট দিয়ে করা যায় (আমরা এই অংশগুলো আলোচনা করব না)।

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

টেস্ট কীভাবে লিখবেন

প্রথম ধাপ হচ্ছে সবসময় টেস্ট ক্লাসটি নিজে তৈরি করা। এই কেসে, আমাদের কমপক্ষে নিচের টেস্ট ক্লাসগুলো থাকবে:

• UserRepositoryTest
• AutoScrollSettingTest
• UserSettingsViewModelTest

আমি ViewModel পার্টটি থেকে শুরু করতে পছন্দ করি।

একটি ViewModel হলো একটি Android আর্কিটেকচার কম্পোনেন্ট যা লাইফসাইকেল চেঞ্জ থেকে বাঁচে (যেমন ফোরগ্রাউন্ড, ব্যাকগ্রাউন্ড, ফোকাসড)। তাই, এটি আমাদের স্টেট সংরক্ষণের একটি ভালো জায়গা।

টেস্ট ফাইলটি তৈরি করুন unitTest ডিরেক্টরিতে সোর্স কোডের আন্ডারে একই প্যাকেজ পাথ ফলো করে।

TDD প্র্যাক্টিসে লিগেসি ওয়ার্ক ডেভেলপমেন্ট থেকে ভিন্ন।

TDD-তে আমরা IDE ব্যবহার করি ফাইল এবং প্রোপার্টি (ফিল্ডস) তৈরি প্রক্রিয়া বুস্ট করার জন্য। কিন্তু আমরা টেস্ট ফাইলগুলো ম্যানুয়ালি তৈরি করি! কয়েকবার ট্রাই করলে, IDE-এর এই দিকটি হ্যান্ডি হয়ে যাবে।

কোড স্ট্রাকচার (প্যাকেজ) তৈরি করুন এবং তারপর প্যাকেজে রাইট ক্লিক করে Class টাইপ সিলেক্ট করে আপনার টেস্ট ক্লাস তৈরি করুন।

একটি বর্ণনামূলক নাম বেছে নিন (হয়তো আপনাকে এর জন্য একটি কনভেনশন ফলো করতে হবে যদি আপনি ইতিমধ্যে না করেন)।

উদাহরণস্বরূপ: xxx is tested for, যেখানে xxx হলো টেস্ট করা কম্পোনেন্টের নাম।

IDE ব্যবহার করে ফাইল তৈরি

এখন, খালি টেস্টগুলো তৈরি করুন। যতটুকু সম্ভব ব্রড হতে চেষ্টা করুন।

ডায়াগ্রাম অনুযায়ী, এই ফিচারের জন্য আমাদের বেশি লজিক নেই।

ইউনিট টেস্ট ফাংশন লিখার দুটি মূল স্ট্র্যাটেজি রয়েছে:

• AAA
• Given/When/Then

@Test fun `strategy A`(){ // Arrange // Act // Assert } @Test fun `strategy B`(){ // Given // When // Then } 

একটি বেছে নিন এবং আপনার সব টেস্টের জন্য সেটি ফলো করুন।

কনসেপ্টটি একই: আপনার টেস্ট কোড ক্লাস্টার করুন যাতে সেটি পড়া এবং মেইনটেইন করা সহজ হয়।

এটি হলো আমার এখনকার অবস্থা:

class `UserProfileViewModel is tested for` { // Unimplemented Class val viewModel = UserProfileViewModel() @Test fun Font Ratio is fetched from data source`(){} @Test fun `Scroll Speed update is called so fontSize calculations are triggered`() {} @Test fun `Font Ratio is updated with new emissions from data source`() {} } 

চলুন টেস্টগুলো চালাই!

Missing Test Target کے কারন ফেল করা টেস্ট

এটি ফেল করছে। আসলে, বিল্ড ফেল করছে- টেস্ট নয়।

অভিনন্দন! আমরা TDD সাইকেলের প্রথম ধাপে পৌঁছেছি:

TDD সাইকেলের প্রথম ধাপ

যেহেতু ViewModel এখনো অস্তিত্বে নেই, লাল রঙ দেখাচ্ছে।

এখন, ViewModel-এর একটি ইনস্ট্যান্স তৈরি করি,

তাহলে, আমরা একটি IDE ব্যবহার করি একটি মিসিং ক্লাস বা অনুইমপ্লিমেন্টেড কোড তৈরি করতে।

এই ডায়ালগ পপ আপ করতে, আমি পয়েন্টারকে অনুইমপ্লিমেন্টেড অংশে নিয়ে যাই এবং Option + Return চাপি (macOS-এ)।

তারপর, প্রদত্ত অপশনগুলো ফলো করুন:

TDD Action: UnitTest ফাইল দিয়ে টার্গেট ফাইল তৈরি

নতুন ফাইলের সঠিক ডেস্টিনেশন বেছে নিন

এখন আবার টেস্টগুলো রি-রান করুন (শেষ ধাপ):

টেস্ট পাস করছে দেখাচ্ছে

হ্যাঁ! এটি পাস করল।

নোট করুন যে এই টেস্টগুলোর বডি খালি এবং সেগুলো কিছুই টেস্ট করে না! এটিই সঠিক এবং ঠিক আছে।

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

এটি আরও স্পষ্ট বোঝাপড়া দেয় ফিচারটি ইমপ্লিমেন্ট করার আগে।

শেষে, আমাদের ৩-৪ টেস্ট ক্লাস থাকবে সাধারণ সিনেরিও এবং ইউনিট টেস্ট কভার করার জন্য।

এটি এমন কিছু দেখাবে:

ন্যূনতম খালি টেস্ট কেস

চলুন 그중 একটি ইমপ্লিমেন্ট করি উদাহরণ হিসেবে।

কিন্তু, এর আগে, আমাদের এই ফিচারের UI এবং Domain ডেটা মডেলের সাথে কাজ করতে হবে।

তাই, ডেটা ঘুরায়েতে সক্ষম হওয়ার জন্য, আপনার প্রয়োজনীয় ডেটা ক্লাসগুলো আগে তৈরি করুন।

আমাদের ProfileViewModel টেস্ট ক্লাসে ফিরে, আমাদের একটি খালি ইউনিট টেস্ট ফাংশন আছে। সেটি ইমপ্লিমেন্ট করি।

নোট করুন যে চাবিকাঠি হচ্ছে টেস্টটি ভালোভাবে পড়া এবং এক্সট্রা ইমপ্লিমেন্টেশন না করা নয় assertions।

শুধু requirement-ই ইমপ্লিমেন্ট করা যাবে।

এই কেসে, আমাদের একটি ডেটা স্ট্রিম দরকার যা একটি পূর্বে তৈরি ডেটা সোর্স (UserRepository)-এর সাথে কানেক্টেড।

ভুলবেন না: আমাদের প্রথমে একটি Failing Test দরকার।

ইনার বডি ইমপ্লিমেন্ট

টেস্ট ফাংশন বডির ভিতরে অনুইমপ্লিমেন্টেড অংশগুলো লক্ষ্য করুন (লাল ফন্ট দিয়ে চিহ্নিত)।

এখন, কোডটি ইমপ্লিমেন্ট করি, তারপর রিফ্যাক্টর করি শুধু পাস করার জন্য।

আমি MockK লাইব্রেরি ব্যবহার করছি ক্লাস এবং অবজেক্ট মক করার জন্য এবং Turbine ফ্লো স্ট্রিম টেস্ট করার জন্য।

আপনি যদি সেগুলোর সাথে পরিচিত নন, প্যানিক করবেন না! শুধু তাদের অফিসিয়াল ওয়েবপেজ চেক করুন এবং ট্রাই করুন।

ডিপেন্ডেন্সি প্রথমে তৈরি করুন এবং Named Arguments ব্যবহার করে ViewModel-এ যোগ করুন। Named Argument আমাদের সাহায্য করে IDE দিয়ে প্যারামিটার তৈরি করার সময় টেস্ট কোডের মাধ্যমে প্রপার নাম দিতে।

IDE ডায়ালগ দিয়ে মিসিং প্যারামিটার তৈরি

একই কাজ করুন FontRatio ভেরিয়েবলের জন্য Repository-র ভিতরে।

শেষে, ফাইনাল টেস্ট কোডটি এমন কিছু হতে পারে নিচের কোডের মতো:

class `UserProfileViewModel is tested for` { init { Dispatchers.setMain(Dispatchers.Unconfined) } val mockUserRepository = mockk<UserRepository>() @Test fun `Font Ratio is fetched from data source`() = runTest { // Given val expectedRatio = 2.0f every { mockUserRepository.fontRatio } returns flowOf(FontRatioUiModel(expectedRatio)) val viewModel = UserProfileViewModel(userRepository = mockUserRepository) // When viewModel.fontRatio.test { val fromDataSource = expectItem() // Then assertEquals(/* expected = */ expectedRatio, /* actual = */ fromDataSource.fontRatio) } } ... } 

নোট করুন যে আমরা ViewModel বা Repository-এর ইনার পার্টস ইমপ্লিমেন্ট করছি না এখানে।

আমরা শুধু মিসিং পার্টস তৈরি করছি টেস্ট বডি থেকে এরর সরাতে।

আমরা সেই ডিটেইলস পরবর্তী ইটেরেশনে ইমপ্লিমেন্ট করব।

এখন টেস্ট চালান।

অবশ্যই এটি ফেল করবে, কারণ আমরা FontRatio ইমপ্লিমেন্ট করিনি ProfileViewModel-এ।

এখন, ViewModel রিফ্যাক্টর করি টেস্ট পাস করার জন্য (ন্যূনতম ইমপ্লিমেন্টেশন)।

এই কেসে, শুধু স্টেট ফ্লোকে রিপোজিটরির সাথে কানেক্ট করতে হবে। আমরা ইতিমধ্যে এটি ডিপেন্ডেন্সি হিসেবে আগের ইটেরেশনে যোগ করেছি।

এখানে ফাইনাল কোড:

class UserProfileViewModel( userRepository: UserRepository ) : ViewModel() { val fontRatio: StateFlow<FontRatioUiModel> = userRepository.fontRatio.stateIn( initialValue = FontRatioUiModel(DEFAULT_FONT_RATIO), scope = viewModelScope, started = SharingStarted.Lazily ) companion object { private const val DEFAULT_FONT_RATIO = 1.0f } } 

আবার টেস্ট চালান, এবং Boom! এটি পাস করল!

মেইন কোডের ন্যূনতম ইমপ্লিমেন্টেশন Efter পাসিং টেস্ট

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

এই টেস্ট কেসগুলোকে সাধারণ ইউনিট টেস্টের মতো ব্যবহার করবেন না (যা দ্রুত রান এবং পাস করে)।

এতে কিছু সময় দিন টেকনিক্যাল এবং প্রোডাক্ট রিকোয়ারমেন্ট বুঝতে। তারপর, প্ল্যান রোল আউট করুন এবং ইমপ্লিমেন্টেশন শুরু করুন। কয়েকবার ট্রাই করলে, TDD-র পদ্ধতিতে চিন্তা করা সহজ হয়ে যাবে।

সোর্স কোড

এই প্রজেক্টের সোর্স কোড এবং রিপোজিটরি আমার GitHub পেজে উপলব্ধ।

ফিল ফ্রি টু চেক ইট আউট অ্যান্ড কমপ্লিট नेक्सট স্টেপস। আমি আলাদা ব্রাঞ্চে ইটেরেশনগুলো আলাদা করেছি যাতে আপনি আপনার নিজের ইমপ্লিমেন্টেশনের সাথে তুলনা করতে পারেন।

উপসংহার

তাহলে, Test-Driven Development (TDD)-এ ডুব মারা এবং এর ভেতর বাইর এক্সপ্লোর করার পর, আমি বলতে পারি, এটি একটি গেম-চেঞ্জার!

আপনাকে ব্রেক ডাউন করি:

কী পয়েন্টস:

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

আমরা টেস্ট ক্লাস তৈরি করা এবং খালি টেস্ট ফাংশন লিখা দিয়ে শুরু করলাম কিন্তু এখন এটা আপনার কাজ সেটি ফিনিশ করা (অথবা আপনি শেয়ার করা রিপোতে জাম্প করতে পারেন :) )।

এটা একটু অদ্ভুত লাগতে পারে টেস্ট থাকা যেগুলো কিছুই করে না, কিন্তু এটিই প্ল্যানের অংশ।

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

প্ল্যান হাতে, আমরা প্রয়োজনীয় কম্পোনেন্টগুলো ইমপ্লিমেন্ট করা শুরু করলাম (এই কেসে ViewModel), নিশ্চিত করে যে আমাদের টেস্টগুলো প্রথমে ফেল করছে। এটিই সঠিক, TDD-এ ব্যর্থ টেস্ট আসলে একটি ভালো জিনিস!

ক্রমাগত, আমরা টুকরোগুলো কানেক্ট করলাম, যেমন UserAutoScrollSettingsUseCase ক্লাস সেট আপ করা ফন্ট সাইজ ক্যালকুলেশন হ্যান্ডেল করার জন্য অটো-স্ক্রোল স্পিডের ভিত্তিতে (প্রজেক্ট রিপো চেক করুন)।

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

প্রক্রিয়া 전반ে, আমরা আমাদের কোড ক্লিন এবং সিম্পল রেখেছিলাম, শুধু যা প্রয়োজন টেস্ট পাস করার জন্য ফোকাস করে। অপ্রয়োজনীয় জটিলতা নেই!

শেষে, আমাদের "Font Size Auto Setting" ফিচার চলে এলো, টেস্টগুলো উজ্জ্বল রঙে পাস করল।

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

তাহলে, আপনি যদি আপনার সফটওয়্যার ডেভেলপমেন্ট গেম লেভেল আপ করতে চান, TDD-কে একটি চান্স দিন! এটি একটি শক্তিশালী পদ্ধতি যা আপনার কোডকে আরও সলিড করবে, বাগ কমাবে, এবং আপনাকে সমগ্রভাবে একজন ভালো ডেভেলপার বানাবে।

আমি যা শেয়ার করলাম, সেটি আমার টিম কীভাবে কাজ করে সেটি এবং সেটি আমাদের জন্য কাজ করছে, কিন্তু এটি সব টিম/কোম্পানির জন্য পারফেক্ট সমাধান নয়। আপনাকে বের করতে হবে আপনার জন্য সেটি কিনা। আমাকে জানান যদি আপনি মনে করেন আমি এই সমাধান উন্নত করতে পারি।

Happy coding! 🚀

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started