CodeCrafters

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

تست بعنوان یک تفکر سیستمی در سیستم‌های مبتنی بر نرم افزار ما دو موضوع کلی داریم یک فرایند نرم افزار: تعیین چهارچوب دو مهندس نرم افزار: تعیین تکنولوژی در طی تولید یک نرم افزار نقش مهندس نرم افزار بشدت کلیدی هستش که در همه جای یک سیستم بارها و کرات دیده میشه چرا انقدر این نقش کلیدی هستش؟؟؟ در طی این پروسه ما با حالت‌های مختلف زیاد ناشناخته روبرو هستیم که نیاز داریم همیشه از یک نگاه سیستماتیکی بهش پرداخته بشه و این اصلی ترین وظیفه مهندس نرم افزار هستش یک سیستم در طی روند زیر تولید میشه: تحلیل -» طراحی -» توسعه -» آزمایش -» استقرار بحث ما بر سر موضوع آزمایش هستش کلیت تست‌ها به دو دسته کلی تقسیم میشن: تست جعبه سفید: آزمایش منطق داخلی کدهای نوشته شده تست جعبه سیاه: آزمایش رفتار سیستم اینکار عمدتا توسط تسترها (QA) صورت میگیره و مهندس نرم افزار با ارائه اسناد و دیاگرام‌های پروژه در روند تست و پلن تست حضور خواهد داشت اما چرا ما نیاز به انواع مختلفی از تست داریم، جواب خیلی ساده هستش بعلت وجود پیچیدگی‌های مختلف و سیستم‌های گوناگون نیاز به تست در شکل‌های مختلف در چرخه حیات نرم افزار شکل گرفت بیایید یک مثال ساده بزنیم کدهای تولید شده توسط تیم توسعه ممکنه ساختار متفاوتی داشته باشه که با رویکردهای مختلفی نوشته شده و پیاده سازی گشته هر نوع ساختار نیاز به یک شیوه خاص جهت تست  هستش،جایی که تیم توسعه خوب عملکرده باشه تست جعبه سفید همیشه کار میکنه و این عالیه، اما اگه بد عمل کرده باشه تست جعبه سفید هزینه بردار، سخت، زمانبر، شکننده و گاها غیر ممکن میشه اما توسعه متوقف میشه؟؟؟ نه ما جایی که به هر عنوانی نتونیم تست منطقی انجام بدیم، تست رفتاری (جعبه سیاه) انجام میدیم یعنی یک فرآیند رو در نظر میگیریم و پیش میبریم، این منجر میشه که توسعه با تعطیلی روبرو نشه نمونه بارز تست جعبه سفید، تست واحد هستش و نمونه بارز تست جعبه سیاه e2e هستش دقت داشته باشید که بر اساس نوع سیستم شما ممکنه تست متفاوت باشد، یعنی ما یجا تست‌هایی داریم بر اساس task, user story, future use-case اما در سبستمی متفاوت تر ما تست‌هایی از قبیل TCCN, Z-object, RTRSM داریم و یکجایی هم BDD داریم مهمترین موارد در تست سیستم چی هستش؟؟؟ تست ماژول‌های حیاتی تست ماژول‌های پر خطا ساختار داده ورودی و خروجی انتظار رفتار مورد قبول از سیستم بررسی نوع ارتباط داخلی و بیرونی و ... آیا همه تست‌ها با کد زده میشن؟؟؟ خیر برخی از تست‌ها دستی و انسانی هستند. و برخی تست ها در محیط آزمایشگاهی که بهشون میگیم HIL test و SIL test آیا همیشه مقادیر درست تست میشن؟؟؟ خیر گاهی بر حسب نیاز مقادیر غلط تست میشن تا چک کنیم رفتار سیستم رو و بتونیم مانع جلوگیری فروپاشی سیستم در اون نقطه بشیم در نهایت آیا همه چیز تست میشه؟؟؟ خیر اما تست بصورت پوشش کامل باید باشد در نهایت فراموش نکنیم که تست از نگاه بالغ یعنی بررسی اینکه سیستم در موقعیت اشتباه و خطا، چه رفتاری از خودش نشون میده #test @code_craftets

اخیرا مقامات کشور زیادی پیامک نمیدن؟؟؟ یعنی فهمیدن هیچکس رسانه‌هاشون رو باور و پیگیری نمیکنن میخوان با پیامک حرف بزنن گویا نمیدونن اسپم میشه😁😁😁😁

کار ریموت خوبه؟؟؟ اگه عادت کنی که روزای تعطیل هم کار کنی آره اونم تا قبل خواب😐😐😐😐

