مشکل کد من اینجا بود.

تو تیبل student
هم دانش اموز اخراجی داشتیم. که is_expeled بود.

هم نمرات مختلف. ولی سمپل دیتا من تمام حالات رو کاور نکرده.

پس رفتار هایی که ناشی از این دو تا پارامتر به وجود میاد همیشه پاس میشه تو تست من. مثلا ممکنه endpoint لیست دانش آموز من نباید دانش آموز اخراجی برگردونه. ولی چون تو سمپل دیتا من نیست پس تستام پاس میشه.

@ManiFoldsPython

اگه تو برلین هستین این event رو از دست ندید 👀 سباستین و مارسلو (استارلت)‌و samuel calvin (سازنده pydantic و پایتون fellow جدید) و armin ronacher (سازنده فلسک)‌همه اونجان

کاش میتونستم برم :))

https://sentry.io/resources/fastapi-event/

@ManiFoldsPython

سوال:‌ میخواهید schema برای APIتون بنویسید که تمام timestampt هارو UTC کنه با Pydantic و FastAPI که دیگه خیالتون راحت باشه هرچی فرانت فرستاد تاثیری نخواهد داشت.

اگه حتی نمیتونید کدشو بزنید در حد prototype هم کامنت کنید جوابشو. جوابش نهایتا چند خطه.

@ManiFoldsPython

تو کامنت ها جواب رو اشاره کردن

UTCDatetime = Annotated[datetime, AfterValidator(lambda v: v.to_utc())]

class Model(BaseModel):
    remind_at: UTCDatetime

دقیقا نکته همینجاست.
PARSE DON'T VALIDATE

به جای اینکه بیایم از validator پایندانتیک همه جا کپی پیست بگیریم بذاریم, یک تایپی میسازیم که خود پایندانتیک برامون کلین کنه. حالا سوال اینجاست, که اگه خواستیم بیشتر کاستومایز کنیم چی؟ دقیقا تو عکس گذاشتم که چطور میشه.

یعنی شما میتونید کاملا ولیدتور کاستوم برای هر تایپی بنویسیم و بعد اون تایپ رو استفاده کنید. نکته مهم سعی کنید حتما تو داکیومنت pydantic core رو یکم بخونید و یکم ازش سر دربیارید. مثلا هندلر های مختلف داره که خودش تایپو براتون هندل میکنه. مثلا اگه string بدید تاریخو خودش datetime میکنه اگه بشه. خودتون هم میتونید هندلر بنویسید کاری نداره. هر اروری raise کنید خود پایندانتیک هندلش میکنه ولی بهتره از ارور خود ValueError پایندانتیک یا built in python استفاده کنید.

اگه مجیک متود پایندانتیک core schema رو تعریف نکنید اونوقت تایپتون میشه Arbitrary و فقط با ‍isintance چکش میکنه.

@ManiFoldsPython

البته اضافه کنم

۱. از gpt برای کمک به خودتون استفاده نکنید خیلی. چون جلوی خلاقیتتون رو میگیره. برای code review یا کدی که قراره میدونید دقیقا چطوری بشه و ۱۰۰درصد بلدین و صرفا واسه صرفه جویی وقته استفاده کنید.
۲. برای سلف استادی خیلی خوبه. که مثلا ریسورس های خوبو سریع پیداش کنید. یعنی ریسورس هایی که تو حالت عادی شاید رسیدن بهشون یکم سخت باشه. مثلا میخواین راجب <فلان چیز خاص> تحقیق کنید. ازش بخواین کتاب بهتون معرفی کنه راجب همون تایتل و همون سرفصلا و خیلی عالی انجام میده. یا مقدمه بهتون بگه.
۳. مطالبی که میگه چشم بسته قبول نکنید. مثلا اینجا code review ای که کرد خیلی جنرال بود. شاید خیلی از پوینتاش valid نبود برای یک کدی که قرار نیست maintain شه خیلی. یعنی نظرش خیلی تک بعدیه.

@ManiFoldsPython

