مانند تست واحد، تست یکپارچه سازی مدرن راهی برای آزمایش تعاملات نرم افزاری پیچیده ارائه می دهد.
شاید سیاره ای با نرم افزار کامل وجود داشته باشد، اما همانطور که کریس دی بونا از Google می نویسد، آن سیاره اونی که ما باهاش زندگی میکنیم به این ترتیب، توسعه دهندگان با یک معاوضه مواجه می شوند: نرم افزار خود را با احتیاط و با دقت آزمایش کنید تا تمام مشکلات پیش از استقرار را بیابید، یا کمتر تست کنید و سریعتر با تحمل بیشتر اشکالات در تولید ارسال کنید. اردوگاه سابق پر از توسعه دهندگانی است که در صنایع تحت نظارت مانند مراقبت های بهداشتی و مالی کار می کنند. دومی توسط طرفداران معروف “شما آن را می سازید، اجرا می کنید” ورنر فوگلز پر شده است. /a> گفته (پی دی اف را در پیوند ببینید).
این مبادله یکی از ظریف ترین بحث های مربوط به بهره وری توسعه دهندگان است.
هرجا که توسعهدهندگان در طیف آزمایشی قرار دارند، راهحلی برای تست نرمافزاری وجود ندارد که توسعهدهندگان را به جستجوی پیوسته ترکیب مناسبی از روشهای آزمایشی متناسب با نیازهای در حال تکامل خود میپردازد. برای پیچیدهتر شدن مسائل، برای تبدیل شدن هر یک از روشهای آزمایشی موجود به عادت، توسعهدهندگان باید نقطه شیرین حل یک نقطه درد اصلی را بیابند و آنقدر کند یا پیچیده نباشند که از آن استفاده نکنند.
As من اخیراً نوشتم، آزمایش واحد آن نقطه شیرین را پیدا کرده است. به عنوان یک تمرین تست نرمافزار، به تیمها اجازه میدهد تا قطعات کوچک و جدا شده از کد را آزمایش کنند، که نه تنها اطمینان میدهد که نرمافزار مطابق با مشخصات مورد نظر خود کار میکند، بلکه به توسعهدهندگان اجازه میدهد تا با قسمتهایی از پایه کد نوشته شده توسط توسعهدهندگان دیگر استدلال کنند. آزمایش واحد دهها سال است که وجود داشته است، اما واقعاً اخیراً ریشهدار شده است زیرا اتوماسیون تجربه کاربر را تا حد قابل استفاده واقعی ساده کرده است.
امروزه شکل دیگری از آزمایش وجود دارد که، مشابه آزمایش واحد، دههها در حال ساخت است، اما تنها اکنون نقطه شیرین خود را در پرداختن به یک مشکل اساسی و ارائه انتزاع مناسب به توسعهدهندگان برای یک رویکرد بسیار ساده یافته مییابد. من در مورد آزمایش یکپارچه سازی صحبت می کنم.
وظیفه یک توسعه دهنده این است که چیزها را به هم بچسباند
در سیستمهای معماری سهلایه مرسوم، توسعهدهندگان ممکن است یک پایگاه داده و شاید یک یا دو API برای تعامل داشته باشند، و این میزان اجزای شخص ثالثی بود که لمس میکردند.
امروزه توسعهدهندگان تمایل دارند راهحلها را به اجزای مختلفی تقسیم کنند—که بیشتر آنها را ننوشتهاند، اکثر آنها کد منبع را ندیدهاند، و بسیاری از آنها به زبان برنامهنویسی متفاوتی نوشته شدهاند.
توسعه دهندگان منطق کمتری می نویسند و زمان بیشتری را صرف چسباندن چیزها به هم می کنند. امروزه سیستم تولید متوسط با چندین پایگاه داده، API و سایر ریزسرویس ها و نقاط پایانی تعامل دارد.
هر زمان که نرم افزار شما مجبور است با نرم افزار دیگری صحبت کند، دیگر نمی توانید فرضیات ساده ای در مورد نحوه عملکرد سیستم خود داشته باشید. هر پایگاه داده، صف پیام، حافظه پنهان و فریم ورک حالت ها، قوانین و محدودیت های خاص خود را دارد که رفتار آن را تعیین می کند. توسعهدهندگان به روشی برای آزمایش این رفتارها قبل از استقرار نیاز دارند و این دسته از آزمایشها را تست یکپارچهسازی میگویند.
«آزمونهای ادغام تعیین میکنند که آیا واحدهای نرمافزاری که بهطور مستقل توسعهیافتهاند، زمانی که به یکدیگر متصل میشوند به درستی کار میکنند یا خیر،» مینویسد. مارتین فاولر، که برای اولین بار در مورد تست یکپارچه سازی در دهه ۱۹۸۰ یاد گرفت.
تا همین اواخر، آزمایش یکپارچه سازی به این معنی بود که شما به یک نمونه از محیط تولید خود نیاز دارید. ایجاد آن محیط آزمایشی با دست فرآیندی بسیار زمانبر و با خطر بزرگ اشتباه بود. برای داشتن اختلاف بین تست و تولید جریمه هایی وجود داشت، و بار مداوم این بود که باید هر بار که تغییری در تولید ایجاد می کردید تغییراتی در محیط آزمایش خود ایجاد کنید. راهاندازی و استفاده از تست یکپارچهسازی آنقدر دشوار بود که برای بسیاری از توسعهدهندگان به عنوان یک رشته تست نرمافزار مبهم و غیرقابل دسترس باقی ماند.
آن موقع بود. این الان است.
Testcontainers: بهبود تست یکپارچه سازی
ریچارد نورث Testcontainers را در سال ۲۰۱۵ زمانی که مهندس ارشد Deloitte Digital بود ایجاد کرد. او مشاهده کرد که راهاندازی پیچیده آزمایش یکپارچهسازی – همه چیز از ایجاد محیطهای محلی ثابت گرفته تا پیکربندی پایگاههای داده و مدیریت مسائل بیشماری دیگر – منبع ثابتی برای کوبیدن تیمهای توسعهدهنده است که به روشی قابل اعتماد برای آزمایش کدشان در برابر وابستگیهای واقعی شبیه تولید نیاز داشتند. /p>
Testcontainers ساخت شمال بهعنوان یک کتابخانه منبع باز که به توسعهدهندگان اجازه میدهد «با کانتینرها» در برابر فروشگاههای داده، پایگاههای داده یا هر چیز دیگری که میتواند در کانتینر Docker اجرا شود، آزمایش کنند، از جمله چارچوبهای محبوب مانند Apache Kafka. Testcontainers روشی ارگونومیک و مبتنی بر کد را برای توسعه دهندگان فراهم می کند تا از ظروف برای آزمایش یکپارچه سازی محلی و مداوم استفاده کنند، بدون اینکه هر توسعه دهنده ای را مجبور کند که در بسیاری از تفاوت های ظریف ظروف متخصص شود.
Today Testcontainers محبوب ترین کتابخانه تست یکپارچه سازی مبتنی بر Docker است که توسط هزاران شرکت استفاده می شود، مانند Spotify، Google، اینستانا، Oracle، و Zalando. بخشی از محبوبیت Testcontainers کتابخانه ماژول های از پیش پشتیبانی شده آن است که تقریباً شامل هر پایگاه داده شناخته شده و بسیاری از فناوری های محبوب است که اغلب به پروژه Testcontainers کمک می کند و مستقیماً توسط پایگاه داده و فروشندگان فناوری نگهداری می شود. در اوایل سال جاری، سرگئی اگوروف، نگهدارنده کانتینرهای تست شمالی و هسته ای، ۴ میلیون دلار بودجه اولیه دریافت کرد و AtomicJar را راه اندازی کرد تا به تمدید ادامه دهد. اکوسیستم ماژول های Testcontainers پشتیبانی شده.
شکست سریعتر یک الگوی برنده است
همیشه بحثهای پرشور در مورد چگونگی بهترین تعادل بین سرعت و کیفیت نرمافزار وجود خواهد داشت. یکی از دلایل محبوبیت زیاد کامپایلر جاوا و فناوریهای مشابه، توانایی آنها در کمک به توسعهدهندگان برای یافتن خرابی نزدیکتر به نقطه توسعه است تا بتوانند به سرعت آنها را برطرف کنند.
همیشه باگهای شیطانی وجود خواهند داشت که از آزمایش شما طفره میروند، اما امروزه با سهولت روزافزون تست واحد نرمافزار و تست یکپارچهسازی، استدلال معتبرتر در مورد سرمایهگذاری چرخههای بیشتر برای آزمایش کد و سطح یکپارچهسازی آن قبل از فشار به تولید سختتر میشود. .
پست های مرتبط
نوع جدیدی از تست نرم افزار قدیمی
نوع جدیدی از تست نرم افزار قدیمی
نوع جدیدی از تست نرم افزار قدیمی