هیوادار -

ساختار ارثبری در جنگو

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

باید در نظر داشت که ترتیب اجرای آنها در جنگو به صورت زیر است

اول تمامی کلاسهایی که از django.test.TestCase ارث برده اند اجرا میشوند

سپس تمامی کلاس هایی که از SimpleTestCase و TransactionTestCase و LiveTestCase به ارث برده اند اجرا می شوند.

در نهایت تمامی تستهایی که از unittest.TestCase استفاده کرده اند.

می توان با استفاده از django dumpdata از جداول مدلها دیتای سریالایز شده تولید کرد و توی فایلهای مختلف ذخیره کرد به این فایلها میگن fixture که توی تست نرم افزار هم قابلیت داره. مثلا میخایم قبل از شروع یک TestCase فایلها در fixture کلاس testCase در دیتابیس ذخیره بشه بعد هم پاک شه. که برای شروع هر تست یک دیتابیس جدید setup بشه.

class MyTestCase(TestCase):
    fixtures = ["fixture-label"]

1 2	class MyTestCase(TestCase): fixtures = ["fixture-label"]

سپس

django-admin loaddata &lt;fixture label&gt;

1	django-admin loaddata <fixture label>

جنگو توی فولدر fixtures یا مسیری که توی settings گفتیم FIXTURE_DIR.

class AnimalTestCase(TestCase):
    fixtures = ["mammals", "birds", "insects"]

1 2	class AnimalTestCase(TestCase): fixtures = ["mammals", "birds", "insects"]

unittest و اصول اولیه

در Unit Test مفاهیم زیر اهمیت دارند:

Fixture: قبل از اجرای هر تست یک محیط باید فراهم شه که به این محیط fixture میگن. مثلا قبلا اجرای متدهای unittest شاید لازم باشه یک instance از کلاس مربوطه ساخته بشه و بعد از انجام شدن متد تست اون instance از بین بره. در ضمن ممکنه که قبل از از متد تست این instance نیاز به ساخته شدن داشته باشه. بنابراین این اینستنس رو توی یک تابع به اسم unittest.TestCase.setUp ساخته میشه. این متد قبل از هر متد تست اجرا میشه. به این محیط ایجاد شده قبل از اجرای هر تست Fixture میگن. بعد از اجرای هر تست هم unittest.TestCase.tearDown اجرا میشه که توی اون هم میشه اون اسنتنس رو پاک کرد. مثال دیگه میتونه این باشه که کانکشن به دیتابیس ساخته بشه که توی اون متدهای تست استفاده بشه. در واقع از یه بخشی از کد که توی همه متدها اجرا میشه فاکتور میگیریم.

Test Case: تست کیس اصل کار تست هستش. یک کلاس هست که توی اون متدهایی تعریف میشه که اون متدها هر کدوم یه قابلیت رو تست میکنه. مثلا

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

import unittest

class WidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget('The widget')

    def test_default_widget_size(self):
        self.assertEqual(self.widget.size(), (50,50),
                         'incorrect default size')

    def test_widget_resize(self):
        self.widget.resize(100,150)
        self.assertEqual(self.widget.size(), (100,150),
                         'wrong size after resize')


if __name__ == '__main__':
    unittest.main()

import unittest

class TestStringMethods(unittest.TestCase):

def test_upper(self):

self.assertEqual('foo'.upper(), 'FOO')

def test_isupper(self):

self.assertTrue('FOO'.isupper())

self.assertFalse('Foo'.isupper())

def test_split(self):

s = 'hello world'

self.assertEqual(s.split(), ['hello', 'world'])

# check that s.split fails when the separator is not a string

with self.assertRaises(TypeError):

s.split(2)

import unittest

class WidgetTestCase(unittest.TestCase):

def setUp(self):

self.widget = Widget('The widget')

def test_default_widget_size(self):

self.assertEqual(self.widget.size(), (50,50),

'incorrect default size')

def test_widget_resize(self):

self.widget.resize(100,150)

self.assertEqual(self.widget.size(), (100,150),

'wrong size after resize')

if __name__ == '__main__':

unittest.main()

اگر یک TestCase.setUp به ارور بخوره هیچ تستی انجام نمیشه. اگر تمامی تست ها انجام بشه بعدش TestCase.tearDown اجرا میشه.

قبل از اجرای هر متد تست setUp و tearDown و __init__ اجرا میشه.

Test Suit: بهتره تست های بهم مرتبط رو با هم دسته بندی کنیم و باهم اجرا کنیم. این کارو با Test Suit انجام میدیم.

