تست‌نویسی در مسیر Pharo

بیاموزید چطور تمرین‌های Pharo خود را در Exercism تست کنید


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

بازخورد فوری

Pharo پشتیبانی خوبی از کار با Testها و Test کردن تدریجی دارد! می‌توانید با کلیک روی orb کنار یک کلاس یا متد test case، هر Testی را برای یک تمرین اجرا کنید.

orbهای Test در مرورگر

رنگ orbها بر اساس نتیجه‌ی آخرین اجرای Test تعیین می‌شود:

  • سبز یعنی Test قبول شده است
  • زرد یعنی یک assertion شکست خورده است
  • قرمز یعنی خطای زمان اجرا یا استثنا رخ داده است

Testهای مرتب

Testهای تمرین‌های Exercism عمداً شماره‌گذاری شده‌اند تا ترتیب اجرای مشخصی داشته باشند (مثلاً test01_verifySomeProperty، test02_verifyAnotherProperty و غیره).

وقتی روی یک تمرین کار می‌کنید، توصیه می‌شود روی orb اولین Test کلیک کنید، علت شکست و آنچه برای قبول شدنش لازم است را بفهمید، و بعد Code لازم را به راه‌حل خود اضافه کنید تا کار کند. در Pharo کاملاً عادی است که این تغییرات را در debugger انجام دهید، جایی که هم به ویرایشگر Code دسترسی دارید و هم نمای همه‌ی متغیرها و پارامترهایی را می‌بینید که می‌توانند در فهم مسئله کمکتان کنند.

توجه: برچسب زدن Testها با یک پیشوند ترتیبی رویه‌ی رایجی نیست، و وقتی برای پروژه‌ی خودتان Test می‌نویسید نباید این کار را بکنید.

حتی وقتی خراب است هم اجرا می‌شود

Pharo با خیال راحت با Codeی که خراب است اجرا می‌شود، و debugger به‌محض برخورد با یک خطا (خواه خطای نگارش، مقدار نامعتبر، یا حتی یک کلاس یا متد ناموجود) صرفاً دوباره باز می‌شود. این تکنیک یکی از تأثیرات اصلی بر توسعه‌ی مبتنی بر Test بود، و وقتی اجرای اولین Test هر تمرینی را امتحان کنید، می‌توانید طعم این رویکرد را بچشید. debugger بلافاصله نشان می‌دهد که کلاس راه‌حل شما پیدا نشده است (چون هنوز هیچ‌چیز ننوشته‌اید). خوشبختانه، دکمه‌ی «Create» هست که به شما کمک می‌کند کلاس ناموجود را اضافه کنید و اجرا را ادامه دهید تا اینکه یا تمام شود یا به خطای دیگری بربخورید.

ساختن یک کلاس در debugger

در Test اول، بعد با خطای دومی روبه‌رو می‌شوید، چون هنوز هیچ متدی ننوشته‌اید. باز هم، دکمه‌ی «Create» در debugger به شما اجازه می‌دهد یکی را تعریف کنید و اجرا را ادامه دهید. در این مرحله می‌توانید در stack trace پایین‌تر هم کلیک کنید، شرایط Test شکست‌خورده را بررسی کنید و متد جدیدتان را تغییر دهید تا قبول شود.

عاشق debugger شوید

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

علاوه بر دیدن متغیرها در debugger، می‌توانید هر دستوری را برجسته کنید و روی «inspect/print» کلیک کنید تا نتیجه‌ی ارزیابی آن را ببینید. این کار می‌تواند هنگام Test کردن نتیجه‌ی یک متد، یا برای بررسی وضعیت درونی یک شیء مفید باشد.

بررسی یک دستور

فراموش نکنید که می‌توانید Code در حال اجرا را هم در debugger تغییر دهید، و ذخیره‌ی یک تغییر به‌سادگی باعث می‌شود اجرا در همان متدی که تازه ذخیره شده از نو شروع شود. این به شما اجازه می‌دهد تا وقتی هنوز «در لحظه» هستید، تغییرات را آزمایش کنید و نتیجه‌شان را ببینید.

در مجموع، از استفاده از debugger در Pharo نترسید؛ ما آن را ابزاری ارزشمند می‌دانیم که به فهمیدن و آزمایش‌کردن یک مسئله کمک می‌کند.

گروه‌های بزرگ‌تر Test و خودکارسازی

اگر روزی لازم شد گروه‌های بزرگ‌تری از Testها را اجرا کنید، می‌توانید آن‌ها را از منوی «Package» هم اجرا کنید، و نیز از ابزار Test Runner استفاده کنید (که از منوی «World» باز می‌شود، یا با تایپ <meta> + OU).

همچنین می‌توانید Testها را به‌صورت برنامه‌ای از playground اجرا کنید، با print evaluating:

AllExercismTests suite run.

اگر می‌خواهید درباره‌ی درونیات Testها بیشتر بدانید، می‌توانید درباره‌ی SUnit بخوانید یا Code را در سلسله‌مراتب TestCase مرور کنید.

آیا می‌دانستید: TDD در Smalltalk، با معرفی کتابخانه‌ی SUnit برای Test، اختراع شد