کتاب Test-Driven Development with Python

این کتاب، تلاش من برای به اشتراک گذاشتن سفری است که از «هک کردن» تا «مهندسی نرم‌افزار» طی کردم. موضوع اصلی آن آزمایش (تست) است، اما همانطور که به زودی خواهید دید، موارد بسیار بیشتری در آن وجود دارد.

از اینکه کتاب Test-Driven Development with Python را می‌خوانید از شما تشکر می‌کنم.

اگر نسخه‌ای را خریداری کرده‌اید، بسیار سپاسگزارم. اگر در حال مطالعه نسخه رایگان آنلاین هستید، باز هم از اینکه تصمیم گرفته‌اید وقت خود را برای آن صرف کنید، قدردانم. شاید، وقتی به پایان رسید، تصمیم بگیرید که به اندازه کافی خوب است که یک نسخه فیزیکی برای خود یا دوستتان بخرید.

امیدوارم همانقدر که من از نوشتن کتاب Test-Driven Development with Python لذت بردم، شما نیز از خواندن آن لذت ببرید.

چرا کتابی درباره توسعه مبتنی بر آزمون نوشتم

“شما کی هستید، چرا این کتاب را نوشته‌اید و چرا باید آن را بخوانم؟” می‌شنوم که می‌پرسید.

من در اوایل کارم به اندازه کافی خوش‌شانس بودم که با گروهی از متعصبان توسعه مبتنی بر آزمون (TDD) همراه شوم، و این موضوع چنان تأثیر بزرگی بر برنامه‌نویسی من گذاشت که مشتاق بودم آن را با همه به اشتراک بگذارم. ممکن است بگویید اشتیاق یک تازه‌وارد را داشتم، و تجربه یادگیری برایم هنوز یک خاطره اخیر بود، و این همان چیزی است که به اولین نسخه، در سال ۲۰۱۴، منجر شد.

هنگامی که برای اولین بار پایتون را یاد گرفتم (از کتاب عالی Dive Into Python از مارک پیلگریم)، با مفهوم TDD برخورد کردم و با خود اندیشیدم، “بله. قطعاً منطق آن را می‌بینم“. شاید شما هم وقتی برای اولین بار درباره TDD شنیدید، واکنش مشابهی داشتید؟ این رویکرد بسیار منطقی به نظر می‌رسید، یک عادت بسیار خوب برای شروع—​مانند مسواک زدن منظم دندان‌ها.

سپس اولین پروژه بزرگ من از راه رسید و می‌توانید حدس بزنید چه اتفاقی افتاد—​یک مشتری وجود داشت، مهلت‌هایی تعیین شده بود، کارهای زیادی برای انجام بود، و تمام نیت‌های خوب درباره TDD مستقیماً از پنجره بیرون رفت.

و در واقع، همه چیز خوب بود. من خوب بودم.

در ابتدا.

در ابتدا فکر می‌کردم واقعاً به TDD نیازی ندارم چون وب‌سایت کوچک بود، و به راحتی می‌توانستم با بررسی دستی، کارکرد صحیح چیزها را آزمایش کنم. روی این لینک اینجا کلیک کن، آن گزینه کشویی را انتخاب کن، و این اتفاق باید بیفتد. آسان. این قضیه “نوشتن آزمون‌ها” به نظر می‌رسید که زمان زیادی می‌برد. علاوه بر این، با اتکا به سه هفته تجربه کدنویسی بزرگسالانه‌ام، خودم را یک برنامه‌نویس نسبتاً خوب می‌دانستم. می‌توانستم از پس آن برآیم. آسان.

سپس الهه ترسناک پیچیدگی از راه رسید. او خیلی زود محدودیت‌های تجربه من را نشان داد.