def suite():
    suite = unittest.TestSuite()
    suite.addTest(WidgetTestCase('test_default_widget_size'))
    suite.addTest(WidgetTestCase('test_widget_resize'))
    return suite

if __name__ == '__main__':
    runner = unittest.TextTestRunner()
    runner.run(suite())

def suite():

suite = unittest.TestSuite()

suite.addTest(WidgetTestCase('test_default_widget_size'))

suite.addTest(WidgetTestCase('test_widget_resize'))

return suite

if __name__ == '__main__':

runner = unittest.TextTestRunner()

runner.run(suite())

ترتیب اجرا fixture ها به صورت زیره:

# testcase fixtures:

TestCase.setUp  # (before any testcase method)
TestCase.tearDown  # (after any testcase method)


# class and module fixtures:

TestCase.setUpClass  # (before first testcase of this class)
TestCase.tearDownClass  # (before first testcase of next TestCase class)

TestCase.setUpModule  # (before first testcase of this Test Module)
TestCase.tearDownModule  # (before first testcase of next Test Module)

# testcase fixtures:

TestCase.setUp # (before any testcase method)

TestCase.tearDown # (after any testcase method)

# class and module fixtures:

TestCase.setUpClass # (before first testcase of this class)

TestCase.tearDownClass # (before first testcase of next TestCase class)

TestCase.setUpModule # (before first testcase of this Test Module)

TestCase.tearDownModule # (before first testcase of next Test Module)

سوال مصاحبه

در ادامه یک سوال مصاحبه جالب از یک شرکت غیرایرانی رو میبینیم که زمان انجامش 45 دقیقه است.

کد زیر را کامل کنید. هدف این است که یک XML به صورت تکست به شما بدهند و شما یک object برگردانید که المانهای این XML در آن قابل فراخوانی باشند همانطور که در تابع main میبینید. (کد به صورت بازگشتی باشد)

if __name__ == "__main__":
    xml_ = "<?xml version='1.0'?><State><City><Name>NewYork</Name></City></State>"
    root = ET.fromstring(xml_)

    r = MyXML(root)
    res = xml_to_obj(root, r)

    city = getattr(r, 'City')
    print(city)
    name = getattr(city, "Name")
    print(name)
    text = getattr(name, "Name")
    print(text)

if __name__ == "__main__":

xml_ = "<?xml version='1.0'?><State><City><Name>NewYork</Name></City></State>"

root = ET.fromstring(xml_)

r = MyXML(root)

res = xml_to_obj(root, r)

city = getattr(r, 'City')

print(city)

name = getattr(city, "Name")

print(name)

text = getattr(name, "Name")

print(text)

سیستم اعتبارسنجی جنگو

دانستن شمای کلی سیستم اعتبارسنجی جنگو authentication system دید خوبی در شروع هر پروژه ای به توسعه دهنده ها میده:

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

راه های بهینه استفاده کردن دیتابیس:

1.توی query هایی که با استفاده از ORM بر روی دیتابیس اجرا میکنیم بهتر است خود SQL آن را ببینیم با استفاده از پرینت کردن query

2.از Indexing در ORM استفاده کنیم

3.وضعیت بهینگی query ها را ببینیم با استفاده از ابزارهایی مثل django-debug-tools

4.مراقب مشکلاتی مثل N+1 problems باشیم

5.از caching استفاده کنیم

6. از قابلیت query laziness در QuerySet های Django نهایت استفاده را بکنیم

7.Query تکراری اجرا نکنیم

8.QuerySet.explain() بهینگی و زمان اجرا query را به من نشان می دهد

9.به حداقل رساندن DB hit با استفاده از prefetch_related و select_related

در لینک زیر مثالهایی از اجرای query اضافی در دیتابیس میبینیم

https://docs.djangoproject.com/en/4.2/topics/db/optimization/

کاربرد nested method در پایتون

کد زیر رو می تونید توی django.forms.fields.py ببینید. یه نکته جالب داره. متد split_url رو توی متد to_python تعریف کرده:

