چند نکته در طراحی اصولی test case در Unit Test

• هر قطعه کد تست باید کوتاه، قابل فهم و خوانا باشه.
• کدهای تست باید قطعه قطعه و به واحدهای مستقل از هم تقسیم بشن.
• کدهای تست باید مستقل از محیط اجرایی باشن و وابستگی به platform نداشته باشن.
• بهتره شیوه اجرای کدهای تست بسادگی و توسط یک دستور انجام بشه.
• امکان گزارش گیری Test code coverage باید فراهم باشه.
• اجرای تست case ها از پایین ترین سطح(Unit) به بالاترین سطح(E2E) باید باشه.
• تست case هارو توسط الگوی AAA بنویسید.
• در کدهای تست باید از نقل/انتقال اطلاعات حجیم خودداری کرد تا پروسه تست بسرعت انجام بشه.
• کدهای تست باید بروز باشن و با هر تغییر جدی روی کدهای اصلی باید تغییر کنند.
• حجم کل کدهای تست تولید شده معمولاً باید برابر یا بیشتر از حجم کدهای اصلی باشه. (یعنی برای همه موارد تست نوشته شده باشه)
• کدهای تست باید در همان روزی که کدهای اصلی پروژه نوشته میشن تولید بشن. (به روزهای آینده موکول نشه)
• تست case ها باید کدها، متدها و امکانات پروژه رو به سخت ترین شکل به چالش بکشن.
• از test double ها استفاده مجدد کنید.
• تا حد امکان از تست کردن محتوای private کلاس ها و Private API ها پرهیز کنید. (بواسطه کدهای public تست blackbox انجام بدید یا CUT رو redesign کنید)
• هنگام نوشتن تست case تا حد امکان از بکار بردن دستورات شرطی if/else/switch... پرهیز کنید.
• بهتره کدهای تست به خارج از محدوده پروژه dependency نداشته باشن.
• بهتره نام فایل تست به کلمه Test ختم بشه. مثل EmailTest, UtilityTest, DatabaseTest
• بهتره نام توابع/متدهای داخل فایل تست با کلمه test شروع بشن. مثل test_if_email_is_valid یا testIsEmailValid
• همیشه تست هارو هم برای سناریوی happy path و هم unhappy path بنویسید. (تست happy path تضمین می کنه که سیستم در شرایط عادی به درستی کار می کنه، اما unhappy path به کشف و رسیدگی به مسائل مربوط به مدیریت خطا، امنیت و انعطاف پذیری در مواجهه با سناریوهای غیرمنتظره کمک می کنه.)

 

نکته: وظیفه نوشتن کدهای تست برای Unit Testing بعهده فرد برنامه نویس هستش نه فرد Tester. زیرا:

- بدلیل حفظ مالکیت کدها/پروژه، Tester نباید به سورس پروژه دسترسی داشته باشه.

- بدلیل مسایل امنیتی و کاهش تهدیدها، Tester نباید به داخل کدها و مکانیزم سیستم دسترسی داشته باشه.

- همچنین Tester قادر نیست به همه ابزارها، سبکها و زبانهای مختلفی که در پروژه استفاده شده مسلط بشه و test case طراحی کنه.

- تنها برنامه نویس هستش به کدهایی که پیاده سازی کرده مسلطه و test case رو در کمترین زمان با بالاترین کیفیت تولید میکنه.

انواع اصلی تست محصول نرم افزاری

 

Functionality test, Performance/Speed test, User experience test, Compatibility test, Security test

 

نکته: هر 5 نوع تست بالا رو میشه با 2 روش manual و automatic و در 5 سطح/لایه مختلف انجام داد:

Unit Test, Integration Test, Feature/Module Test. System Test, [User] Acceptance/E2E Test

#6 - نکات و اصول مهم در برنامه نویسی Java/Android

1- بهتره همیشه شماتیک :file رو در کلاس WebView رو مسدود کنید.

کلاس WebView قابلیت نمایش صفحات وب در داخل اکتیویتی رو فراهم میکنه، و از اونجایی که دیگر برنامه ها قادرن Intent URI به WebView ایجاد شده بفرستن، پس این امکان رو هم دارن تا بتونن فایل یا آدرس URI آلوده رو در دستگاه بارگذاری کنن...

راه حل:

String _intentUrl = getIntent().getStringExtra("http://blog.ir");

if (!_intentUrl.startsWith("file:"))
{
   loadUrl = _intentUrl;
}

 

2- از انجایی که همه برنامه ها قادرن محتوای logcat رو read کنن، هرگز اطلاعات حساس رو برای دیباگ Log نکنید، مخصوصاً درخواستها و پاسخهای HTTP رو.

 

3- اگر در حین بازکردن برنامه Eclipse با خطای Java was started but returned exit code 13 مواجه شدید، این یعنی مثلاً Java 64bit نصب کردید، درصورتی که Eclipse تون 32bit هستش. یا Java 32bit نصب کردید، درصورتی که Eclipse تون 64bit هستش.

بنابراین باید معماری هردو یکی باشه... مثلاًً هردو 32bit یا هردو 64bit باشن.

نکته: در صورت حل نشدن مشکل با نصب معماری مناسب، فایل eclipse.ini رو که در کنار فایل اجرایی Eclipse تون هست رو باز کنید و بدنبال واژه –vm بگردید... بعد در زیر این واژه مسیر نصب شده Java رو جایگزینش کنید...

و یا برنامه Eclipse رو باز کنید و به مسیر Menu -> Prefecences -> Java -> Installed JREs برید و مسیرنصب شده Java رو بهش بدید...