پروژه رشد کرد. بخش‌هایی از سیستم شروع به وابستگی به بخش‌های دیگر کردند. من تمام تلاشم را کردم که اصول خوبی مانند DRY (خودت را تکرار نکن) را دنبال کنم، اما این فقط به قلمروی نسبتاً خطرناکی منجر شد. به زودی، با وراثت چندگانه بازی می‌کردم. سلسله‌مراتب کلاس‌ها با عمق هشت سطح. دستورات eval.

از اعمال تغییرات در کدم می‌ترسیدم. دیگر مطمئن نبودم چه چیزی به چه چیزی وابسته است، و اگر این کد را اینجا تغییر دهم چه اتفاقی ممکن است بیفتد…​اوه خدایا، فکر کنم آن قسمت از آن ارث می‌برد…​نه، ارث نمی‌برد؛ نادیده گرفته شده است. اوه، اما به آن متغیر کلاس وابسته است.

بسیار خوب، تا زمانی که نادیده گرفتنِ نادیده گرفته شده را نادیده بگیرم، باید مشکلی نباشد. فقط بررسی می‌کنم—​اما بررسی کردن بسیار سخت‌تر می‌شد. اکنون بخش‌های زیادی برای سایت وجود داشت، و کلیک کردن دستی روی همه آنها شروع به غیرعملی شدن کرده بود. بهتر است دست به کار خوب نزنیم. Refactoring را فراموش کن. فقط بساز و سر کن.

به زودی، من یک درهم‌ریختگی زشت و زننده از کد داشتم. توسعه جدید دردناک شد.

خیلی زود پس از این، خوش‌شانس بودم که در شرکتی به نام Resolver Systems (اکنون PythonAnywhere) شغلی به دست آورم، جایی که برنامه‌نویسی مفرط (XP) یک هنجار بود. افراد آنجا من را با TDD دقیق آشنا کردند.

اگرچه تجربه قبلی‌ام قطعاً ذهن من را به مزایای احتمالی آزمایش خودکار باز کرده بود، اما باز هم در هر مرحله از آن طفره رفتم. “منظورم این است که، آزمایش به طور کلی ممکن است ایده خوبی باشد، اما واقعاً؟ این همه تست؟ برخی از آنها به نظر وقت تلف کردن کامل می‌آیند…​چی؟ تست‌های عملکردی علاوه بر تست‌های واحد؟ بس کنید، این زیاده‌روی است! و این چرخه TDD تست/تغییر-حداقلی-کد/تست؟ این فقط احمقانه است! ما به تمام این گام‌های کوچک نیاز نداریم! بیایید—ما می‌بینیم که پاسخ درست چیست؛ چرا مستقیماً به انتها نرویم؟”

باور کنید، من در مورد هر قانون شک کردم، هر میان‌بری را پیشنهاد دادم، برای هر جنبه به ظاهر بی‌معنی TDD توجیه خواستم—​و در نهایت حکمت همه اینها را درک کردم. تعداد دفعاتی که فکر کرده‌ام، “ممنون، تست‌ها،” را از دست داده‌ام، وقتی یک تست عملکردی یک رگرسیون را که هرگز پیش‌بینی نمی‌کردیم، کشف می‌کند، یا یک تست واحد من را از یک خطای منطقی واقعاً احمقانه نجات می‌دهد. از نظر روانشناختی، این کار توسعه را به یک فرآیند بسیار کم‌استرس‌تر تبدیل کرده است. کدی تولید می‌کند که کار کردن با آن لذت‌بخش است.

پس، بگذارید همه چیز را در مورد آن به شما بگویم!

اهداف کتاب Test-Driven Development with Python

هدف اصلی من انتقال یک روش‌شناسی است—​روشی برای انجام توسعه وب، که به نظر من برنامه‌های وب بهتر و توسعه‌دهندگان شادتری ایجاد می‌کند. کتابی که صرفاً مطالب قابل جستجو در گوگل را پوشش دهد، فایده چندانی ندارد، بنابراین کتاب Test-Driven Development with Python راهنمای دستور زبان پایتون، یا یک آموزش در مورد توسعه وب به خودی خود نیست.