تو ریپو student fastapi app هم تست نویسیم تموم شد. کلا تموم شد همه بخشاش به جز delete که تصمیم گرفتم ننویسم 😂 جاخالی باشه برای کسی که fork خواست کنه.

دو نکته مهم راجب تست نویسی:

اولا که وقتی unit test مینویسید در لحظه باید یک unit رو تست کنید نه بیشتر. که اگه fail شد بدونید کدوم unit فیل شده. به جای اینکه خیلی رو خوانایی تستتون کار کنید رو text ای که برای assertion گذاشتید کار کنید. که اگه fail شد بدونید چرا این اتفاق افتاده

دوما که اصلا و اصلا و ابدا ‍تست کاوریج مهم نیست!! تاکید میکنم تست کاوریج فقط برای لایبری اوپن سورس مهمه! احمقانه ترین measure برای تست نویسی اینه که شما تست کاوریج رو بسنجید.

ریپو تست ACL منو ببینید
ACL Tests

اخرین assertion فیل شد. من دیباگش کردم. باگش این بود که من چک نمیکردم یک معلم وقتی داره دیتا یک دانش آموز دیگه رو میگیره ایا اون دانش آموز تو کلاسشه یا نه. یعنی من یک کدی ننوشته بودم! چیزی که شما با تست کاوریج متوجه نمیشید.

در نهایت به جای اینکه بیام هر روتر رو تست کنم که پرمیشنش مطابق تسک عمل میکنه اومدم اول permission هارو تست کردم, بعد رفتار روتر رو. وقتی رفتار روتر رو تست کردم خود پرمیشن رو ماک کردم که کلا به من برای همه اندپوینت ها همیشه دسترسی بده!! چرا؟‌چون وقتی دارم روتر رو تست میکنم فقط و فقط و فقط باید روتر رو تست کنم نه چیز دیگه ای رو.

@ManiFoldsPython

نهایتا خوشحال میشم یک سر به سورس کد بزنید و ببینید که چطور شد؟

اگه خواستین code review کنید. اگه کسی هم تسکشو بفرسته حتما من سره وقت review میکنم براش.

https://github.com/ManiMozaffar/fast-student

@ManiFoldsPython

ویدیو خوبی بود. شیر میکنم شاید بدردتون خورد

https://www.youtube.com/watch?v=-EQ5-5wpaec

@ManiFoldsPython

دو falsehoold تست نویسی

۱. چون unit test من پاس شده پس software requirement من satisfy شده و محصول من کار میکنه
۲. تست کاوریج بالا و داشتن assertion زیاد یعنی من تست هام خیلی خوبه و باگ برنامم بسیار کمه

وقتی میگم تست باید رفتار محصول و software requirement رو تست کنه یعنی چی؟ برای یک لاگین بیایم یک software requirement بنویسیم برای لاگین:

User shall be required to change his/her password every 3 months
Login response time on backend shall be time contrainst of 1 second to avoid timing attacks
Login response shall be with respect to Auth0, handled by JWT in cookie with CSRF in header, to be considered as safe
User shall not attempt to unsuccessfull login more than 20 times with an IP Address
User shall be redirected to dashboard after a successfull login
User shall be asked for username and password, to match credential in database, to perform a a successfull login
User shall not be aware of the spefiec reason behind unsuccessfull login, such as "Wrong Password" or "Wrong Email"
Optionally, the user may enable two-factor authentication for added security. This could include SMS, authenticator apps, or hardware tokens.
After a specified number of unsuccessful login attempts, the user's account shall be temporarily locked to prevent brute force attacks. An unlock process must be provided, often through email verification
For avoiding automated login attempts, a CAPTCHA could be implemented, especially after a few failed login attempts.
Optionally, users can choose to be remembered on a specific device/browser, so they don’t have to log in every time


