📌 یادگیری کتابخانه Playwright واقعاً ارزشمنده

چه برای خزش وب (Web Crawling) و چه برای تست سامانه‌ها، Playwright یکی از ابزارهای بسیار قدرتمنده

دست شما رو کاملاً باز می‌ذاره و تقریباً هر چیزی که برای کار حرفه‌ای نیاز دارید رو فراهم کرده.
یکی از قابلیت‌های جذابش حالت Headless هست:

* اگر headless=false باشه، کد دقیقاً روی دسکتاپ اجرا می‌شه و توسعه و دیباگ رو خیلی راحت می‌کنه
* اگر headless=true باشه، آماده‌ی اجرا روی سرور می‌شه (ایده‌آل برای استفاده داخل CI/CD)

🧠 مفهوم Context رو به‌خوبی پیاده‌سازی کرده
(تصور کنید یک پروفایل جدید در مرورگر باز می‌کنید که می‌تونه چندین تب همزمان داشته باشه)

📸 امکان Screenshot و حتی Record کردن ویدیو از صفحه رو می‌ده
چه در حالت headless و چه غیر headless
(خیلی کاربردی برای مستندسازی، داکیومنت فنی و آموزش کار با سامانه‌ها)

🔌 کار با API رو هم به‌صورت native در اختیارتون می‌ذاره
مدیریت کوکی، سشن و احراز هویت در طول اجرای تست‌ها رو خودش کاملاً هندل می‌کنه

📦 با انواع فرمت‌های داده سازگاره و خیلی راحت می‌تونید با داده‌های مختلف کار کنید

🔥 اما یه نکته‌ی خیلی جذاب در تست سامانه‌ها:

فرض کنید طبق سیاست‌نامه‌ی سازمان، یک صفحه باید حداکثر تا ۵ ثانیه اندپوینت‌هاش پاسخ بدن.
تستر می‌تونه به اون بخش از صفحه timeout پنج‌ثانیه‌ای بده و خروجی رو بررسی کنه
بدون درگیری مستقیم با لاگ‌ها یا کدهای پیچیده.

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

@code_crafters

خب بیایم یکم راجب تست نویسی بگیم

توسعه تست محور TDD کم و بیش همه باهاش آشنا هستیم، تو حالت کلاسیکش با تست‌ها رفتار سیستم رو مشخص میکردیم و بعد کد میزدیم، بابت همین تو کتاب معروفش اگه بریم بیشترین تمرکز روی نوشتن تست‌های e2e هستش (تستی که رفتار کاربر رو شبیه سازی میکرد) و تا حدودی روی integration test و اندک روی unit test، بابت همین خیلی‌ها رویکرد TDD (کلاسیک) رو با BDD یکی میدونن و اشتباه چون تمرکز هردو روی رفتار (behavior) هستش

اما TDD دستخوش تغییرات شدیدی شد چون ضعف داشت روی سیستم‌های بزرگ و یک بازبینی راجبش انجام دادیم

در واقع TDD امروزی‌تر تمرکزش بیشتر روی صحت کد هستش و رفتار بوسیله BDD چک و بررسی میشه، چرا اینجوری شد

در رویکرد کلاسیک توسعه دهنده میومد رفتار سیستم رو فرض میکرد و بر اساس اون پیش میرفت اما مشکل اینجا بود که توسعه دهنده جزو ذی‌نفع محسوب نمیشه، BDD اومد و نگاه کسب و کاری بهش انداخت و رفتار سیستم رو بر اساس ذی‌نفع مطرح کرد

چه اتفاقی افتاد اساسا رویکرد کلاسیک TDD اینجوری بود که
E2E -> unit test -> integration test

این یک فاجعه بود، عملا e2e یا شکست میخورد یا ناقص بود یا کند بود و ... بر اساس تجربه در پروژه‌های بزرگ و پیچیده اومدیم E2E رو گذاشتیم لایه آخر و گفتیم بجای توسعه دهنده، QA این رو بر عهده بگیره

معجزه شد واقعا، سرعت توسعه بالا رفت و زمان زیادی ذخیره شد برامون تفکیک مسئولیت صورت گرفت و با اسکرام و دواپس هم سازگارتر بود گویا، فلسفه قبلی پا برجا بود ولی منتها بازدهی بیشتر بود و بهتر