در عوض، امیدوارم به شما بیاموزم که چگونه از TDD استفاده کنید تا با اطمینان بیشتری به هدف مقدس مشترک ما برسید: کد تمیز که کار می‌کند.

با این گفته: من دائماً به یک مثال عملی واقعی اشاره خواهم کرد، با ساخت یک برنامه وب از پایه با استفاده از ابزارهایی مانند جنگو (Django)، سلنیوم (Selenium)، جِی‌کوئری (jQuery) و ماک‌ها (mocks). من هیچ دانش قبلی از هیچ‌کدام از اینها را فرض نمی‌کنم، بنابراین شما باید با یک مقدمه مناسب در مورد این ابزارها و همچنین نظم TDD از این کتاب خارج شوید.

در برنامه‌نویسی مفرط، ما همیشه برنامه‌نویسی زوجی انجام می‌دهیم، بنابراین من تصور کرده‌ام که کتاب Test-Driven Development with Python را طوری می‌نویسم که انگار با خود قبلی‌ام جفت شده‌ام، و مجبورم توضیح دهم که ابزارها چگونه کار می‌کنند و به سؤالاتی در مورد اینکه چرا ما به این روش خاص کد می‌نویسیم، پاسخ دهم.

بنابراین، اگر زمانی لحنی کمی حمایت‌گرانه می‌گیرم، به این دلیل است که من آنقدرها هم باهوش نیستم، و باید با خودم بسیار صبور باشم. و اگر زمانی حالت دفاعی می‌گیرم، به این دلیل است که من از آن دسته افراد آزاردهنده‌ای هستم که به طور سیستماتیک با هر آنچه دیگران می‌گویند مخالفت می‌کنم، بنابراین گاهی اوقات متقاعد کردن خودم به توجیه زیادی نیاز دارد.

طرح کلی

من کتاب Test-Driven Development with Python را به چهار بخش تقسیم کرده‌ام.

• بخش اول (فصل‌های ۱ تا ۸): مبانی TDD و جنگوما مستقیماً با ساخت یک برنامه وب ساده با استفاده از TDD شروع می‌کنیم. با نوشتن یک تست عملکردی (با سلنیوم) آغاز می‌کنیم، و سپس از مبانی جنگو—​مدل‌ها، نماها، الگوها (templates)—​با آزمایش واحد دقیق در هر مرحله عبور می‌کنیم. من همچنین “بز آزمایشگر” (The Testing Goat) را معرفی می‌کنم.

• بخش دوم (فصل‌های ۹ تا ۱۲): رفتن به تولید (Production)این فصل‌های کتاب Test-Driven Development with Python همه در مورد استقرار برنامه وب شما در یک سرور واقعی است. ما بحث می‌کنیم که چگونه تست‌های ما و تمرین TDD در کار کردن افزایشی می‌تواند بسیاری از درد و خطر را از فرآیندی که معمولاً بسیار پرمخاطره است، بگیرد.

• بخش سوم (فصل‌های ۱۳ تا ۱۶): فرم‌ها و اعتبارسنجی (Validation)در اینجا، به برخی از جزئیات چارچوب فرم‌های جنگو می‌پردازیم، اعتبارسنجی و یکپارچگی داده‌ها را با استفاده از محدودیت‌های پایگاه داده پیاده‌سازی می‌کنیم. ما درباره استفاده از تست‌ها برای کشف APIهای ناآشنا و محدودیت‌های چارچوب‌ها بحث می‌کنیم.

• بخش چهارم (فصل‌های ۱۷ تا ۲۷): مباحث پیشرفته در آزمایشبرخی از موضوعات پیشرفته‌تر در TDD را پوشش می‌دهد، از جمله Spiking (که در آن به طور موقت قوانین TDD را رها می‌کنیم)، Mocking، کار کردن از بیرون به درون، و ادغام مداوم (CI).

سرفصل‌های کتاب Test-Driven Development with Python: