امروز یکسری حالات مختلف از teardown کردن تست‌ها در pytest یاد گرفتم خوب بود هر کدوم کاربرد و جای خودش داره.

به سه حالت مختلف رسیدم. حالت اول زمانی که شما نیاز به یک resource دارید برای تست‌هاتون برای مثال اول لاگین کنید و بعدش ریکوئست بزنید. تو این مواقع بهتر که یک fixture داشته باشید که براتون لاگین کنه و وقتی کارتون تموم شد خودش لاگ اوت کنه.

به اون پروسه لاگ‌اوت کردن میگن teardown یکدونه هم tear up داریم که پروسه لاگین کردن تو این مثاله. مثال دیگش میشه زمانی که نیاز دارید یک رکورد خاص داخل دیتابیس ساخته بشه و بعد از تست حذف بشه. به ساختنش میگن tear up به حذف کردنش میگن tear down.

خب حالا حالت اول که fixture باشه.

import pytest

@pytest.fixture
def client() -> AuthedClient:
    #login and etc
    yeild client
    client.logout()

داخل فیکسچر‌ها pytest هرچیزی که بعد از yield بیارید tear down و هرچی که قبلش بیاد tear up.


حالت دوم شما یک مقدار از درون تست نیاز دارید برای tear down کردن. برای مثال شما یک تست دارید پست زدن داخل توییتر رو تست میکنه. شما برای tear down کردن این تست لازم دارید پست رو پاک کنید اما برای پاک کردنش نیاز به id اون پست دارید. اینجاس که شما یک مقدار لازم دارید که داخل خود تست‌ ساخته شده.
برای این مورد به نظر من بهترین حالت در حال حاضر با دانش الان من استفاده از try-finally هستش.

def test_twt_post_create_success(twt_client):
    post_id = None
    try:
        post = twt_client.post("Hello from test")
        post_id = post.id
    finally:
       if post_id:
             twt_client.remove_post(post_id)

اینجا فیکسچر‌های شما که برای مثال twt_client هست براتون کلاین tear up و tear down میکنن به روش اول. و try-finally پستی که ساختید رو tear down میکنه. مهدی سینیور ما باشد گفت که یک فیکسچر بسازم که داخلش یک yeild خالی باشه و بعد از yeild از داخل یک متغیر گلوبال بیاد ایدی پست ها رو بخونه و همرو حذف کنه که برای این کار لازمه داخل هر تست هر وقت پست ساختیم اضافه اش کنید به اون متغیر که من به نظرم try finally بهتر بود در نتیجه همون زدم فرستادم تک‌لید :)

✍🏻 @TorhamDevCH

خیلی تصادفی این رزومه رو دیدم توی لینکدین ، طرف برداشته رزومه شو در قالب ویندوز xp طراحی کرده، جذاب بود ایده ش :

https://mitchivin.com/

✍🏻 مسعود بیگی

نکته هایی در مورد فایل های استاتیک جنگو - بخش اول

داکیومنت محترم جنگو صراحتا گفته:

توی development (یعنی وقتی Debug=True هست) جنگو خودش فایل های استاتیک رو سرو میکنه.
به شرط اینکه اپ django.contrib.staticfiles توی INSTALLED_APPS باشه.

بعد گفته که STATIC_URL رو اینجوری تعریف کنید (پیش فرض اینه)

STATIC_URL = "static/"

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

دقت کن آخرش یه اسلش هست، اگه آخرش اسلش رو نذاری، این خطارو میده و کلا پروژه ران نمیشه:
The STATIC_URL setting must end with a slash

خب حالا اگه این بخشی از تمپلت ما باشه، باید اول static رو لود کنیم. و بعدش از تمپلت تگ static استفاده کنیم:

{% load static %}

<link rel="stylesheet" type="text/css" href="{% static 'css/style.css' %}">

جای اون static پایینی مسیر قرار میگیره.
مثلا سایتم ali.com باشه میشه:
ali.com/static/css/style.css

اگه اینارو میدونی یه 🥱 بزار

وگرنه هر چی دوس داری بزار 😅

ادامه دارد...

نکته هایی در مورد فایل های استاتیک جنگو - بخش دوم

خب ما STATIC_URL رو مشخص کردیم.
حالا جنگو کجا باید دنبال فایل های استاتیک ما باشه؟

یکی از دوستان، توی کامنت ها نوشته:

من دقیقا همینکارو میکنم لود نمیکنه
باید حتما تو

STATICFILES_DIRS
تعریف کنم تا لود شه

جنگو انتظار داره هر app فایل های استاتیک خودش رو داشته باشه.
مثل اپ ع admin که اونم خودش یه فولدر به اسم static داره. و توی اون فولدر یه فولدر به اسم admin . استاتیک هاش اونجا هستن.

پس اگه اسم اپ ما shop هست. فایل های استاتیک اینجوری میشن:
shop/static/css/style.css

چرا؟
چون توی تمپلت اینجوری نوشته بودم، توی پست قبلی (بخش اول):

href="{% static 'css/style.css' %}"

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

{% load static %}
<img src="{% static 'my_app/example.jpg' %}" alt="My image">

و گفته فولدر ها باید اینجوری باشن، اسم اپ بعد static اومده:
my_app/static/my_app/example.jpg

✔️جنگو اول STATICFILES_DIRS رو میگرده بعد app هارو میگرده، یعنی اگه استایل مشترکی توی این فولدرها باشه، اولویت با STATICFILES_DIRS هست.

احتمالا کاربرد STATICFILES_DIRS رو متوجه شدید؟
بله، برای اینه که اگه فایل استاتیکی داریم که نمیخواهیم توی اپ خاصی باشه (مثلا دلیل مون اینه که مشترک هستن بین همه اپ ها)، پس توی این آرایه میزایمش، مثال جنگو اینه:

STATICFILES_DIRS = [
    BASE_DIR / "static",
    "/var/www/static/",
]

حالا یه نکته مهم:
✔️نباید STATIC_ROOT برابر با یکی از مسیرهای آرایه STATICFILES_DIRS باشه. وگرنه این خطارو میده:
The STATICFILES_DIRS setting should not contain the STATIC_ROOT setting
چرا؟
چون بعدا که میخواهیم دستور collectstatic رو اجرا کنیم، قاطی میکنه دیگه. چون این دستور همه static هارو یکجا جمع میکنه، که بدیم وب سرور serve شون کنه.
پس STATIC_ROOT برای مشخص کردن مسیر همه فایل های استاتیک، هنگام دیپلوی هست. (وقتی میخوایم پروژه رو ببریم روی اینترنت)

مقدار پیش فرض STATIC_ROOT برابر None هست. و اگه بخواهیم collectstatic کنیم باید بهش مقدار بدیم (اسم یا مسیر یه فولدر، اسلش آخرش هم نمیخواد 😁 )

زیاد شد، بقیه بعدا...

یه سوال بپرسم: چه زمانی لازمه اینکارو کنیم؟
urlpatterns = [
# ... the rest of your URLconf goes here ...
] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

اگه همه این نکات رو میدونستی یه 🥱
وگرنه هر چی دلت خواست

اسپانسر این پست 👈 لینک