خب حالا چرا این رویکرد جدید
unit test -> integration test -> E2E

خوب بود و جوابگو
اپیک‌ها مشخص میشه
داستان کاربری در بک لاگ پروژه قرار میگیره
آیتم‌ها مشخص میشه

توسعه دهنده‌ها آیتم‌ها رو بر میداره و با مالک پروژه هماهنگ میشن کدوم‌ها در بک لاگ اسپرینت وارد بشه

توسعه دهنده ابتدا تست‌های واحد ویو رو مینویسه و ویو رو پاس میکنه، تست‌های لایه سرویس رو مینویسه و پاس میکنه، آیتم‌های واحد تموم شد

در رویکرد کلاسیک شما اول باید دیتابیس زو کامل بالا بیارید و همچنین تمام زیرساخت مورد نیازی که هنوز قطعی و مشخص نیست، اما تو حالت مدرن‌تر دیگه لازم نبود(چون e2e رفت انتهای لیست) توسعه دهنده با خیال راحت ماک می‌ساخت و پیش میرفت و وابستگی‌ها ذره ذره و به مرور مشخص و تعیین میشد، توسعه نمیخوابید یا کار اضافه انجام نمی‌داد

بعد اینکه واحدها تموم شد
توسعه دهنده میاد و ویو و سرویس رو به هم دیگه می‌چسبوند و براشون تست یکپارچه (integration) می‌نویسه، که بیشتر بابت نگهداری و چک کردن در تغییرات بعدی جهت اطمینان از درستی عملکرد بود، در انتها تستر میاد و با نگاه ذی‌نفعی e2e رو مینویسه و تمام

توسعه سریعتر
دیپلوی سریعتر
نقش‌ها مشخص
درگیری توسعه دهنده با ذی‌نفع کمتر و کمتر
دست توسعه دهنده هم بازتر

حالا شاید براتون سوال شده، مزیت دیگه این رویکرد مدرن برای توسعه چی هستش؟؟؟

بعنوان توسعه دهنده اول باید از ویو شروع کنم یا سرویس راه درست کدومه، خب اینجا یک تفکر جدید هم داریم DDD و به همون اندازه معماری درست توسعه دامنه محور

چندتا سوال از خودتون بپرسید

آیا منطق تجاری داخل سیستم مهمتر هستش و انتهای پروژه بازتره؟؟؟ پس برید از نوشتن تست سرویس و پاس کردن اون شروع کنین
آیا تراکنش در سیستم مهمتره و انتهای پروژه مشخص‌تر؟؟؟ پس برید از نوشتن تست ویو و پاس کردنش شروع کنید

در نهایت وظیفه توسعه دهنده نوشتن تست واحد و تجمیع و اطمینان از عملکرد منطقی کد هستش و تستر اطمینان از صحت سرویس و رفتار سرویس


#test
#tdd
#ddd
#bdd

@code_crafters

چرا pytest ارزش یادگیری داره؟؟؟

در مرحله اول شما با یک فریمورک تست روبرو هستید که همه فن حریف هستش برای هر چیزی و هر جایی، یکسری از موارد جذابش رو بهتون بگم تو دنیای واقعی

اول اینکه خیلی ساده هستش و با اکو سیستم پایتون بشدت دوست هستش شما با assert و مقادیر قابل چک (== != > < is in و ...) درگیرید

یافتن تست‌ها با test_*.py / *_tets.py بصورت درونی داره

امکان group test در یک کلاس رو بهتون میده

امکان subtest رو بهتون میده کافیه از :: استفاده کنید برای مسیر به تابع تستتون (test_view.py::test_login/.)


بریم یه نگاه تخصصی تر بهش بندازیم با ویژگی‌های بیشترش، من ترتیب بگم تا یک سناریوی واقعی بهتون هم بدم

یک فایل conftest.py میتونید بسازید که کانفیگ های مدنظر رو اعمال کنید خصوصیت این فایل این هستش در هر جای مسیر تست بزارید از اون مسیر و به دایرکتوری‌های داخلی اعمال میشه

بهتون fixture میده که امکان تعریف توی scope های مختلف رو میده (module, function, session, class) و جالبترین قسمت بصورت داینامیک بودنش هست، این تو دنیای واقعی کاربرد داره که fixture رو برای حالت ci/cd بزارید رو session که تست‌ها موجب کند شدن اوتومیشن نشند و تو حالت توسعه بزارید روی function تا همه چی رو دقیق مشاهده کنید، اگه یک fixture دارید که تو تست‌های مختلف در مسیرهای مختلف اجرا میشه میتونید بزارید داخل conftest.py بالا و بدون دردسر حملش کنید و فقط کافیه صداش بزنید بعنوان پارامتر ورودی تست‌های دیگتون

گزینه autouse بهتون میده واسه وابستگی‌هایی که همه جا باید اجرا بشه مثه چی؟؟؟ تنظیم timezone, پاک کردن کش برای هر تست، ماک کردن یک سرویس و ....

میتونید از آرگومان کامند لاین استفاده کنید، شما تو محیط توسعه لوکال مقادیر environment هاتون رو داخل فایل .env میزارید و روی سروی و داخل stage های pipeline نزریق میشن، این قسمت بهتون کمک میکنه که با ارسال args در خط فرمان به conftest.py بگید که مقادیر environment رو از کجا بگیره، کافیه شما دو مقدار
--load-test
--load-dev
تعریف کنید و جالبتر اینکه با ترکیب این args و scope در پاراگراف بالاتر، یک معجزه در conftest.py واسه fixture بنویسید و خودتون رو درگیر جداسازی تست‌ها و scope برای محیط تست و اوتومیشن نکنید


بهتون امکان مارک‌گذاری رو‌میده یک سیستم شبیه به برچسب دهی یا تگ گذاری کردن برای تست‌هاتون (skipif , skip, fail , timeout , ...) یک قسمت محبوب برای توسعه دهنده‌ها parametrize هستش، در یک سناریوی ویو شما status های مختلف دارید 200, 400, 500 دارید لازم نیست چندتا تست بنویسید یا assert های مختلف برای هر بخش با این ویژگی می‌تونید یکبار یک تست جامع برای ویوتون بنویسید تو هر بخش اضافه شدن جدید بهش فقط parameterize رو بروز می‌کنید (یک مثال کاربردی تر ویویی که params میگیره) یا ویویی که با permission‌های مختلف کار میکنه هستش

و جالبترین قسمتش آرگومان‌های داخلی خودش برای cli هستش که میتونید یک حالت مانیتور مانند کامل برای تست‌هاتون داشته باشید

-v
-s
--tb
-ra
--lf
-m (unit/e2e/smoke/integration)
-k
--fixtures
--maxfail
--duration
--markers
-W ignore

#test

@code_crafters

چرا pytest ابزاری مهندسی شده هستش؟؟؟

یکی از موارد جذاب در این فریمورک در بخش markerها نهفته شده
یک نوع تست وجود داره که بهش میگیم smoke، کاربردش چیه فقط بررسی میکنه سیستم زنده هستش یا نه، تو حوزه تستر مورد استفاده زیادی هستش، شما کافیه روی یکسری تست‌ها که هدفشون بررسی حیات سیستم هستش این برچسب رو بزارین، چه اتفاقی میافته؟؟؟ درون ci قبل از اینکه همه تست‌هارو اجرا کنید اول smoke رو ران میکنید و اگه پاس شدن بعد سراغ مابقی روند میرید این باعث میشه ci سریعتر رخ بده
pytest -m smoke

ما تست‌های مختلفی داریم
تست unit که فقط منطق یک متد رو بررسی میکنه سمت side-efect و هر چیزی بیرون از منطق متد نمیره و نمیبرین این تست‌ها و کافیه با مارک. unit مشخص کنید
pytest -m unit

تست integration داریم که وابستگی‌های داخلی رو بررسی میکنه نه بیرون از پروژه با مارکر integeration مشخص کنید (فراموش نکنید در این نوع تست زیرساخت واقعی منتها در محیط ایزوله تست میشه)
pytest -m integeration

و همچنین برای تست e2e که رفتار واقعی یوزر رو تست میکنه با مارکر e2e مشخص کنید

تو برخی سیستم‌های خاص لازم هستش که رفتار اشتباه هم تست بشه (سیستم‌های مالی) با مارکر exception کار کنید

برخی تست ممکنه وابستگی‌های سنگینی داشته باشن جهت راه اندازی یا کویری‌های سنگینی بزنن با مارکر slow مشخص میشن

یه نکته جالب تو تست‌هاتون با mock مرزها رو مشخص می‌کنید این موضوع مهم هستش

بیشترین تست رو unit
در حد معقول رو integeration
و تعداد کم رو e2e شامل میشه

با مجموع این موارد و استفاده بجا شما می‌تونید استراتژی تست بچینید برای سناریوهای مختلف و محیط‌های جداگانه

چندتا ابزار مهندسی دیگه
تو سیاست نامه سازمان‌های حرفه‌ای، قوانین زمان ریسپانس برای یک اندپوینت میزارن، با استفاده از پکیج pytest-timeout و مارکر timeout میتونید این سیاست‌نامه رو بررسی کنید

@pytest.mark.timeout(3)
def test_timeout();
     time.sleep(4)
     assert 1 == 1

با استفاده از پکیج pytest-cov میتونید میزان پوشش کدهای تست شده رو بررسی کنید و علاوه بر اون حجم درست کدهای تست شده (درستی و کیفیت تست رو شامل نمیشه) و یک گزارش بگیرید که شامل جزئیات کمتر یا بیشتر باشه ، اینکه در متد یا کلاس یا ماژول یا برنامه یا پکیچ تا چه مقدار و میزانی کدها تست شده یا چه بخش‌هایی از یک متد تست شده یا نشده (try/except , if/else)


در نهایت pytest یک فریمورک در خدمت مهندسی نرم افزار هستش جایی که حلقه
(فرآیند -> تحلیل -> ساخت -> تست -> اجرا ) شکل میگیره


#test


@code_crafters

معماری به مثابه معنا، نه جداسازی سطحی (در سیستم‌های بزرگ و چند لایه)

داخل مهندسی نرم افزار (بخش مفاهیم و طراحی) ما با موضوع ساختار برنامه روبرو هستیم، در مهندسی نرم افزار ساختار سیستم باید گرافی باشه، از ساختار پنکیکی جلوگیری که این ساختار به معنای ورشکستی سیستم تلقی میشه، منظور چیه ؟؟؟ یک مثال ساده بگم، شما چهارتا سرویس دارید این چهار سرویس رو در یک نقطه دسترسی قرار ندید یعنی نگید از پورت هشتاد ورودی برو به همه سرویس‌ها

بیاید مثال عملی تر بزنیم
ما مقادیر:
static
media
UI application(front)
api application(backends)

رو داریم همه اینها رو در ورودی بعد از web server نزارید، باید ساختار گرافی بسازید، به چه شکل؟؟؟

Nginx => static, media, ui, gateway

gateway=> BFF, identity service, cms service

BFF => (first level backends)

جالب شد BFF چیه؟؟؟
اینجا دقیقا جایی هستش که اوج معماری مدرن شروع میشه تفکیک بین microservice بر پایه DDD یا فقط modularity monoloth (که کابوس شکست سازمان‌هایی هستش که مهندس نرم افزار ندارن) یعنی چی؟؟؟ تفکیک پذیری بر اساس معنا، نه بر اساس جدا سازی

خود BFF مخفف backend for front هستش خب بیایید این رو یکم براتون بازش کنم

سه مفهوم رو در DDD براتون بگم تا یکم مسئله رو باز کنم
Ubiquitous language
SAGA
Aggregation

چطور سرویس‌هامون رو از هم جدا کنیم (سرویس، نه دامنه) در زبان مشترک اگه برای یک مفهوم چند معنا داشتیم اونجا مرزهای سرویس‌هاتون قرار گرفته برای مثال (کاربر: از نگاه پشتیبان یعنی پاسخ گیرنده، از نگاه کسب و کار یعنی مشتری، از نگاه برنامه نویس یعنی یوزر) جنگ بر سر هویت و موجودیت هستش:

