چند نکته در طراحی اصولی 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 رو در کمترین زمان با بالاترین کیفیت تولید میکنه.

نکاتی راجب نمایش صحیح حروف فارسی

بدون استفاده از عبارت SET NAMES utf8 در دیتابیس:
 اگر انکودینگ فایل موردنظر UTF8 باشه، تگ meta صفحه UTF8 باشه، charset دیتابیس هم utf8_persian_ci باشه خروجیش صحیحه و میشه این:
آ ب پ ت ث ج چ ح خ د ض ر ز ش

اگر انکودینگ فایل موردنظر UTF8 باشه، تگ meta صفحه UTF8 "نباشه"، charset دیتابیس utf8_persian_ci باشه/نباشه خروجیش میشه این:
آ ب پ ت ث ج چ ح خ د ض ر ز ش

اگر انکودینگ فایل موردنظر UTF8 "نباشه"، تگ meta صفحه UTF8 باشه، charset دیتابیس utf8_persian_ci باشه/نباشه خروجیش میشه این:
� � � � � � � � � � � � � � 

اگر انکودینگ فایل موردنظر UTF8 "نباشه"، تگ meta صفحه UTF8 "نباشه"، charset دیتابیس utf8_persian_ci باشه/نباشه خروجیش میشه این:
Â È Ê Ë Ì Í Î Ï Ö Ñ Ò Ô

 اگر انکودینگ فایل موردنظر UTF8 باشه، تگ meta صفحه UTF8 باشه، اما charset دیتابیس utf8_persian_ci "نباشه" خروجیش صحیحه و میشه این:
آ ب پ ت ث ج چ ح خ د ض ر ز ش

می بینید که حتی بدون استفاده از عبارت SET NAMES utf8 باز هم میشه "خروجی" صحیح رو گرفت.

با استفاده از عبارت SET NAMES utf8 در دیتابیس:
 اگر SET NAMES UTF8 باشه، انکودینگ فایل موردنظر UTF8 باشه، تگ meta صفحه UTF8 باشه، charset دیتابیس utf8_persian_ci باشه خروجیش صحیحه و میشه این:
آ ب پ ت ث ج چ ح خ د ض ر ز ش

اگر SET NAMES UTF8 باشه، انکودینگ فایل موردنظر UTF8 باشه، تگ meta صفحه UTF8 "نباشه"، charset دیتابیس utf8_persian_ci باشه خروجیش میشه این:
آ ب پ ت ث ج چ ح خ د ض ر ز ش

اگر SET NAMES UTF8 باشه، charset دیتابیس utf8_persian_ci "نباشه"، و همه چیز دیگر UTF8 باشن خروجیش میشه این:
? ? ? ? ? ? ? ? ? ? ? ? ? ?

اگر SET NAMES UTF8 باشه، انکودینگ فایل موردنظر UTF8 "نباشه"، تگ meta صفحه UTF8 باشه، charset دیتابیس utf8_persian_ci باشه خروجیش میشه این:
" "

 اما برای نمایش درست کلمات در خود دیتابیس لازمه که از set_charset و SET NAMES UTF8 استفاده کنید.

چند تفاوت Thread و Process

مسئله Thread و Process دو موضوع نزدیک به هم ولی متفاوت هستن...

 

1- Process مستقل هستش، ولی Thread ها بخشی از یک Process هستن. (یعنی یک Process میتونه چندین Thread بوجود بیاره)
2- هر Process حافظه اختصاصی خودش رو داره، ولی Thread ها از حافظه اشغال شده Process استفاده می کنن. (یعنی هر Process حافظه خودش رو با Thread های خودش به اشتراک میذاره)
3- هر Process شامل یک برنامه و PID انحصاری هستش، ولی هر Thread شامل مجموعه ای از دستورالعمل ها و Stack انحصاری هستش.
4- هر Process درواقع یک Task هستش، ولی هر Thread یک Light wight process هستش.
5- Process ها توسط IPC (یا همون Inter-process communication) با یکدیگر ارتباط برقرار می کنن، ولی Thread ها توسط دستورات برنامه نویسی (در زبان PHP و Java توسط wait, notify و در زبان C توسط pthread_cond_wait, pthread_cond_signal) با یکدیگر ارتباط برقرار می کنن.
6- ساخت Process به سختی توسط duplicate کردن Process والد انجام میشه، ولی ساخت Thread براحتی توسط کپی شی Thread انجام میشه.
7- برای اجرای چند Process بطور موازی/parallel به یک سیستم Multi-Process نیاز هست، ولی برای اجرای چند Thread بطور همزمان به دستورات برنامه نویسی نیاز هست.
8- بطور کلی Process توسط CPU کنترل میشه، ولی Thread توسط Process کنترل میشه.
9- هر Process یک Thread main داره، ولی هر Thread فقط خودشه که کارگر/worker صدا زده میشه.
10- Process در فضای separate memory اجرا میشه، ولی Thread در فضای Shared memory اجرا میشه.
و...

#2 - نکاتی برای افزایش امنیت وبسایت

مقالات مرتبط:

نکاتی برای افزایش امنیت وبسایت

 

1- حتاالمکان از کتابخانه های template engine برای کدنویسی لایه View/UI وب اپلیکیشن استفاده کنید و نه کدنویسی inline/mixed.

 

2- برای کاهش مصرف پهنای باند و افزایش سرعت سایت، همیشه فایلهای CSS, JavaScript, HTML رو minify و lint کنید:

CSS:

https://github.com/purifycss/purifycss

https://cssnano.co/guides/getting-started

https://github.com/ben-eb/cssnano-cli

https://github.com/css/csso-cli

https://github.com/uncss/uncss

JS:

