تست عکس فوری

تست های عکس فوری هر زمان که می خواهید اطمینان حاصل کنید که UI شما به طور غیر منتظره تغییر نمی کند ، ابزاری بسیار مفید است.

یک مورد تست عکس فوری معمولی یک مؤلفه UI را ارائه می دهد ، یک عکس فوری می گیرد ، سپس آن را با یک فایل عکس فوری مرجع که در کنار آزمون ذخیره می شود ، مقایسه می کند. اگر دو عکس فوری مطابقت نداشته باشند ، این آزمایش شکست خواهد خورد: یا تغییر غیر منتظره است ، یا عکس فوری مرجع باید به نسخه جدید مؤلفه UI بروز شود.

تست عکس فوری با شوخی

در مورد آزمایش اجزای React شما می توان از یک رویکرد مشابه استفاده کرد. به جای ارائه UI گرافیکی ، که به ساخت کل برنامه نیاز دارد ، می توانید از یک رندر تست استفاده کنید تا به سرعت یک مقدار سریال قابل استفاده برای درخت React خود ایجاد کنید. این آزمون مثال را برای یک مؤلفه پیوند در نظر بگیرید:

اولین باری که این تست اجرا می شود ، JEST یک فایل عکس فوری ایجاد می کند که به نظر می رسد:

مصنوعات عکس فوری باید در کنار تغییرات کد انجام شود و به عنوان بخشی از فرآیند بررسی کد شما بررسی شود. JEST از فرمت بسیار با فرمت استفاده می کند تا عکسهای فوری را در هنگام بررسی کد قابل خواندن باشد. در اجرای آزمایش های بعدی ، JEST خروجی ارائه شده را با عکس فوری قبلی مقایسه می کند. اگر مطابقت داشته باشند ، آزمون می گذرد. اگر آنها مطابقت نداشته باشند ، یا دونده آزمون اشکالی در کد شما پیدا کرده است (در این مورد در این مورد) که باید برطرف شود ، یا اجرای آن تغییر کرده است و عکس فوری باید به روز شود.

عکس فوری به طور مستقیم به داده هایی که ارائه می دهید - در مثال ما مؤلفه با صفحه Prop منتقل شده به آن است. این بدان معنی است که حتی اگر هر پرونده دیگری در این مؤلفه غرفه هایی را از دست داده باشد (مثلاً App. Js) ، هنوز هم آزمون را پشت سر می گذارد زیرا آزمایش از استفاده از مؤلفه نمی داند و فقط به Link. js منتقل می شود. همچنین ، ارائه همان مؤلفه با غرفه های مختلف در سایر تست های عکس فوری بر اولی تأثیر نمی گذارد ، زیرا آزمایشات در مورد یکدیگر نمی دانند.

اطلاعات بیشتر در مورد چگونگی کار تست عکس فوری و اینکه چرا ما آن را ساخته ایم می توان در پست وبلاگ انتشار یافت. توصیه می کنیم این پست وبلاگ را بخوانید تا حس خوبی داشته باشید که چه زمانی باید از آزمایش عکس فوری استفاده کنید. ما همچنین توصیه می کنیم این فیلم Egghead را در تست عکس فوری با JEST مشاهده کنید.

به روزرسانی عکس های فوری

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

اگر ما عمداً آدرس را تغییر دهیم ، مؤلفه پیوند در مثال ما به آن اشاره می کند.

در این حالت ، JEST این خروجی را چاپ می کند:

از آنجا که ما فقط مؤلفه خود را به روز کردیم تا به یک آدرس متفاوت اشاره کنیم ، منطقی است که انتظار داشته باشیم در عکس فوری برای این مؤلفه تغییر کنیم. مورد تست عکس فوری ما ناکام است زیرا عکس فوری برای مؤلفه به روز شده ما دیگر با مصنوعات عکس فوری برای این مورد تست مطابقت ندارد.

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