هویت: هر چیزی که به تنهایی بتونه مستقل معنا بده
موجودیت: هر چیزی که جهت معنا نیاز به اتصال داشته باشه

واسه مثال: کاربر هویت هستش (دارای شناسه یکتا در سیستم)، مشتری و پاسخ گیرنده موجودیت وابسته به کاربر هستند که شماره تماس، آدرس و ... دارند

موضوع بعدی SAGA:
انجام یکسری عملیات های رکوردی در یک درخواست، یعنی شما یک درخواست میگیرید و چندین جدول مختلف رو باهاش تاچ و کامیت میکنید (یک الگوی سخت)

مورد بعدی aggregation:
دریافت یک درخواست و جمع آوری اطلاعات در یک نقطه خاص

این سه مورد موضوعاتی هستند که داخل BFF حضور دارن یعنی دامنه اصلی و شاید پشتیبان در رویکرد DDD و اینجا جایی هستش که بهش میگیم شروع business logic و فاز توسعه میکروسرویس شروع میشه و امسدوارم فاز پایه خوبی رو اجرا کرده باشین وگرنه شروع نشده با شکست روبرو هستید

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

نوع داده و درخواست:
اگه درخواست از نوع sync باشه از gRPC استفاده میکنید
اگه نوع درخواست async/event driven باشه از rabbitmq

در یک زبان ساده بگم بهتون، grpc میاد وسط سرویس‌هاتون قرار میگیره و rabbitmq میاد در کنار سرویس‌هاتون قرار میگیره و در صورت نیاز در جاهای خاصی میاد بین سرویس‌ها نقش ایفا میکنه (جایی که هزاران درخواست میان جهت کامیت در دیتابیس)

در نهایت چه اتفاقی افتاد؟؟؟ فرانت هیچگونه اطلاعی از سرویس‌های بکند نداره، coupling ضعیف شکل میگیره و معماری با قدرت به سمت خوبی پیش میره

مرزبندی سرویس‌ها رو جدی بگیرید، این یک روند بر اساس تجربه و دانش هستش، و با DTO مرز بین سرویس‌هاتون رو داخل کدهاتون مشخص کنید

درخواست در مرحله اول میرسه به view و داخل اون ابتدا serializable اجرا میشه (درستی نوع تایپ مدنظر)، در مرحله بعد وارد سرویس میشه و داخل سرویس ابتدا value object (یک مفهوم دیگه از DDD) صدا زده میشه جهت ولیدیشن و اعتبار سنجی و بعد منطق تجاری روش اجرا میشه و در نهایت به DTO تبدیل میشه و ویو جهت ریسپانس برگردونده میشه

request => view - response

view => serialization (type data) - service - return DTO

service => value objects (validation) - logic (data layer and ...) - DTO


فراموش نکنید مهندسی نرم افزار یک مسیله به مرور یادگیرنده هستش، در هر مرحله یادگیری بینشتون تغییر میکنه


@code_crafters

چند نکته جالب بهتون بگم

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

#File tox.ini

[tox]
envlist = py39, py310

[testenv]
deps = -rrequirements.txt

commands = pytest

علاوه بر این شما میتونید داخل تست‌هاتون از دیباگر داخل پایتون (pdb) استفاده کنید، در نقاط مدنظرتون مقدار breakpoint() رو قرار بدید و بعد از اجرا با pytest دیباگرتون رو با دستورات
c ادامه برنامه
n رفتن به خط بعد
l نمایش خطوط اطراف
q بستن دیباگر

مدیریت کنید


در نهایت یکی از موضوعات جالب pytest داشتن پلاگین‌های بی شمار آن است
pytest-cov
pytest-django
pytest-timeout
pytest-async
pytest-repeat
pytest-bdd
pytest-xdist

و کلی پلاگین دیگه که داخل داکیومنت رسمی pytest

Refrence guides -> pytest plugin list

مشاهده کنید


و یک کتاب خوب هم جهت خوندن بهتون معرفی کنم
python testing with pytest
هستش

#test

@code_crafters

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

کار ریموت خوبه؟؟؟

اگه عادت کنی که روزای تعطیل هم کار کنی آره