دیدین؟‌حالا باید برای تک تک این موارد بشینید تست بنویسید. که اکثرا e2e test هستند. چرا؟‌چون api throttling که معمولا از gateway میاد و یا ایمیل ارسال میشه و یا فرانت و بک اند همزمان باهم درگیرن. پس میشه گفت ۶-۷ تا unit دارن باهم کار میکنن تا این software requiremenet رعایت شه. وقتی میگم دیتا سمپل باید خوب باشه همینجا خودشو نشون میده. همونطور که فهمیدین باید اکانتی تو دیتابیس تست باشه که ۳ ماه از اخرین باری که رمز رو تغییر داده باشه گذشته باشه که بتونه اون popup مربوط به تغییر پسوورد رو ببینه تو فرانت و بک اند. میتونه بعد از این تستا code coverage ما ۷۰ درصد باشه میتونه هم ۱۰۰ درصد باشه اصلا برامون مهم نیست!‌مهم اینه که کارایی که یوزر میخواسته بکنه موقع لاگین رو پلتفورم رو همگی تست کردیم حتی اگه یک روتر اصلا تست نداشته باشه. همونطور که میتونه تست کاوریج ۱۰۰ باشه و هیچکدوم از اینا تست نشده باشه.

در آخر اشتباه برداشت نکنید, یونیت تست برای ‍smoke testing خیلی عالیه. e2e تست پیچیدگی زیادی داره و دلیل نمیشه قید unit test رو بزنید چون e2e دارین.


وقتی این موارد رو رعایت نمیکنید انتظار یک پروداکت خیلی stable نباید داشته باشین. البته که پایبند بودن به همه اینا سخته و زمانبر ولی تو case و پروداکت خودتون باید بسنجید آیا برای من سودی داره که پروداکتم بسیار stable و کم باگ و خطا باشه؟


@ManiFoldsPython

#RECAP
پستی که قبلا گذاشتم دوباره میذارم:

تست ها دو وضعیت دارن:

یا stateful هستند. یعنی state چیزهایی که دارید تست میکنید قبل و بعد از تست فرق میکنه. مثلا فکر کنید دیتابیس رو ماک نگرفتین و تست بک اند رو یک دور ران کردید رو خود پروژه به صورت مستقیم. اینطوری شما دارین دیتایی به اپلیکیشنتون اضافه میکنید که قبلا نبوده. یعنی state اپلیکیشن شما با هر بار ران شدن تست ها فرق میکنه

و یا stateless هستند. یعنی مثلا شما ۱۰۰ بارم که تست رو ران کنی state اپلیکیشن شما فرقی نمیکنه و همونیه که قبلا بوده.


و تو چند تا کتگوری مختلف هستند که ۴ تاشو اینجا معرفی میکنم:

۱. یونیت تست: به تستی گفته میشه که داره یک یونیت رو تست میکنه. اگه یونیت دیگه ای باشه اون یونیت می بایست ماک شه. مثل ردیس و یک API. اگه قراره API یونیت تست شه پس ردیس باید ماک شه. یونیت تست ها معمولا stateless هستند. معمولا تو مرحله توسعه هر یونیت نوشته میشوند. هر یونیت باید ایزوله شود.

۲. اینتگریشن تست:‌درواقع integration بین ۲ یا چند unit تست میشه. اکثر مواقع stateful هستند ولی میتونند stateless هم باشند. معمولا تو مرحله اتصال دو یونیت به هم نوشته می شوند. مثلا تست میکنید که ایا وقتی یک مسیج produce میکنید تو کافکا ایا کانسومر ران میشه و تسکشو اجرا میکنه؟‌به این میگن integration test.

۳. تست اند تو اند (e2e):‌ کل سیستم تست میشه. اکثر اوقات (خیلی کم پیش میاد اینطور نباشه) stateful هستند. معمولا از دید کاربر سیستم ‍e2e میشود و در آخرین چرخه توسعه قبل از رفتن رو پروداکشن انجام میشود. همچنین قبل از اولین ریلیز اولین بار شروع به توسعه خود تست میشود. برعکس دو مثال بالا که حین توسعه بودند.