پیش بروید و با اجرای دستور فوق تغییرات را بپذیرید. همچنین ممکن است در صورت تمایل از پرچم معادل تک کاراکتری-U استفاده کنید تا دوباره عکس های فوری ایجاد کنید. این امر باعث ایجاد دوباره مصنوعات عکس فوری برای همه تست های عکس فوری می شود. اگر به دلیل اشکال غیر عمدی ، آزمایش های عکس فوری اضافی را انجام ندادیم ، قبل از ایجاد مجدد عکس های فوری ، باید اشکال را برطرف کنیم تا از ضبط عکس های فوری از رفتار حشره دار جلوگیری کنیم.

اگر می خواهید محدود شود که موارد آزمایش عکس فوری دوباره ایجاد می شود ، می توانید یک پرچم اضافی-testnamepatte را منتقل کنید تا عکس های فوری را دوباره ضبط کنید و فقط برای تست هایی که با این الگوی مطابقت دارند.

می توانید با کلون کردن مثال عکس فوری ، اصلاح مؤلفه پیوند و اجرای JEST ، این عملکرد را امتحان کنید.

حالت عکس فوری تعاملی

عکسهای فوری ناموفق نیز می توانند به صورت تعاملی در حالت ساعت به روز شوند:

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

از اینجا می توانید آن عکس فوری را به روز کنید یا به حالت بعدی بروید:

پس از اتمام ، شوخی قبل از بازگشت به حالت ساعت ، خلاصه ای را به شما می دهد:

عکسهای فوری درون خطی

عکس های درون خطی به طور یکسان با عکسهای فوری خارجی رفتار می کنند (پرونده های SNAP) ، به جز مقادیر عکس فوری به طور خودکار به کد منبع نوشته می شوند. این بدان معناست که می توانید بدون نیاز به تغییر به یک فایل خارجی ، مزایای عکسهای فوری تولید شده را دریافت کنید تا مطمئن شوید که مقدار صحیح نوشته شده است.

مثال:

ابتدا ، شما یک تست می نویسید ، با تماس . tomatchinlinesnapshot () بدون استدلال تماس می گیرید:

دفعه بعد که شوخی می کنید ، درخت ارزیابی می شود و عکس فوری به عنوان استدلال برای tomatchinlinesnapshot نوشته می شود:

این همان چیزی است که در آن وجود دارد! حتی می توانید عکسهای فوری را ب ا-به روزرسانی های updatesnapshot یا با استفاده از حالت u i n-watch به روز کنید.

به طور پیش فرض ، JEST نوشتن عکس های فوری را به کد منبع شما می رساند. با این حال ، اگر در پروژه خود از زیباتر استفاده می کنید ، JEST این کار را تشخیص می دهد و به جای آن کار را به زیباتر (از جمله احترام به پیکربندی خود) واگذار می کند.

تطابق ملک

غالباً زمینه هایی در شیء وجود دارد که می خواهید عکس فوری تولید کنید (مانند شناسه و تاریخ). اگر سعی کنید این اشیاء را عکس بگیرید ، آنها عکس فوری را وادار می کنند که در هر اجرا شکست بخورند:

برای این موارد ، JEST اجازه می دهد تا یک تطابق نامتقارن برای هر خاصیتی فراهم کند. این تطبیق ها قبل از نوشتن یا آزمایش عکس فوری بررسی می شوند و سپس به جای مقدار دریافت شده در پرونده عکس فوری ذخیره می شوند:

هر مقدار معین که یک تطابق نباشد دقیقاً بررسی می شود و در عکس فوری ذخیره می شود:

اگر این پرونده مربوط به یک رشته نیست نه یک شی ، پس از آزمایش عکس فوری باید قسمت تصادفی آن رشته را به تنهایی جایگزین کنید. می توانید برای آن به عنوان مثال استفاده کنیدعبارات () و عبارات منظم را جایگزین کنید.

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

بهترین روشها

عکس های فوری ابزاری خارق العاده برای شناسایی تغییرات رابط غیر منتظره در برنامه شما است - خواه این رابط یک پاسخ API ، UI ، سیاهههای مربوط یا پیام های خطا باشد. مانند هر استراتژی تست ، بهترین عملكردهایی وجود دارد كه باید از آنها آگاه باشید و دستورالعمل هایی را كه باید دنبال كنید ، برای استفاده مؤثر از آنها استفاده كنید.

