✅تست نویسی رو دستکم نگیرید
از کانال per3onal

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

خیلی وقت بود جنگو کد نزده بودم و یک سری موارد رو فراموش کرده بودم (مواردی که مربوط میشه فقط و فقط به خود جنگو)
خیلی هم اعتقادی به TDD ندارم ولی معتقدم تست نویسی باید باشه؛ حالا که بحثش شد بذار بگم تا همین چندسال قبل بدون TDD کد نمیزدم؛ اما یک عیب بزرگ داشتم  TDD فقط و فقط وقتی درست عمل می‌کنه که شما تمام نیاز بیزینس رو بدونی و دقیقا بدونی چطور قراره از سیستم استفاده بشه.
حالا نگیم ۱۰۰٪ حداقل ۸۰٪ پروژه رو باید کامل بدونید؛ باگش در اومد دیگه بیزینسی جز بیزینس خودت وجود نداره که ۸۰٪ اش مشخص باشه. تغییرات بسیار است.

بگذریم؛ کد رو زدم و تموم شد و با Insomnia, bruno تستش کردم (bruno رو هنوز خیلی بلدش نیستم ولی باید یادبگیرم که خب درحال حاضر وقتش نیست برای همین رکوئست‌هایی که مهم نیست رو export-import میزنم بین این دوتا ابزار)
همه چیز به خوبی کار می‌کرد که رفتم سراغ تست نویسی؛ همه تست‌ها به خوبی کار می‌کرد جز یک مورد
یک generic.CreateAPIView یا views.APIView هرکاری میکردم توی یکی از تست‌های خاص جواب نمی‌داد جالبتر این بود که دقیقا همین تست توی Insomnia داشت جواب میداد؛ اونم بطور کامل و درست؛ دیباگر هم حتی هیچی نشون نمیداد.
من توی این Endpoint فقط می‌خواستم یک دیتایی رو دریافت کنم Deserialize کنم بعد با اون چیزی که توی دیتابیس دارم مقایسه کنم که یا تایید بدم یا ارور بدم.

خلاصه‌اش کنم:
نهایتا متوجه شدم روی model و یکی از فیلدها محدودیت unique=True گذاشتم و توی Insomnia دارم اون فیلد رو با دیتای متفاوتی از چیزی که توی دیتابیس ایجاد کردم صدا میزنم همینجا یادآوری شد که :

serializer.is_valid()

قبل از اینکه validate کاستوم شده شما رو اجرا کنه میره چک می‌کنه آیا دیتا رو اگر بخواد validate کنه دیتابیس بهش تایید میده یا نه.
(تابع نرمالایز کردن اون فیلد خاص رو من توی validate مربوط به serializer صدا میزدم؛ چون توی تمام فریمورک‌های استاندارد ولید کردن اول باید توی serializer صورت بگیره و محدودیت‌های دیتابیس Fallback هستند.)

خلاصه که چون توی تست‌هام از faker استفاده می‌کن (اینم خودش یک best practice هست که باید رعایت بشه) توی هر دو endpoint اون فیلد بصورت دقیقا یکسان ارسال می‌شد و باگ در اومد و با یک redesign کوچیک همه جیز درست شد.

اگر این تست نبود:
۱- من باقی بخش‌های پروژه رو با دیزاینی که باگ داشت کد زده بودم
۲- باگ خودش رو نشون نمی‌داد مگر توی stage, production توی محیط تست قطعا بازم با همین استاندارد که بذار normalization رو هم همزمان تست کنم همه چیز ادامه پیدا میکرد.
۳- درست کردن این باگ حتی اگر برای هفته بعدی هم می‌افتاد؛ حداقل ۵-۶ روزکاری زمان می‌برد تا مشکلش رو بتونیم حل کنیم.
بخاطر حجم داده و حجم کد و dependency هایی که بوجود میومد (چیزی که الان کمتر از ۱ ساعت وقت گرفت با یک redesign کامل)


تست نویسی رو دستکم نگیرید واقعا.