تست ها را بنویسید زیاد نیست. بیشتر ادغام.

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

مدتی پیش گیلرمو راخ (خالق
Socket.io و بنیانگذار Zeit.co (
شرکتی پشت بسیاری از چیزهای عالی که اخیراً منتشر شده است))
چیزی عمیق توئیت کرد:

تست ها را بنویسید زیاد نیست. بیشتر ادغام.

این عمیق است، هرچند مختصر، بنابراین بیایید در زیر شیرجه بزنیم:

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

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

من شنیده ام که مدیران و تیم ها 100٪ پوشش کد برای برنامه ها را درخواست می کنند.
این یک ایده واقعا بد است. مشکل همینه بازدهی کاهشی دریافت می کنید
تست های شما با افزایش پوشش بسیار بالای 70٪ (این عدد رو درست کردم…
هیچ علمی وجود ندارد). چرا اینطور است خوب، وقتی شما همیشه 100% را هدف می گیرید، شما
وقت خود را صرف آزمایش چیزهایی کنید که واقعاً نباید آزمایش شوند.
چیزهایی که در واقع هیچ منطقی در آنها وجود ندارد (بنابراین هر گونه خطایی می تواند توسط آن کشف شود
ESLint و Flow). انجام آزمایش‌های این چنینی واقعاً سرعت شما و شما را کاهش می‌دهد
تیم پایین.

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

باید اشاره کنم که تقریبا تمام پروژه های متن باز من 100% کد هستند
پوشش. این به این دلیل است که بیشتر پروژه های منبع باز من کتابخانه های کوچکتری هستند
و ابزارهایی که می توانند در موقعیت های مختلف مورد استفاده مجدد قرار گیرند (شکستن می تواند منجر به
به یک مشکل جدی در پروژه های بسیار وقت گیر) و نسبتا آسان هستند
به هر حال برای دریافت 100٪ پوشش کد.

انواع مختلفی از آزمون ها وجود دارد (به گفتگوی 5 دقیقه ای من مراجعه کنید
در مورد این در Fluent Conf:
“آنچه می توانیم در مورد آزمایش از چرخ بیاموزیم”).
هر کدام دارای معاوضه هایی هستند. ما در مورد سه نوع رایج آزمایش صحبت می کنیم
وقتی در مورد تست خودکار صحبت می کنیم عبارتند از: واحد، ادغام و انتها به انتها.

در اینجا یک اسلاید از من است
کارگاه آموزشی Frontend Masters:
“تست برنامه های جاوا اسکریپت”.

این هرم آزمایشی ترکیبی از هرم است که من از آن گرفتم
وبلاگ مارتین فاولر و یکی
من گرفتم از
وبلاگ تست گوگل

همانطور که در اینجا نشان داده شده است، هرم از پایین به بالا نشان می دهد: واحد، ادغام، E2E.
با بالا رفتن از هرم، نوشتن/اجرای تست‌ها کندتر و گران‌تر می‌شوند
(از نظر زمان و منابع) برای اجرا/نگهداری. این به معنای اشاره به آن است
به دلیل این عوامل باید زمان بیشتری را برای تست های واحد اختصاص دهید.

یک چیزی که نشان نمی دهد، هر چند، این است همانطور که از هرم بالا می روید،
ضریب اطمینان هر نوع آزمایش افزایش می یابد. شما بیشتر برای
پول شما بنابراین در حالی که تست های E2E ممکن است کندتر و گران تر از تست های واحد باشند،
آنها به شما اطمینان بیشتری می دهند که برنامه شما به همین شکل کار می کند
در نظر گرفته شده است.

همانطور که اشاره شد، سازهای ما فراتر از فرضیه اصلی مارتین رفته اند
آزمایش مفهوم هرم به همین دلیل “The Testing Trophy” را ساختم 🏆

فرقی نمی کند جزء شما باشد یک جزء را ارائه می دهد با لوازم
c و d اگر یک جزء در واقع شکستن اگر زیر e تحویل داده نشده است. و همینطوردر حالی که داشتن برخی از تست های واحد برای تایید عملکرد این قطعات به صورت مجزا، الف نیست
چیز بد اگر این کار را نکنید به شما کمکی نمی کند بیش از حد بررسی کنید که آیا آنها
به درستی با هم کار کنند و با آزمایش اینکه آنها با هم کار می کنند متوجه خواهید شد
درست است، شما اغلب نیازی به آزمایش آنها در انزوا ندارید.