class URLField(CharField):
    widget = URLInput
    default_error_messages = {
        "invalid": _("Enter a valid URL."),
    }
    default_validators = &#91;validators.URLValidator()]

    def __init__(self, **kwargs):
        super().__init__(strip=True, **kwargs)

    def to_python(self, value):
        def split_url(url):
            """
            Return a list of url parts via urlparse.urlsplit(), or raise
            ValidationError for some malformed URLs.
            """
            try:
                return list(urlsplit(url))
            except ValueError:
                # urlparse.urlsplit can raise a ValueError with some
                # misformatted URLs.
                raise ValidationError(self.error_messages&#91;"invalid"], code="invalid")

class URLField(CharField):

widget = URLInput

default_error_messages = {

"invalid": _("Enter a valid URL."),

}

default_validators = [validators.URLValidator()]

def __init__(self, **kwargs):

super().__init__(strip=True, **kwargs)

def to_python(self, value):

def split_url(url):

"""

Return a list of url parts via urlparse.urlsplit(), or raise

ValidationError for some malformed URLs.

"""

try:

return list(urlsplit(url))

except ValueError:

# urlparse.urlsplit can raise a ValueError with some

# misformatted URLs.

raise ValidationError(self.error_messages["invalid"], code="invalid")

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

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

مزایاش که مشخصه، اگه کدی لازم نباشه به scope های دیگه نشون داده نمیشه و مزایای دیگه…

ترتیب اجرای متدهای فیلدها توی django.forms

در مورد صحتسنجی فیلدهایی که هنگام اجرای یک form توی جنگو طی میشه ترتیب زیر طی میشه که هر کدوم از اونها رو میشه overwrite کرد که رفتار form وقتی که دیتا میگیره تغییر بدیم

to_python()
validate() # normally it need to be overwritten
run_validators()

cleaned_data &lt;- clean() # run to_python, validate, run_validators clean_()

access errors -> non_field_errors()
add_error() to attach field to specific field

to_python()

validate() # normally it need to be overwritten

run_validators()

cleaned_data <- clean() # run to_python, validate, run_validators clean_()

access errors -> non_field_errors()

add_error() to attach field to specific field

این توابع رو توی کلاس Field از django.forms میتونید ببینید. لینک زیر بدرد بخوره:

https://docs.djangoproject.com/en/4.2/ref/forms/validation/

رفتار حرفه ای در محیط کار 2

رفتارهای حرفه ای که برای پیشرفت نیاز است:

1.تمامی تایمی که در آفیس حضور دارید مشغول وظایفتان باشید

2.تلاش کنید کارها را با کیفیت خوب و در زمان مقرر تحویل دهید

3.از وقت اداری برای گفتگو با دیگران استفاده نکنید

4.مسائل شخصی و شوخی های بیخودی خودداری کنید

5.در زمان مقرر خارج شوید

6.تلاش به ارتقاء خود داشته باشید

7.با لحن و زبان خیلی خودمانی با همکاران خودداری کنید

8.از به اشتراک گذاری اطلاعات زیاد از حد از زندگی خود خودداری کنید

9.از افراد سمی و حواشی با هر هزینه ای دوری کنید حتی به قیمت ناراحت کردن آنها

10.همیشه مثبت بمانید حتی اگر فضا سمی است. در این صورت حتی بهتر است شرکت را ترک کنید تا اینکه شما هم به شخصی سمی تبدیل شوید.

11.وارد حاشیه های کاری نشوید و سرتان به کار خودتان باشد

لینک 1

لینک 2

F() expression توی جنگو

تفاوت دو کد زیر چیست؟

# Tintin filed a news story!
reporter = Reporters.objects.get(name="Tintin")
reporter.stories_filed += 1
reporter.save()

# Tintin filed a news story!

reporter = Reporters.objects.get(name="Tintin")

reporter.stories_filed += 1

reporter.save()

from django.db.models import F

reporter = Reporters.objects.get(name="Tintin")
reporter.stories_filed = F("stories_filed") + 1
reporter.save()

from django.db.models import F

reporter = Reporters.objects.get(name="Tintin")

reporter.stories_filed = F("stories_filed") + 1

reporter.save()

استفاده از F() expression توی کد جنگوی بالا این امکان رو میده که تغییر فیلد و increment کردنش سمت دیتابیس آماده انجام بشه بجای اینکه پایتون یک واحد بهش اضافه کنه. یعنی یک query میره سمت دیتابیس و مقدار فیلد هرچی هست همونجا یه واحد اضافه میشه. اینجوری دیگه لازم نیست یک بار از دیتابیس بگیره و اضافه کنه و آپدیت شده رو بفرسته سمت دیتابیس و دو query اجرا کنه. اما برای اینکه مقدار آپدیت شده سمت دیتابیس را داشته باشیم:

reporter.refresh_from_db()

1	reporter.refresh_from_db()