بچه‌ها خودتون یا اطرافیاتون اگه قبلا با پلتفرم مودل (moodle) کار کردن ممنون میشم بهم معرفی کنین

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

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

چند نکته جالب بهتون بگم یکی استفاده از پکیج 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 Refrence guides -> pytest plugin list مشاهده کنید و یک کتاب خوب هم جهت خوندن بهتون معرفی کنم python testing with 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

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

چرا 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

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

چرا 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 برای محیط تست و اوتومیشن نکنید بهتون امکان مارک‌گذاری رو‌میده یک سیستم شبیه به برچسب دهی یا تگ گذاری کردن برای تست‌هاتون (skip, fail , ...) یک قسمت محبوب برای توسعه دهنده‌ها parametrize هستش، در یک سناریوی ویو شما status های مختلف دارید 200, 400, 500 دارید لازم نیست چندتا تست بنویسید یا assert های مختلف برای هر بخش با این ویژگی می‌تونید یکبار یک تست جامع برای ویوتون بنویسید تو هر بخش اضافه شدن جدید بهش فقط parameterize رو بروز می‌کنید (یک مثال کاربردی تر ویویی که params میگیره) یا ویویی که با permission‌های مختلف کار میکنه هستش و جالبترین قسمتش آرگومان‌های داخلی خودش برای cli هستش که میتونید یک حالت مانیتور مانند کامل برای تست‌هاتون داشته باشید -v -s --tb -ra -m -k --fixtures --maxfail --duration --markers #test @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 و به همون اندازه معماری درست توسعه دامنه محور چندتا سوال از خودتون بپرسید آیا منطق تجاری داخل سیستم مهمتر هستش و انتهای پروژه بازتره؟؟؟ پس برید از نوشتن تست سرویس و پاس کردن اون شروع کنین آیا تراکنش در سیستم مهمتره و انتهای پروژه مشخص‌تر؟؟؟ پس برید از نوشتن تست ویو و پاس کردنش شروع کنید در نهایت وظیفه توسعه دهنده نوشتن تست واحد و تجمیع و اطمینان از عملکرد منطقی کد هستش و تستر اطمینان از صحت سرویس و رفتار سرویس #rest #tdd #ddd #bdd @code_crafters

شما تا حالا دیدین تو این مملکت آخوند جماعت نسبت به چیزی معترض باشن؟؟؟ این نشان عالی از مفتخوری هستش

📌 یادگیری کتابخانه Playwright واقعاً ارزشمنده چه برای خزش وب (Web Crawling) و چه برای تست سامانه‌ها، Playwright یکی از ابزارهای بسیار قدرتمنده دست شما رو کاملاً باز می‌ذاره و تقریباً هر چیزی که برای کار حرفه‌ای نیاز دارید رو فراهم کرده. یکی از قابلیت‌های جذابش حالت Headless هست: * اگر headless=false باشه، کد دقیقاً روی دسکتاپ اجرا می‌شه و توسعه و دیباگ رو خیلی راحت می‌کنه * اگر headless=true باشه، آماده‌ی اجرا روی سرور می‌شه (ایده‌آل برای استفاده داخل CI/CD) 🧠 مفهوم Context رو به‌خوبی پیاده‌سازی کرده (تصور کنید یک پروفایل جدید در مرورگر باز می‌کنید که می‌تونه چندین تب همزمان داشته باشه) 📸 امکان Screenshot و حتی Record کردن ویدیو از صفحه رو می‌ده چه در حالت headless و چه غیر headless (خیلی کاربردی برای مستندسازی، داکیومنت فنی و آموزش کار با سامانه‌ها) 🔌 کار با API رو هم به‌صورت native در اختیارتون می‌ذاره مدیریت کوکی، سشن و احراز هویت در طول اجرای تست‌ها رو خودش کاملاً هندل می‌کنه 📦 با انواع فرمت‌های داده سازگاره و خیلی راحت می‌تونید با داده‌های مختلف کار کنید 🔥 اما یه نکته‌ی خیلی جذاب در تست سامانه‌ها: فرض کنید طبق سیاست‌نامه‌ی سازمان، یک صفحه باید حداکثر تا ۵ ثانیه اندپوینت‌هاش پاسخ بدن. تستر می‌تونه به اون بخش از صفحه timeout پنج‌ثانیه‌ای بده و خروجی رو بررسی کنه بدون درگیری مستقیم با لاگ‌ها یا کدهای پیچیده. هرچی بیشتر درباره Playwright می‌خونم، بیشتر به این نتیجه می‌رسم که این کتابخونه حاصل تجربه‌ی واقعی در دنیای مهندسی نرم‌افزاره، نه صرفاً یک ابزار تئوریک. @code_crafters