🔵 عنوان مقاله
What's New for Testing in Spring Boot 4 and Spring Framework 7
🟢 خلاصه مقاله:
در نسخههای جدید فریمورکهای بهروز، ابزارهای تست تغییرات مهمی داشتهاند که توسعهدهندگان باید از آنها مطلع شوند. اگر شما در زمینه خودکارسازی تست برنامههای Spring Boot فعالیت میکنید، حتماً به نتایج ارائه شده در نسخههای جدید توجه کنید. در این مقاله، فیلیپ ریکس درباره ویژگیهای جدید و بهبودهای مهم در Spring Boot 4 و Spring Framework 7 صحبت میکند، که میتواند فرآیند تست را سادهتر و کارآمدتر کند.
نسخههای جدید این فریمورکها امکانات متنوعی برای تستهای واحد و یکپارچه فراهم کردهاند؛ از جمله ابزارهای بهتر برای شبیهسازی سرویسها و امکان تست سریعتر و دقیقتر برنامهها.آموزشهای جدید و بروزرسانیهای بزرگی در راه است که باعث افزایش کیفیت و سرعت توسعه برنامهها میشود. مهم است که توسعهدهندگان با این تغییرات آشنا شوند تا بتوانند هر چه بهتر از قابلیتهای جدید بهرهمند شوند و نرمافزارهای باکیفیتتری تولید کنند.
#SpringBoot #SpringFramework #تست_نرمافزار #نسخهجدید
🟣لینک مقاله:
https://cur.at/E9HhwWM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
What's New for Testing in Spring Boot 4 and Spring Framework 7
🟢 خلاصه مقاله:
در نسخههای جدید فریمورکهای بهروز، ابزارهای تست تغییرات مهمی داشتهاند که توسعهدهندگان باید از آنها مطلع شوند. اگر شما در زمینه خودکارسازی تست برنامههای Spring Boot فعالیت میکنید، حتماً به نتایج ارائه شده در نسخههای جدید توجه کنید. در این مقاله، فیلیپ ریکس درباره ویژگیهای جدید و بهبودهای مهم در Spring Boot 4 و Spring Framework 7 صحبت میکند، که میتواند فرآیند تست را سادهتر و کارآمدتر کند.
نسخههای جدید این فریمورکها امکانات متنوعی برای تستهای واحد و یکپارچه فراهم کردهاند؛ از جمله ابزارهای بهتر برای شبیهسازی سرویسها و امکان تست سریعتر و دقیقتر برنامهها.آموزشهای جدید و بروزرسانیهای بزرگی در راه است که باعث افزایش کیفیت و سرعت توسعه برنامهها میشود. مهم است که توسعهدهندگان با این تغییرات آشنا شوند تا بتوانند هر چه بهتر از قابلیتهای جدید بهرهمند شوند و نرمافزارهای باکیفیتتری تولید کنند.
#SpringBoot #SpringFramework #تست_نرمافزار #نسخهجدید
🟣لینک مقاله:
https://cur.at/E9HhwWM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
rieckpil
What's New for Testing in Spring Boot 4 and Spring Framework 7
Complete guide to Spring Boot 4.0 testing: test context pausing, JUnit 6, Testcontainers 2.0, new modular Spring Boot, TestRestClient, etc.
🔵 عنوان مقاله
How I automated the annoying part of my job with Goose and Playwright MCP
🟢 خلاصه مقاله:
در مقالهای با عنوان «چگونه بخش خستهکننده کارم را با Goose و Playwright MCP خودکار کردم»، فیلیپ هریچ یک ایده جذاب و عملی برای بهبود فرآیندهای روزمره در کار تست نرمافزار ارائه میدهد. او توضیح میدهد که چگونه با بهرهگیری از ابزارهای قدرتمند مانند Playwright MCP و Goose، میتوان برخی وظایف تکراری و زمانبر را خودکار کرد و در نتیجه بهرهوری تیم تست را افزایش داد.
فیلیپ هریچ در این مقاله به جزئیات نحوه پیادهسازی این راهحلها میپردازد و نشان میدهد که چگونه این ابزارها میتوانند کارهای یکنواخت و خستهکننده را سادهتر و سریعتر انجام دهند. او بر اهمیت کاهش خطای انسانی و زمانگیری موثر تأکید میکند و بیان میکند که استفاده از این فناوریها جایگزین مناسبی برای انجام دستی وظایف روزانه است.
این روشهای خودکارسازی نه تنها فرآیندهای آزمایش را بهبود میبخشد، بلکه امکان تمرکز بیشتر بر روی بهبود کیفیت و توسعه ویژگیهای جدید را فراهم میآورد. بابهکارگیری ادواتی مانند Goose و Playwright MCP، تیمهای تست میتوانند سختترین کارهای تکراری را به راحتی مدیریت کنند و بهرهوری کلی فعالیتهای خود را بالاتر ببرند.
#خودکارسازی_تست #توسعه_نرمافزار #Playwright #Goose
🟣لینک مقاله:
https://cur.at/kDGW1n4?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How I automated the annoying part of my job with Goose and Playwright MCP
🟢 خلاصه مقاله:
در مقالهای با عنوان «چگونه بخش خستهکننده کارم را با Goose و Playwright MCP خودکار کردم»، فیلیپ هریچ یک ایده جذاب و عملی برای بهبود فرآیندهای روزمره در کار تست نرمافزار ارائه میدهد. او توضیح میدهد که چگونه با بهرهگیری از ابزارهای قدرتمند مانند Playwright MCP و Goose، میتوان برخی وظایف تکراری و زمانبر را خودکار کرد و در نتیجه بهرهوری تیم تست را افزایش داد.
فیلیپ هریچ در این مقاله به جزئیات نحوه پیادهسازی این راهحلها میپردازد و نشان میدهد که چگونه این ابزارها میتوانند کارهای یکنواخت و خستهکننده را سادهتر و سریعتر انجام دهند. او بر اهمیت کاهش خطای انسانی و زمانگیری موثر تأکید میکند و بیان میکند که استفاده از این فناوریها جایگزین مناسبی برای انجام دستی وظایف روزانه است.
این روشهای خودکارسازی نه تنها فرآیندهای آزمایش را بهبود میبخشد، بلکه امکان تمرکز بیشتر بر روی بهبود کیفیت و توسعه ویژگیهای جدید را فراهم میآورد. بابهکارگیری ادواتی مانند Goose و Playwright MCP، تیمهای تست میتوانند سختترین کارهای تکراری را به راحتی مدیریت کنند و بهرهوری کلی فعالیتهای خود را بالاتر ببرند.
#خودکارسازی_تست #توسعه_نرمافزار #Playwright #Goose
🟣لینک مقاله:
https://cur.at/kDGW1n4?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Filiphric
How I automated the annoying part of my job with Goose and Playwright MCP
Learn how to automate repetitive issue creation tasks using Goose desktop app and Playwright MCP. Stop context switching and let AI handle the boring stuff.
ترجمه فارسی | The Pragmatic Programmer
این کتاب فقط درباره کدنویسی نیست؛ دربارهی طرز فکر یک برنامهنویس حرفهایه.
یاد میده چطور مسئولیت کارت رو بپذیری، تصمیمهای بهتر بگیری و کدی بنویسی که قابل اعتماد و قابل نگهداری باشه.
بعد از سالها هنوز هم یکی از مهمترین منابع رشد حرفهای برنامهنویسهاست؛
از جونیور تا سنیور.
https://github.com/hheydarian/the-pragmatic-programmer-parsion
این کتاب فقط درباره کدنویسی نیست؛ دربارهی طرز فکر یک برنامهنویس حرفهایه.
یاد میده چطور مسئولیت کارت رو بپذیری، تصمیمهای بهتر بگیری و کدی بنویسی که قابل اعتماد و قابل نگهداری باشه.
بعد از سالها هنوز هم یکی از مهمترین منابع رشد حرفهای برنامهنویسهاست؛
از جونیور تا سنیور.
https://github.com/hheydarian/the-pragmatic-programmer-parsion
GitHub
GitHub - hheydarian/the-pragmatic-programmer-parsion: Persian translation of "The Pragmatic Programmer: From Journeyman to Master"…
Persian translation of "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt & David Thomas. - hheydarian/the-pragmatic-programmer-parsion
❤1
با توجه با گزارشهای دریافتی، استفاده از آسیبپذیری تازه کشف شده در React به شکل گسترده در کشور فعال شده است، به کلیه کسبوکارهایی که از React استفاده میکنند توصیه اکید میشود که پچهای این آسیبپذیری را اعمال کنند.
https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
react.dev
Critical Security Vulnerability in React Server Components – React
The library for web and native user interfaces
چرا آسیبپذیری اخیر ریاکت فقط توی معماری RSC دیده شد و نه در SSR؟
تو روزهای اخیر یک آسیبپذیری جدی توی ریاکت مطرح شد که به کامپوننتهای سمت سرور مربوط بود.
این اسیب پذیری لزوما مربوط به ورژن نبود. چون به فرض اگر نکست بالای ۱۴ بودیم اما کماکان page router استفاده میکردیم هیچ خطری وجود نداشت
خب حالا app router با page router چه تفاوتی دارن؟
جواب این سؤال توی تفاوت عمیق معماری SSR و RSC قرار داره.
معماری SSR دقیقاً چه کاری انجام میده؟
تو این مدل، ریاکت روی سرور اجرا میشه و خروجی نهایی به شکل HTML کامل ساخته میشه و برای مرورگر فرستاده میشه.
بعد از اون، کد جاوااسکریپت توی مرورگر دانلود میشه و فرآیند هیدریشن انجام میشه.
نکتهی مهم اینجاست که HTML فقط یک خروجی نهایی و ایستاست.
این خروجی نه ساختار کامپوننتها رو نگه میداره، نه منطق اجرا رو منتقل میکنه و نه مرزی بین کد سمت سرور و کلاینت مشخص میکنه.
به همین خاطر، سطح حمله توی این معماری معمولاً محدود میشه به چیزهایی مثل XSS یا template injection و خود ریاکت توی سمت کلاینت نقش فعالی توی تفسیر دادههای ورودی نداره.
معماری RSC چه چیزی رو عوض کرد؟
توی معماری RSC، کامپوننتها واقعاً روی سرور اجرا میشن و نتیجهی اجرای اونها بهجای HTML، به شکل ساختار درختی ریاکت به سمت کلاینت میره.
این انتقال با استفاده از یک پروتکل اختصاصی به اسم React Flight انجام میشه.
به زبان سادهتر، مرورگر دیگه فقط یک خروجی آماده تحویل نمیگیره، بلکه اطلاعات لازم برای ساخت رابط کاربری رو دریافت میکنه.
حالا Flight شامل چه نوع اطلاعاتی میشه؟
توی این پروتکل، دادههایی جابهجا میشن که شامل نوع کامپوننتها، پراپها، مرز بین کد سمت سرور و کلاینت و همینطور ارجاع به ماژولهایی هستن که باید توی کلاینت بارگذاری بشن.
توی سمت دریافتکننده، ریاکت این دادهها رو parse میکنه، ارجاعها رو resolve میکنه و اگه لازم باشه بعضی بخشها رو به شکل lazy لود میکنه.
️ چرا این تغییر سطح حملهی جدید درست میکنه؟
توی مهندسی نرمافزار یک قانون ساده وجود داره:
هرچی داده به لایهی اجرا نزدیکتر باشه، ریسک امنیتی هم بالاتر میره.
اینجا دادهای که از بیرون وارد سیستم میشه، مستقیم وارد مسیری شامل parse، resolve و تصمیمگیری اجرایی میشه.
اگه توی هرکدوم از این مرحلهها اعتبارسنجی یا محدودسازی درست انجام نشه، یک سطح حملهی جدید شکل میگیره.
چرا چنین ریسکی توی SSR وجود نداشت؟
توی معماری SSR، چیزی که به مرورگر فرستاده میشه صرفاً HTMLه.
این فرمت نه زبان اجرایی حساب میشه، نه ارجاع ماژولی داره و نه منطق پویا رو منتقل میکنه.
به همین خاطر، پردازشش توی مرورگرها بهینه و ایزوله شده و سطح تعاملش با منطق اجرایی برنامه خیلی محدوده.
در مقابل، Flight یک پروتکل جدیده، پیچیدهست و خیلی به لایهی اجرای برنامه نزدیکه و همین نزدیکی، دلیل اصلی بالا رفتن ریسک امنیتی محسوب میشه.
جمعبندی نهایی
این اتفاق بیشتر یادآوری میکنه که هر معماریای که داده رو به اجرای مستقیم نزدیکتر میکنه، ناچار هزینهی امنیتی بیشتری هم میده.
ریاکت برای رسیدن به عملکرد بهتر، کم کردن حجم جاوااسکریپت و حرکت به سمت معماری server-first مجبور شد Flight رو معرفی کنه و همین انتخاب، دلیل تفاوت این آسیبپذیری با معماری SSR شد.
@ | <Ali Noori/>
تو روزهای اخیر یک آسیبپذیری جدی توی ریاکت مطرح شد که به کامپوننتهای سمت سرور مربوط بود.
این اسیب پذیری لزوما مربوط به ورژن نبود. چون به فرض اگر نکست بالای ۱۴ بودیم اما کماکان page router استفاده میکردیم هیچ خطری وجود نداشت
خب حالا app router با page router چه تفاوتی دارن؟
جواب این سؤال توی تفاوت عمیق معماری SSR و RSC قرار داره.
معماری SSR دقیقاً چه کاری انجام میده؟
تو این مدل، ریاکت روی سرور اجرا میشه و خروجی نهایی به شکل HTML کامل ساخته میشه و برای مرورگر فرستاده میشه.
بعد از اون، کد جاوااسکریپت توی مرورگر دانلود میشه و فرآیند هیدریشن انجام میشه.
نکتهی مهم اینجاست که HTML فقط یک خروجی نهایی و ایستاست.
این خروجی نه ساختار کامپوننتها رو نگه میداره، نه منطق اجرا رو منتقل میکنه و نه مرزی بین کد سمت سرور و کلاینت مشخص میکنه.
به همین خاطر، سطح حمله توی این معماری معمولاً محدود میشه به چیزهایی مثل XSS یا template injection و خود ریاکت توی سمت کلاینت نقش فعالی توی تفسیر دادههای ورودی نداره.
معماری RSC چه چیزی رو عوض کرد؟
توی معماری RSC، کامپوننتها واقعاً روی سرور اجرا میشن و نتیجهی اجرای اونها بهجای HTML، به شکل ساختار درختی ریاکت به سمت کلاینت میره.
این انتقال با استفاده از یک پروتکل اختصاصی به اسم React Flight انجام میشه.
به زبان سادهتر، مرورگر دیگه فقط یک خروجی آماده تحویل نمیگیره، بلکه اطلاعات لازم برای ساخت رابط کاربری رو دریافت میکنه.
حالا Flight شامل چه نوع اطلاعاتی میشه؟
توی این پروتکل، دادههایی جابهجا میشن که شامل نوع کامپوننتها، پراپها، مرز بین کد سمت سرور و کلاینت و همینطور ارجاع به ماژولهایی هستن که باید توی کلاینت بارگذاری بشن.
توی سمت دریافتکننده، ریاکت این دادهها رو parse میکنه، ارجاعها رو resolve میکنه و اگه لازم باشه بعضی بخشها رو به شکل lazy لود میکنه.
️ چرا این تغییر سطح حملهی جدید درست میکنه؟
توی مهندسی نرمافزار یک قانون ساده وجود داره:
هرچی داده به لایهی اجرا نزدیکتر باشه، ریسک امنیتی هم بالاتر میره.
اینجا دادهای که از بیرون وارد سیستم میشه، مستقیم وارد مسیری شامل parse، resolve و تصمیمگیری اجرایی میشه.
اگه توی هرکدوم از این مرحلهها اعتبارسنجی یا محدودسازی درست انجام نشه، یک سطح حملهی جدید شکل میگیره.
چرا چنین ریسکی توی SSR وجود نداشت؟
توی معماری SSR، چیزی که به مرورگر فرستاده میشه صرفاً HTMLه.
این فرمت نه زبان اجرایی حساب میشه، نه ارجاع ماژولی داره و نه منطق پویا رو منتقل میکنه.
به همین خاطر، پردازشش توی مرورگرها بهینه و ایزوله شده و سطح تعاملش با منطق اجرایی برنامه خیلی محدوده.
در مقابل، Flight یک پروتکل جدیده، پیچیدهست و خیلی به لایهی اجرای برنامه نزدیکه و همین نزدیکی، دلیل اصلی بالا رفتن ریسک امنیتی محسوب میشه.
جمعبندی نهایی
این اتفاق بیشتر یادآوری میکنه که هر معماریای که داده رو به اجرای مستقیم نزدیکتر میکنه، ناچار هزینهی امنیتی بیشتری هم میده.
ریاکت برای رسیدن به عملکرد بهتر، کم کردن حجم جاوااسکریپت و حرکت به سمت معماری server-first مجبور شد Flight رو معرفی کنه و همین انتخاب، دلیل تفاوت این آسیبپذیری با معماری SSR شد.
@ | <Ali Noori/>