স্বয়ংক্রিয় পরীক্ষা লেখা (Writing Automated Tests)

১৯৭২ সালে "দ্য হাম্বল প্রোগ্রামার" প্রবন্ধে এডসগার ডাইকস্ট্রা (Edsger W. Dijkstra) বলেছিলেন যে "প্রোগ্রাম টেস্টিং বাগগুলোর উপস্থিতি দেখানোর জন্য খুব কার্যকর উপায় হতে পারে, কিন্তু তাদের অনুপস্থিতি দেখানোর জন্য এটি আশাহীনভাবে অপর্যাপ্ত।" তার মানে এই নয় যে আমরা যতটা সম্ভব পরীক্ষা করার চেষ্টা করব না!

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

ধরা যাক, আমরা একটি add_two ফাংশন লিখি যা যেকোনো সংখ্যার সাথে ২ যোগ করে। এই ফাংশনের সিগনেচার একটি পূর্ণসংখ্যাকে প্যারামিটার হিসাবে গ্রহণ করে এবং একটি পূর্ণসংখ্যাকে ফলাফল হিসাবে রিটার্ন করে। যখন আমরা সেই ফাংশনটি ইমপ্লিমেন্ট এবং কম্পাইল করি, তখন Rust সমস্ত টাইপ চেকিং এবং বোরো চেকিং করে যা আপনি এতক্ষণ শিখেছেন, এটি নিশ্চিত করার জন্য যে, উদাহরণস্বরূপ, আমরা এই ফাংশনে একটি String মান বা একটি অবৈধ রেফারেন্স পাস করছি না। কিন্তু Rust পরীক্ষা করতে পারে না যে এই ফাংশনটি ঠিক সেটাই করবে যা আমরা চাই, অর্থাৎ, প্যারামিটারের সাথে ১০ বা প্যারামিটার বিয়োগ ৫০ যোগ না করে, প্যারামিটারের সাথে ২ যোগ করে রিটার্ন করবে! এখানেই পরীক্ষার প্রয়োজন হয়।

আমরা এমন পরীক্ষা লিখতে পারি যা দাবি করে, উদাহরণস্বরূপ, যখন আমরা add_two ফাংশনে 3 পাস করি, তখন রিটার্ন করা মান 5 হয়। আমরা যখনই আমাদের কোডে পরিবর্তন করি তখনই এই পরীক্ষাগুলো চালাতে পারি যাতে বিদ্যমান সঠিক আচরণ পরিবর্তন না হয় তা নিশ্চিত করা যায়।

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