اونم تا قبل خواب😐😐😐😐

تست بعنوان یک تفکر سیستمی


در سیستم‌های مبتنی بر نرم افزار ما دو موضوع کلی داریم

یک فرایند نرم افزار: تعیین چهارچوب
دو مهندس نرم افزار: تعیین تکنولوژی


در طی تولید یک نرم افزار نقش مهندس نرم افزار بشدت کلیدی هستش که در همه جای یک سیستم بارها و کرات دیده میشه

چرا انقدر این نقش کلیدی هستش؟؟؟
در طی این پروسه ما با حالت‌های مختلف زیاد ناشناخته روبرو هستیم که نیاز داریم همیشه از یک نگاه سیستماتیکی بهش پرداخته بشه و این اصلی ترین وظیفه مهندس نرم افزار هستش

یک سیستم در طی روند زیر تولید میشه:

تحلیل -» طراحی -» توسعه -» تست -» تحویل


بحث ما بر سر موضوع آزمایش هستش
کلیت تست‌ها به دو دسته کلی تقسیم میشن:
تست جعبه سفید: آزمایش منطق داخلی کدهای نوشته شده
تست جعبه سیاه: آزمایش رفتار سیستم

اینکار عمدتا توسط تسترها (QA) صورت میگیره و مهندس نرم افزار با ارائه اسناد و دیاگرام‌های پروژه در روند تست و پلن تست حضور خواهد داشت

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

بیایید یک مثال ساده بزنیم
کدهای تولید شده توسط تیم توسعه ممکنه ساختار متفاوتی داشته باشه که با رویکردهای مختلفی نوشته شده و پیاده سازی گشته هر نوع ساختار نیاز به یک شیوه خاص جهت تست  هستش،جایی که تیم توسعه خوب عملکرده باشه تست جعبه سفید همیشه کار میکنه و این عالیه، اما اگه بد عمل کرده باشه تست جعبه سفید هزینه بردار، سخت، زمانبر، شکننده و گاها غیر ممکن میشه اما توسعه متوقف میشه؟؟؟ نه ما جایی که به هر عنوانی نتونیم تست منطقی انجام بدیم، تست رفتاری (جعبه سیاه) انجام میدیم یعنی یک فرآیند رو در نظر میگیریم و پیش میبریم، این منجر میشه که توسعه با تعطیلی روبرو نشه

نمونه بارز تست جعبه سفید، تست واحد هستش
و نمونه بارز تست جعبه سیاه e2e هستش

دقت داشته باشید که بر اساس نوع سیستم شما ممکنه تست متفاوت باشد، یعنی ما یجا تست‌هایی داریم بر اساس task, user story, future use-case اما در سبستمی متفاوت تر ما تست‌هایی از قبیل TCCN, Z-object, RTRSM داریم و یکجایی هم BDD داریم

مهمترین موارد در تست سیستم چی هستش؟؟؟
تست ماژول‌های حیاتی
تست ماژول‌های پر خطا
ساختار داده ورودی و خروجی
انتظار رفتار مورد قبول از سیستم
بررسی نوع ارتباط داخلی و بیرونی
و ...

آیا همه تست‌ها با کد زده میشن؟؟؟
خیر برخی از تست‌ها دستی و انسانی هستند. و برخی تست ها در محیط آزمایشگاهی که بهشون میگیم HIL test و SIL test

آیا همیشه مقادیر درست تست میشن؟؟؟ خیر گاهی بر حسب نیاز مقادیر غلط تست میشن تا چک کنیم رفتار سیستم رو و بتونیم مانع جلوگیری فروپاشی سیستم در اون نقطه بشیم

در نهایت آیا همه چیز تست میشه؟؟؟
خیر اما تست بصورت پوشش کامل باید باشد


در نهایت فراموش نکنیم که تست از نگاه بالغ یعنی بررسی اینکه سیستم در موقعیت اشتباه و خطا، چه رفتاری از خودش نشون میده



#test

@code_craftets

من تو محیط‌های کاری متفاوت زیادی بودم

اما امروز متوجه یک موضوع جالبی شدم تو شناخت مدیرهای باسواد متخصص و مدیرهای بی‌سواد غیر متخصص