۴. اسموک تست:‌تستی که برای بیلد گرفتن اجرا میشود بهش میگن اسموک تست. معمولا از unit test برای اسموک استفاده میشه. از هر تست stateless دیگه ای هم میشه استفاده کرد برای اسموک تست. حواستون باشه نباید از stateful برای اسموک استفاده کرد چون ممکنه به اشتباه تست fail شود (بخاطر تغییر state) و بیلد الکی ریجکت شود. ولی بازم ممکنه یک جاهایی استفاده از تست stateful برای اسموک هم منطقی باشه. ولی تو حالت عادی باید از این کار جلوگیری کرد.

@ManiFoldsPython

سلام 👋👋

مطالب مهمی که تو کانال گفتم, مواردی که کمتر بهش پرداخته میشه تو کامینیتی پایتون ایران, رو نوشن کردم تو این کانال

لینک نوشن

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

در آینده پست هایی که تو کانال هم میره بعضا وارد این نوشن میشه.

اگه براتون notion درست نمایش داده نمیشه(راست چین نیست) میتونید از یکی از دو extension زیر استفاده کنید:

Notion-Enhancer

NotionRTL

@ManiFoldsPython

میتونید کامنت هم بذارین و سوال بپرسید 🙂 برای اینکار باید لاگین باشید فکر کنم.

خب خب
بریم سراغ راهنمایی اول
من پروژه رو خودم تکمیل کردم و در لینک زیر قرار دادم
https://github.com/amirbahador-hub/python_tutorial
کاری که شما باید بکنید اینه که fork بگیرین و بهبودش بدین
الان دیگ خیلی راحت تره دیگ , یه کدی دارین که داره کار می‌کنه
فرض کنید سنیور شرکت هستین و اینو یه جونیور بهتون pull request داده

همانطور که گفتم باید سعیتون این باشه که با کمترین راهنمایی به جواب برسین

@BenDevelop

تو پروژه student app رضا جان PR زد یک نکته خیلی تمیز پیدا کرد!

در صورتی که من شروطمو اسم گذاری کرده بودم که باعث خوانا تر شدن کد میشد رضا از Walrus Operator استفاده کرد که همینکارو تو یک خط انجام بده و حجم کد بیشتر نشه 👌

یک نکته

اگه برید تو ریپو کل پوشه ACL و پیاده سازیش یک کلس هم نداره! یک نفر از دوستام همین کارو کرده بود ولی برای هر user role اومده بود یک کلس ساخته بود که نتیجش این شده بود که همیشه نیاز به کلس داشت برای اضافه کردن یک role جدید و نمیتونست از فانکشن هایی که نوشته re-use کنه.


همیشه استفاده از دیزاین پترن های OOP همه چیزو پیچیده میکنه. منتهی باید بدونید کجا استفاده کنید که کدتون رو خوانا تر کنه (مثلا اگه ۱۰۰ تا فانکشن داشتم اون موقع قطعا باید function هامو decouple میکردم یا تو چند تا کلس اونا رو میشکوندم که رفتاری رو پیاده سازی میکردن.

@ManiFoldsPython

SOA vs Microservices

@ManiFoldsPython

یک اشتباهی که تو این تیبل وجود داره اینه که نوشته containerization تو SOA محبوب نیست در صورتی که عکس این موضوعه
تو microservice هم اشاره به grpc نشده

@ManiFoldsPython

دو ریسورس خوب که تو گروه بچه ها به اشتراک گذاشتن

یکی برای درک بیشتر SOA که آمازون توضیح داده. خوبه نسبتا. فقط کاش توضیح ESB رو بیشتر میداد چون یک پارگراف براش تو همچین article ای کم بود.
https://aws.amazon.com/what-is/service-oriented-architecture/

یکی هم شرح DI تو مدرن پایتون و رفع ابهام
https://www.youtube.com/watch?v=qkGxy4c64Jg


گروه دقیقا داره سمت خوبی میره و سوالات خیلی خوبی پرسیده میشه👌
@ManiFoldsPython