1. عکسهای فوری را به عنوان کد رفتار کنید

عکس های فوری انجام داده و آنها را به عنوان بخشی از روند بررسی منظم کد خود مرور کنید. این به معنای درمان عکس های فوری است که می خواهید هر نوع آزمایش یا کد دیگری در پروژه خود داشته باشید.

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

همانطور که قبلاً ذکر شد ، JEST از فرمت بسیار با فرمت برای تهیه عکس های فوری انسانی استفاده می کند ، اما ممکن است شما برای معرفی ابزارهای اضافی مانند Eslint-Plugin-Jest با گزینه بدون اسناپوت های خود یا Snapshot-Diff مفید باشد. ویژگی مقایسه ، برای ارتقاء ادعاهای کوتاه و متمرکز.

هدف این است که بررسی عکس های فوری را در درخواست های کشش آسان کنید و در برابر عادت به بازسازی عکس های فوری در هنگام عدم موفقیت سوئیت ها به جای بررسی علل اصلی عدم موفقیت آنها ، مبارزه کنید.

2. آزمایشات باید قطعی باشد

آزمایشات شما باید قطعی باشد. اجرای همان تست ها چندین بار بر روی یک مؤلفه که تغییر نکرده است باید هر بار نتایج مشابهی را به دست آورد. شما مسئول اطمینان از عکس های تولید شده خود هستید که شامل داده های خاص یا سایر داده های غیر قطعی نیست.

به عنوان مثال ، اگر یک مؤلفه ساعت دارید که از Date. Now () استفاده می کند ، عکس فوری تولید شده از این مؤلفه هر بار که مورد آزمایش انجام می شود متفاوت خواهد بود. در این حالت ما می توانیم تاریخ را مسخره کنیم. now () برای بازگشت یک مقدار ثابت هر بار که آزمون اجرا می شود:

اکنون ، هر بار که پرونده تست عکس فوری اجرا می شود ، Date. Now () به طور مداوم 1482363367071 باز می گردد. این امر باعث می شود که همان عکس فوری برای این مؤلفه بدون در نظر گرفتن زمان اجرای آزمون ایجاد شود.

3. از نامهای عکس فوری توصیفی استفاده کنید

همیشه تلاش کنید تا از تست های توصیفی و/یا نام عکس فوری برای عکس های فوری استفاده کنید. بهترین نام ها محتوای عکس فوری مورد انتظار را توصیف می کنند. این امر باعث می شود تا داوران بتوانند عکس های فوری را در حین بررسی تأیید کنند و برای هر کسی که بداند عکس فوری منسوخ شده قبل از به روزرسانی رفتار صحیح است یا خیر.

به عنوان مثال ، مقایسه کنید:

از آنجا که دومی دقیقاً آنچه را که در خروجی انتظار می رود ، توصیف می کند ، روشن تر است که چه موقع اشتباه است:

سوالات متداول

آیا عکسهای فوری به طور خودکار در سیستم های ادغام مداوم (CI) نوشته شده اند؟

نه ، از نظر JEST 20 ، عکسهای فوری در شوخی به طور خودکار هنگام اجرای JEST در یک سیستم CI بدون عبور صری ح-به روزرسان ی-به روز می شوند. انتظار می رود که تمام عکسهای فوری بخشی از کدهایی باشند که روی CI اجرا می شوند و از آنجا که عکسهای فوری جدید به طور خودکار عبور می کنند ، نباید یک آزمایش را بر روی سیستم CI بگذرانند. توصیه می شود همیشه همه عکسهای فوری را مرتکب شده و آنها را در کنترل نسخه نگه دارید.

آیا باید پرونده های عکس فوری انجام شود؟

بله ، تمام پرونده های عکس فوری باید در کنار ماژول هایی که آنها را پوشش می دهند و تست های آنها انجام شود. آنها باید بخشی از یک آزمون در نظر گرفته شوند ، مشابه ارزش هر ادعای دیگر در شوخی. در حقیقت ، عکسهای فوری نشان دهنده وضعیت ماژول های منبع در هر مقطع زمانی معین است. به این ترتیب ، هنگامی که ماژول های منبع اصلاح می شوند ، شوخی می تواند بگوید چه چیزی از نسخه قبلی تغییر کرده است. همچنین می تواند زمینه اضافی زیادی را در هنگام بررسی کد فراهم کند که در آن داوران می توانند تغییرات شما را بهتر مطالعه کنند.