امروز مدیر مجموعه برامون صحبت میکرد از انتگرال مجموعه بسته و ارتباطش با نیروی کار گرفته تا تاثیر وجود آب و هوای بارانی در گذر زمان و نگاه فیزیکی به مسئله، به حدی موضوع و مسئله جالب بود که تمام خستگی چند شب اخیر رو فراموش کرده بودم

برام جالب بود در یکی از مدیران متخصص قبلیم هم من این موضوع رو دیده بودم

اما در مدیران بی‌سواد غیر متخصص، داخل مجموعه زیر نظرشون هیچی ندیدم جز خاله زنک بازی و حاشیه سازی برای نیروها

و همین یک مورد نشون میده که حجم تخصص مدیر چقدر تاثیر گذار هستش که نیروها و سازمان در چه شرایطی باشند

خیلی هم جالبه که مدیران متخصص، نیروهای با اصالت و با شخصیت بیشتری رو استخدام میکنن، تا نسبت به مدیران بی‌سواد و غیر متخصص

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

از گروه مستقل تست (ITG) تا مهندس نرم‌افزار در تست (SDET)

1️⃣ تفکیک «صحت» و «تصدیق» در مهندسی نرم‌افزار
کیفیت نرم‌افزار یکی از چالش‌برانگیزترین موضوعات در صنعت نرم‌افزار است.
در صنایع فیزیکی، کیفیت با متریک‌های عینی مانند وزن، ضخامت، مقاومت یا ابعاد قابل اندازه‌گیری است؛ اما در نرم‌افزار، کیفیت مفهومی چندبعدی و تا حدی انتزاعی است.
در مهندسی نرم‌افزار، کیفیت معمولاً از طریق دو مفهوم بنیادین بررسی می‌شود:

✅ صحت (Verification)
«آیا سیستم را درست ساخته‌ایم؟»
تمرکز بر درستی پیاده‌سازی، منطق کد و انطباق با طراحی.
بررسی صحت الگوریتم‌ها
پوشش تست
عدم وجود باگ منطقی
رعایت استانداردهای کدنویسی
این موضوع بیشتر به درون سازمان و تیم توسعه مربوط است.

✅ تصدیق (Validation)
«آیا سیستم درست را ساخته‌ایم؟»
تمرکز بر برآورده شدن نیازهای واقعی مشتری.
انطباق با نیازمندی‌ها
تجربه کاربری مناسب
حل مسئله واقعی کاربر
این موضوع به بیرون سازمان و رضایت مشتری مرتبط است.

2️⃣ کیفیت، مسئولیت جمعی است
کیفیت نرم‌افزار:
فقط مسئولیت تیم توسعه نیست
فقط با تست انتهایی حاصل نمی‌شود
فقط با سخت‌گیری افراطی ایجاد نمی‌شود
فقط با تأیید یک گروه خاص تضمین نمی‌شود

در رویکردهای مدرن، گروه مستقل تست (ITG) از ابتدای پروژه در کنار تیم توسعه قرار می‌گیرد، نه فقط در فاز پایانی.
در چارچوب‌های چابک، تستر یکی از نقش‌های کلیدی تیم است و از مرحله تحلیل نیازمندی‌ها تا تحویل محصول حضور دارد.

این حضور باعث می‌شود:
بدهی فنی کاهش یابد
تصمیمات فنی پخته‌تر شوند
ریسک معماری کاهش پیدا کند
بلوغ فنی تیم افزایش یابد

و این دقیقاً همان نقطه‌ای است که نقش کلاسیک Tester به سمت SDET (Software Development Engineer in Test) تکامل پیدا می‌کند.

3️⃣ کیفیت از دید استاندارد
در استاندارد قدیمی کیفیت نرم‌افزار یعنی:
ISO/IEC 9126
این استاندارد کیفیت را در چند بعد تعریف می‌کند:
قابلیت نگهداری (Maintainability)
قابلیت استفاده مجدد (Reusability)
در دسترس بودن (Availability)
اطمینان‌پذیری (Reliability)
جامعیت (Integrity)
انعطاف‌پذیری (Flexibility)
قابلیت حمل (Portability)
درستی (Correctness)

