TDD নিয়ে আমি অনেক লিখেছি। তাই আশ্চর্য নয়, যখন আমার লাস্ট আর্টিকেল পাবলিশ হয়েছিল ঠিক সেই মিনিটে David Heinemeier Hansson RailsConf কিনোটে TDD নিয়ে কথা বললেন, তখন আমাকে কিছু প্রশ্ন করা হয়েছে:
DHH-এর TDD মতামতের সাথে একমত? এখনও TDD রিকমেন্ড করবেন? না হলে কী করব?ক
DHH কী বললেন
কিনোট মিস করলে, DHH-এর essaয় সারাংশ পাওয়া যাবে:
হয়তো টেস্ট-ফাস্ট इंडাস্ট্রির দুরবস্থা রিগ্রেশন টেস্টিংয়ে ভাঙতে কাউন্টার-ইন্টুইটিভ র্যাম হিসেবে দরকার ছিল। হয়তো এটা একটাparable ছিল যা লিটারালি ডে-টু-ডে সফটওয়্যার রাইটিং ডেসক্রাইব করার জন্য নয়। কিন্তু যা যেভাবে শুরু হয়েছিল, সেটা দ্রুত করাপ্ট হয়ে গেল। নন-বিলিভারদের হাতুড়া দিয়ে দমন করা, তাদের অনপ্রফেশনাল এবং সফটওয়্যার লিখতে অযোগ্য ঘোষণা করা। একটা লিটমাস টেস্ট।
বাস। আর নয়। আমার নাম ডেভিড, এবং আমি টেস্ট-ফাস্ট সফটওয়্যার লিখি না। আর এর জন্য কখনো ক্ষমা প্রার্থনা করব না, লুকাতে তো দূর। আমি কৃতজ্ঞ TDD-এর প্রতি যে অটোমেটেড রিগ্রেশন টেস্টিংয়ে আমার চোখ খুলল, কিন্তু আমি অনেক আগেই ডিজাইন ডগমা থেকে आगे চলে গেছি।
…
হ্যাঁ, টেস্ট-ফাস্ট আমার কাছে মর चुका। কিন্তু তার কবরে নাচার বদলে, আমি এর কন্ট্রিবিউশন সম্মান করব, ট্র্যাভেস্টিয়ের ওপর দির্ঘসূত্র নয়। এটা আমাদের ইতিহাসে একটি গুরুত্বপূর্ণ ফেজ ছিল, এখন এগিয়ে যাওয়ার সময়।
পুরো essaয় পড়ার যোগ্য, কিন্তু মূল পয়েন্টগুলো বের করলাম:
- TDD হলো অটোমেটেড রিগ্রেশন টেস্টিং উত্সাহিত করার একটা মাইন্ড 핵
- ক্রোধিত টেস্ট-ফাস্ট রেটরিক দুঃখ ও নিরাশা আনয়
- TDD ওভারলি কমপ্লেক্স অবজেক্ট ও ইন্ডিরেকশনের জাল তৈরি করে
- আপনাকে আইসোলেটেড সিস্টেম টেস্ট প্রিফার করা উচিত यুনিট টেস্টের চেয়ে
- তবে সেই প্রিফারেন্সকেও অন্য রিলিজিয়ন বানাতে হবে না
- এই কারণগুলোর জন্য, টেস্ট-ফাস্ট আর ডিজাইন প্র্যাকটিস নয় যা আপনাকে ব্যবহার করা উচিত।
essaয়-এ এই পয়েন্টগুলো একে অপরের সাথে গাঁথিয়ে দেওয়া হয়েছে। আলাদা আলাদা মেনে বুঝতে পারলেও, এগুলো এতটুকু intertwined নয়।
আপনি যদি এগুলো ভাঙে আলাদা না করেন, একটা পয়েন্ট argue করলে অন্যান্য পয়েন্ট ও assume করা হয় যেগুলো আপনি আসলে একমত নন। টুইটার আউট্রেজ এবং ১৪০ ক্যারেক্টার লিমিটের সাথে মিললে confusion, strawmen, এবং flamewar হয়।
তাই আলাদা আলাদা কয়েকটা পয়েন্ট আলোচনা করব।
TDD ওভারলি কমপ্লেক্স অবজেক্ট ও ইন্ডিরেকশনের জাল তৈরি করে
সাম্প্রতিক সময়ে রুবি টেস্টিং কমিউনিটিতে "কমপ্লেক্স অবজেক্ট ও ইন্ডিরেকশনের জাল"-এর প্রতি পছন্দ দেখছি। আমি মনে করি এটা খারাপ। (জাভা থেকে পলায়নের কারণগুলোর একটা এটা!) তবে আমি একমত নই যে TDD এটা করাতে।
প্রায় দশক ধরে TDD করছি, এবং আমি টেস্টগুলো ডেটাবেস থেকে আইসোলেট করি না। কন্ট্রোলার-লেভেল ফাংশনাল টেস্ট এবং রোবাস্ট ইন্টিগ্রেশন টেস্ট সিউটও আমার টোটাল টেস্ট সিউটের ভ্যালুয়েবল পার্ট, যেন স্লো হোক।
টেস্টগুলো সিস্টেম থেকে আইসোলেট করাই অপ্টিমাইজেশন। এবং YAGNI বলে সেটা এত গুরুত্বপূর্ণ নয় এখনো। বরং, আমি SSD এবং অ্যাপ প্রিলোডিং থেকে ওভারঅল স্পিড বাস্ট পেতে চাই, ইনডিভিডুয়াল টেস্ট অপ্টিমাইজ করার চেয়ে।
তবুও, TDD সিস্টেম ডিজাইনকে প্রভাবিত করে।
TDD আপনার কোডকে অর্গানিক্যালি grow করে। এটা চমৎকার হতে পারে! কিন্তু কখনো কখনো, একজন স্কিলড সফটওয়্যার ডেভেলপার TDD চেয়ে ভালো লুকিং কোড লিখতে পারে। সেটা অন্য কোডের সাথে বেশি টাইটলি কাপলড হতে পারে, সকল OOD রুল ফলো করতে পারে না, কিন্তু সেটা ক্লিয়ার, স্ট্রেটফরওয়ার্ড, এবং সিম্পল। (DHH Ping Pong-এ কিছু ভালো উদাহরণ আছে)।
TDD আপনাকে অবজেক্ট API ডিজাইন লক করে দিতে পারে রিয়েলি জানার আগে যে কী বানাচ্ছেন। পরে API চেঞ্জ করা কঠিন হয়। এই ঘর্ষণ আপনাকে ওয়ার্স ডিজাইন একসেপ্ট করতে বাধ্য করতে পারে।
টেস্ট-ফাস্ট আর ডিজাইন প্র্যাকটিস নয় যা ব্যবহার করা উচিত
TDD ফ্লেক্সিবল, ভালো টেস্টেড অবজেক্ট মডেল বানানোর চমৎকার টুল। তাই এই পয়েন্টের সাথে আমি সম্পূর্ণ অনমত। আমি আগের আর্টিকেলে TDD-এর অনেক সুবিধা বলেছিলাম:
- আপনি একটি বেশি ফ্লেক্সিবল, টেস্টেড অবজেক্ট মডেল পাবেন।
- আপনার সিস্টেম ডেফিনিশন অনুযায়ী টেস্টেবল, তাই ভবিষ্যতের টেস্ট কম খরচে লিখা যাবে।
- টেস্টিং খরচ ডেভেলপমেন্ট প্রসেসে বন্টে যায়, তাই এস্টিমেট বেশি সঠিক হয়।
- ফ্লোতে থাকতে সাহায্য করে, কারণ কখনো ডিসাইড করতে হয় না নেক্সট কী করব।
এই সুবিধাগুলোর বাইরে, এটা আপনাকে টেস্টিং প্র্যাকটিস করাও। কারণ আপনি সবসময় টেস্ট আগে লিখেন, আপনি ফ্যাক্টকে অনেক বেশি টেস্ট করবেন বদলে পরে টেস্ট করার চেষ্টা করলে। আপনি সাথে সাথে জানবেন টেস্টগুলো সঠিক কিনা (কারণ প্রথমে ফেলবে)। প্লাস, "এই একবার টেস্ট স্কিপ করি" এমন এক্সকিউজ থাকবে না।
ক্রোধিত টেস্ট-ফাস্ট রেটরিক দুঃখ ও নিরাশা আনয়
শতশত শতাংশ একমত। হ্যাঁ, আবার পোস্ট করছি। কিন্তু কেউ TDD না করলে কারণ সে সুবিধা জানে না, অথবা এখনো শিখতে পারিনি, অথবা অকামফরটেবল ফিল করে, সঠিক এপ্রোচ হচ্ছে তাকে লজ্জিত করা নয়, সাহায্য করা। TDD আপনার কাছে উপকারী হলে, কীভাবে হেল্প করে সেটা দেখান। ইন্টারেস্টেড হলে শুরু করতে হেল্প করুন।
যদি TDD ছাড়া কোড লিখতে পছন্দ করে, তাহলে দিন।
এক্সপার্টিজ বিল্ড হলে, আপনার নিজস্ব ইন্টুইশন, নিজস্ব টেস্ট, নিজস্ব প্রিফার্ড টেকনিক ডেভেলপ হবে। এই ইন্টারনেট আর্গুমেন্ট কোনো এক্সপার্টকে সেই জিনিসগুলো ইগনোর করতে শিখাবে না।
তাই, কেউ আপনার বেস্ট প্র্যাকটিস ফলো না করলে তার আক্ষেপ করলে, আপনি হয় তাদের শিখার ক্ষমতা আহত করছেন অথবা শূন্যে চিৎকার করছেন। যা 베স্ট কেসে টাইম 웨이স্ট, ওয়ার্স্ট কেসে আপনার कॉজ আহত করছে।
তাহলে আপনি কি TDD চালিয়ে যাবেন?
হ্যাঁ! আমি নিঃসন্দেহে সাজেস্ট করছি আপনি শিখুন এবং প্র্যাকটিস করুন।
টেস্টিং শেখানোর 크레ডিট TDD-র, এবং আমি এখনও TDD করলে বিশাল সুবিধা পাই। এটা পাঃফেক্ট নয়, কিন্তু কোনো এক টেকনিক ম্যাজিক্যালি ভালো কোড প্রডিউস করে না।
বরং, আপনাকে নতুন প্যাটার্ন, টেকনিক, টুল শিখতে থাকতে হবে। প্র্যাকটিস করুন যতক্ষণ না সঠিক প্যাটার্ন সঠিক জায়গায় ব্যবহার করা ফিল হয় সঠিক।
শিখার সময়, কোড মডিফাই, রিফ্যাক্টর, এক্সপেরিমেন্ট করার সময় দিন। পুরনো কোড ও নতুন কোড দেখুন। আপনাদের চেয়ে এক্সপেরিয়েন্সড কেউ রিভিউ করুন। ভালো হয়েছে? এইভাবে আপনি grow করবেন।
