لینک کوتاه مطلب : https://hsgar.com/?p=6895

راه‌اندازی HN: DeploySentinel (YC S22) – تست‌های سرتاسری که پوسته پوسته نمی‌شوند

سلام HN، مایکل و وارن در اینجا – بنیانگذاران DeploySentinel (https://deploysentinel.com). ما تست سرتاسری را آسان‌تر و قابل اعتمادتر می‌کنیم.

در آخرین کارم، متوجه شدم که چگونه می‌توان از بسیاری از حوادث تولید و مشتریان ناراضی با اتوماسیون آزمایشی بیشتر جلوگیری کرد – “یک اونس پیشگیری ارزش یک پوند درمان را دارد”. با این حال، مشخص نبود که شما می توانید پیشگیری را فقط برای یک اونس دریافت کنید. تیم‌های ما سرمایه‌گذاری روی تست‌ها، به‌ویژه تست‌های انتها به انتها (از طریق چرخاندن یک مرورگر بدون هد در CI و آزمایش به‌عنوان کاربر نهایی) افزایش دادند، اما به سرعت مشخص شد که ساخت و نگهداری آن‌ها فوق‌العاده گران است، به خصوص مجموعه تست و پیچیدگی برنامه افزایش می یابد. وقتی از تیم‌های مهندسی دیگر از شرکت‌های مختلف پرسیدیم، مرتباً می‌شنیدیم که تعمیر و نگهداری آزمایش چقدر زمان بر است.

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

هر کسی که این داستان را آشنا می‌بیند احتمالاً می‌تواند به روزهایی که برای رفع اشکال مشکلی مانند این سپری کرده است، تأیید کند، احتمالاً در این فرآیند مقداری مو از دست داده و در پایان فقط با حذف آزمایش و به دست آوردن عقل خود، آن را «حل کرده‌اند». برخی از تیم‌ها حتی سعی می‌کنند ابزارهای نظارتی جلویی را برای تولید در فرآیند CI خود قرار دهند، اما متوجه می‌شوند که قادر به انجام ضبط صدها عمل آزمایشی که توسط یک ماشین انجام می‌شود تنها در چند ثانیه نیستند.

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

ما به شما این امکان را می‌دهیم که عکس‌های فوری DOM، رویدادهای شبکه و گزارش‌های کنسول را برای هر مرحله برداشته شده در آزمایش Cypress که در CI اجرا می‌شود، بررسی کنید تا بینش بیشتری در مورد اینکه چرا یک آزمایش خاص ممکن است ناموفق باشد، ارائه دهید. مانند Fullstory/LogRocket است، اما برای خرابی CI به جای اشکالات تولید. (ما با آزمایش های Cypress شروع می کنیم، با برنامه هایی برای گسترش بیشتر.)

ابزار ما از طریق API افزونه آنها با Cypress ادغام می‌شود، بنابراین می‌توانیم آزمایش‌ها را در CI وصل کنیم و فقط با نصب NPM و 2 خط کد، تست‌ها را ثبت کنیم. از آنجا می‌توانیم به رویدادهای Cypress/Mocha متصل شویم تا همه چیزهایی را که در دونده آزمایشی اتفاق می‌افتد (مثلاً زمانی که آزمایش شروع می‌شود، زمانی که یک فرمان اجرا می‌شود، زمانی که یک عنصر پیدا می‌شود، و غیره) ضبط کنیم و همچنین پورت پروتکل دیباگر با مرورگر برای گوش دادن به رویدادهای شبکه و کنسول. در حالی که یک مجموعه آزمایشی در حال اجرا است، دیباگر به طور مداوم آنچه را که در طول اجرای آزمایشی اتفاق می‌افتد جمع‌آوری می‌کند و اطلاعات (منهای رویدادهای سانسور شده پیکربندی شده توسط کاربر) را پس از اتمام هر آزمایش آپلود می‌کند.

در حالی که این ممکن است شبیه وارد کردن LogRocket/FullStory به مجموعه آزمایشی شما باشد، اما در واقع تفاوت‌های زیادی وجود دارد. عملی‌ترین آنها این است که آن ابزارها معمولاً دارای محدودیت نرخ پایینی هستند که برای ترافیک انسانی در تعامل با برنامه‌های وب با سرعت انسانی خوب کار می‌کنند، اما هنگام برخورد با ترافیک دونده آزمایشی موازی که با برنامه وب با سرعت ماشین تعامل دارند، خراب می‌شوند. سایر جزئیات جزئی حول محور ما می چرخد ​​که پخش مجدد را با فراداده آزمایشی به جای ابرداده کاربر مرتبط می کنیم، دسترسی کامل به تمام درخواست های شبکه/پیام های کنسول منتشر شده در آزمایش در سطح مرورگر، و نمایه سازی اطلاعات پخش بر اساس دستورات آزمایشی به جای مهر زمانی (زمان) یک مفهوم غیرقابل اعتماد در آزمایشات است!).

هنگامی که یک آزمایش با شکست مواجه شد، یک نظر Github PR ایجاد می‌شود و یک مهندس می‌تواند فوراً به برنامه وب ما دسترسی پیدا کند تا شروع به اشکال‌زدایی شکست آزمایشی خود کند. از طرف دیگر، آنها می توانند داشبورد وب ما را نیز بررسی کنند. به جای پخش ویدیویی از شکست در حرکت آهسته برای درک موضوع، یک مهندس می‌تواند از طریق دستور به فرمان آزمایشی گام بردارد، DOM را با ابزار بازرسی عنصر مرورگر خود در هر نقطه بررسی کند، ببیند آزمایش با چه عناصری تعامل داشته است. اگر پیام‌های کنسولی در حین کار منتشر شد، یا به هر درخواست شبکه‌ای که همراه با کدهای خطای HTTP یا پیام‌های خطای شبکه مرورگر انجام می‌شود نگاهی بیندازید.

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

ما رویای دنیایی را می بینیم که در آن برنامه ها دارای حداقل اشکال هستند، مشتریان خوشحالی دارند و با تیم های مهندسی ساخته شده اند که آزمایش را یک کار گران قیمت نمی دانند! اگرچه اولین مشکلی که ما به آن می پردازیم تست هایی است که در CI شکست می خورند، ما در حال کار روی یک سری چیزها فراتر از آن هستیم، از جمله دومین مشکل بزرگ در تست: طول زمان اجرای تست.

ما یک نسخه آزمایشی رایگان در اختیار شما قرار داده ایم که می توانید آن را با آزمایش های خود امتحان کنید، به همراه چند نمایش زنده از شکلی که اشکال زدا ما در یک آزمایش نمونه به نظر می رسد. می توانید از اینجا شروع کنید: https://deploysentinel.com/

ما مشتاقانه منتظر شنیدن تجربیات دیگران در مورد آزمایشات پایان به پایان هستیم و نظر شما در مورد کاری که ما انجام می دهیم چیست!

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.