این نگاه نشان می‌دهد کیفیت صرفاً «کم بودن باگ» نیست.


4️⃣ متریک کلیدی: پیچیدگی سیکلی (Cyclomatic Complexity)
یکی از مهم‌ترین متریک‌های ساختاری کیفیت کد است

Cyclomatic Complexity (CC)
این متریک نشان می‌دهد:

چند مسیر تصمیم‌گیری مستقل در یک ماژول یا تابع وجود دارد.

هرچه این عدد بالاتر باشد:
احتمال خطا بیشتر
تست‌نویسی سخت‌تر
نگهداری دشوارتر

طبقه‌بندی پیشنهادی:
مقدار cc < 5 وضعیت عالی
مقدار cc < 10 وضعیت مطلوب
مقدار cc < 15 در معرض ریسک (نیاز به تست بیشتر)
مقدار cc > 20 وضعیت بحرانی (نیاز به بازنگری معماری)

این متریک می‌تواند برای هر:
ماژول
کلاس
تابع
متد
محاسبه شود.


5️⃣ ابزار محاسبه CC در پایتون
در زبان پایتون می‌توان با کتابخانه زیر این مقدار را محاسبه کرد:
Radon
نمونه استفاده:
radon cc your_file.py -a
این ابزار می‌تواند در:
CI/CD
Code Review
Quality Gate

سیاست‌نامه کیفیت سازمان
استفاده شود.


6️⃣ گذار از ITG به SDET
در مدل سنتی:
گروه تست مستقل (ITG)
تست در انتهای پروژه
تمرکز بر کشف باگ

در مدل مدرن SDET:
مهندس تست بخشی از تیم توسعه است
تست خودکار می‌نویسد
در طراحی معماری اثر می‌گذارد
متریک‌های کیفیت را تحلیل می‌کند
در تصمیمات فنی مشارکت دارد

در واقع SDET فقط «کشف‌کننده خطا» نیست؛
او «معمار کیفیت» است.

جمع‌بندی
کیفیت نرم‌افزار حاصل:
صحت (Verification)
تصدیق (Validation)
معماری سالم
پیچیدگی کنترل‌شده
حضور تست از ابتدا
بلوغ مهندسی تیم
و در نهایت، کیفیت یک فعالیت انتهایی نیست؛
بلکه یک فرهنگ سازمانی است.


با تشکر از هوش مصنوعی برای تمیز کردن متن
#test

@code_crafters

هر اتفاقی افتاد یادتون نره ما یک ملتیم که جز دل‌های همدیگه جایی نداریم

آخرین مجله اکونومیست رو خوندم، که با سرتیتر بزرگ نوشته بود
(آخرالزمان شغل‌ها)

خب ماجرا از چه قراره؟؟؟
مجله راجب هوش مصنوعی و شغل‌ها صحبت کرده بود، موارد زیادی از بدبینی و خوش بینی و پیشنهاد راهکار برای دولت‌ها و ... مطرح کرده بود

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

طبق این نمودار از زمان ظهور chat bot ها میزان اشتغال دائم مهندسین علوم داده، مهندسین نرم افزار، مهندسین علوم کامپیوتر از ۷۷ درصد به نزدیک ۵۰ درصد رسیده و این فقط برای سه سال هستش که از نسخه ضعیفش تا الان که قویترین نسخه اون شبکه شبیه به نصف شبکه عصبی انسان رو داره رخ داده

اینکه چه برداشت یا تفسیری از اون داشته باشید برعهده خودتون هستش و این آمار برای کشورهایی هستش که تو تکنولوژی بشدت سرمایه گذاری کردن و شاه رگ بزرگ اقتصادهای بزرگ جهان هستند

اینکه مجله یه جاهایی اومده یسری حرفا از یکسری ها گفته یا راهکار داده و .... به معنای واقعیت یا پیروی سیاست مدارها از اون نیستش

اعداد و ارقام واقعیت‌ها رو میگن

@code_crafters

تو فیلمای تاریخی همیشه میدیدم
که یه نیرویی حمله میکردن به یک قلعه، وقتی نمیشد تصرفش کنن

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


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