https://github.com/nolanlawson/optimize-js

 

3- بطور منظم و ماهیانه پهنای باند وبسایت/سرور رو چک کنید.

 

4- یک سیستم اسکنر پیاده کنید که نوع دسترسی و زمان تغییر فایلها و دایرکتوری های کل سایت رو اسکن و به شما گزارش کنه.

 

5- از استفاده بیش از حد کوکی و ذخیره اطلاعات حساس/نمایشی  در داخلشون خودداری کنید.

#2 - نکات و اصول مهم در طراحی وبسایت

مقالات مرتبط:

نکات و اصول مهم در طراحی وبسایت

نکاتی برای افزایش امنیت وبسایت

#2 - نکاتی برای افزایش امنیت وبسایت

 

 

1- از صفت alt در تگهای img و از صفت title در تگهای link استفاده کنید. صفت alt بیانگر خلاصه ای از محتوای تصویر موردنظر هستش.

2- فراموش نکنید که محل جاری آدرسهای Font در فایلهای CSS از همان مسیر Relative فایل CSS شروع می شوند.

3- Link های صفحات را چک کنید و از سالم بودنشان مطمئن بشید.

4- شکل ظاهری صفحات داخلی و جداگانه را با شکل ظاهری صفحات اصلی یکنواخت کنید.

5- به عملا و دیکطه لقاط دغط کینید!

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

 

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

چک لیست سرویس و رسیدگی به سیستم PC

- برآورد مشکلات سیستم

- بررسی کلی سخت افزار

- بررسی کلی نرم افزار

 

سخت افزار

- پاکسازی داخل سیستم و مادربورد

- سرویس CPU و فن CPU

- سرویس Power supply و فن Power supply

- پاکسازی موس، کیبورد و مانیتور

- تهیه باطری جدید برای CMOS/BIOS

- پاکسازی سوکت ها و پورت های سیستم

[- قطع و غیرفعال کردن مودم Dialup]

[- قطع و غیرفعال کردن درایو Floppy]

- تعویض کابلهای کهنه/آسیب دیده

- ریست و تنظیم مجدد مانیتور

- بررسی کابلهای داخل و بیرون سیستم

 

نرم افزار

- بک آپ گیری از اطلاعات!

- آپدیت Firmware مادربورد(BIOS EEPROM)

- ریست و تنظیم مجدد BIOS/CMOS

- فرمت(wipe) دوره ای عمقی پارتیشن ها یا کل دیسک

- نصب مجدد سیستم عامل

- تنظیم سیستم عامل

[- ریستارت سیستم عامل بعد از انجام تنظیمات]

- تنظیم تاریخ و ساعت سیستم

- نصب نرم افزارهای کتابخانه ای/Runtime

- دانلود [و رایت] و نصب Driver ها

- حذف نرم افزارهای بلااستفاده و مزاحم

- پاکسازی فایلها و پوشه های اضافی و temp

[- بهینه سازی و تنظیم رجیستری]

- نصب و بروزرسانی نرم افزارهای کاربردی

- نصب ضدبدافزار سبک و قدرتمند

- بروزرسانی ضدبدافزار

- اسکن کل پارتیشن ها توسط ضدبدافزار

- بهینه سازی تنظیم سرویس ها

- Defrag/Optimize پارتیشن ها(بجز SSD ها)

- پاکسازی و تنظیم startup سیستم عامل

- پاکسازی system restore point ها

 

شبکه

- پاکسازی کش DNS و ریست Socket سیستم

- آپدیت Firmware مودم ADSL/DSL

- تنظیم subnet mask مودم به 255.255.255.128 یا بالاتر

- تنظیم Subnet prefix مودم به 25

- تنظیم DNS مودم به 208.67.222.222 و 8.8.8.8

- تنظیم Security protocol مودم به WPA2 یا WPA3

- خاموش کردن قابلیت WPS مودم

- پنهان کردن SSID مودم

 

MVC in a nutshell

 

دقیقتر:

 

 

دقیقتر:

 

mvc چیست، ام وی سی چیست، ساختار mvc

منبع: https://blog.glyphobet.net/essay/153/

ساختار فایل APK مقابل فایل JAR

 

چک لیست طراحی اصولی API در Java

1. Package Design Checklist

1.1. General

• 1.1.1. Favor placing API and implementation into separate packages [explain]
• 1.1.2. Favor placing APIs into high-level packages and implementation into lower-level packages [explain]
• 1.1.3. Consider breaking up large APIs into several packages [explain]
• 1.1.4. Consider putting API and implementation packages into separate Java archives [explain]
• 1.1.5. Avoid (minimize) internal dependencies on implementation classes in APIs [explain]
• 1.1.6. Avoid unnecessary API fragmentation [explain]
• 1.1.7. Do not place public implementation classes in the API package [explain]
• 1.1.8. Do not create dependencies between callers and implementation classes [explain]
• 1.1.9. Do not place unrelated APIs into the same package [explain]
• 1.1.10. Do not place API and SPI into the same package [explain]
• 1.1.11. Do not move or rename the package of an already released public API [explain]

1.2. Naming

• 1.2.1. Start package names with the company’s official root namespace [explain]
• 1.2.2. Use a stable product or product family name at the second level of the package name [explain]
• 1.2.3. Use the name of the API as the final part of the package name [explain]
• 1.2.4. Consider marking implementation-only packages by including “internal” in the package name [explain]
• 1.2.5. Avoid composite names [explain]
• 1.2.6. Avoid using the same name for both package and class inside the package [explain]
• 1.2.7. Avoid using “api” in package names [explain]
• 1.2.8. Do not use marketing, project, organizational unit or geographic location names [explain]
• 1.2.9. Do not use uppercase characters in package names [explain]