آیا آزمایش عکس فوری فقط با اجزای React کار می کند؟

React و React مؤلفه های بومی مورد استفاده خوبی برای آزمایش عکس فوری هستند. با این حال ، عکسهای فوری می توانند هر مقدار قابل سریال را ضبط کنند و باید در هر زمان مورد استفاده قرار گیرد ، هدف از آزمایش صحیح است. مخزن JEST شامل نمونه های بسیاری از آزمایش خروجی خود JEST ، خروجی کتابخانه ادعای JEST و همچنین پیام های ورود به سیستم از قسمت های مختلف GEST Codebase است. نمونه ای از خروجی Snapshotting CLI را در Jest repo مشاهده کنید.

تفاوت بین آزمایش عکس فوری و آزمایش رگرسیون بصری چیست؟

آزمایش عکس فوری و آزمایش رگرسیون بصری دو روش مجزا برای آزمایش UIS است و آنها به اهداف مختلفی خدمت می کنند. ابزارهای تست رگرسیون بصری تصاویر صفحات وب را می گیرند و تصاویر حاصل از پیکسل را با پیکسل مقایسه می کنند. با مقادیر آزمایش عکس فوری ، سریال شده ، در پرونده های متنی ذخیره می شوند و با استفاده از یک الگوریتم متفاوت مقایسه می شوند. معاملات مختلفی برای در نظر گرفتن وجود دارد و ما دلایل ایجاد آزمایش عکس فوری در وبلاگ JEST را ذکر کردیم.

آیا تست عکس فوری جایگزین تست واحد می شود؟

آزمایش عکس فوری تنها یکی از بیش از 20 ادعا است که با شوخی ارسال می شود. هدف از آزمایش عکس فوری جایگزینی تست های واحد موجود نیست ، بلکه ارائه ارزش اضافی و آزمایش بدون درد است. در برخی از سناریوها ، آزمایش عکس فوری به طور بالقوه می تواند نیاز به آزمایش واحد را برای مجموعه خاصی از عملکردها (به عنوان مثال مؤلفه های React) حذف کند ، اما آنها نیز می توانند با هم کار کنند.

عملکرد تست عکس فوری در مورد سرعت و اندازه پرونده های تولید شده چیست؟

JEST با عملکرد در ذهن بازنویسی شده است ، و آزمایش عکس فوری نیز از این قاعده مستثنی نیست. از آنجا که عکسهای فوری در پرونده های متنی ذخیره می شوند ، این روش آزمایش سریع و قابل اعتماد است. JEST یک فایل جدید برای هر پرونده تست ایجاد می کند که از TomatchsNapShot Matcher استفاده می کند. اندازه عکسهای فوری بسیار اندک است: برای مرجع ، اندازه تمام پرونده های عکس فوری در جعبه کد JEST خود کمتر از 300 کیلوبایت است.

چگونه می توانم درگیری ها را در پرونده های عکس فوری حل کنم؟

فایلهای عکس فوری همیشه باید وضعیت فعلی ماژول هایی را که پوشش می دهند نشان دهند. بنابراین ، اگر در حال ادغام دو شاخه هستید و در پرونده های عکس فوری با یک درگیری روبرو می شوید ، می توانید درگیری را به صورت دستی حل کنید یا با اجرای JEST و بازرسی از نتیجه ، پرونده عکس فوری را به روز کنید.

آیا می توان اصول توسعه آزمایش محور را با آزمایش عکس فوری اعمال کرد؟

اگرچه نوشتن پرونده های عکس فوری به صورت دستی امکان پذیر است ، اما معمولاً قابل دسترسی نیست. عکسهای فوری به این نکته کمک می کنند که آیا خروجی ماژول های تحت پوشش آزمایشات تغییر می کند ، نه اینکه راهنمایی برای طراحی کد در وهله اول ارائه دهد.