استراتژی تست میکروسرویس ها

میکروسرویس ها ذاتاً توزیع می شوند. میکروسرویس های زیادی در هر معماری وجود دارد. هر میکروسرویس دارای اجزای مختلفی است، مانند سرویسی که می‌تواند رویدادهای ActiveMQ یا موضوع کافکا را مصرف کند، داده‌ها را در هر دو پایگاه داده RDBMS یا NoSQL به طور همزمان ذخیره کند و سپس رویداد تازه ایجاد شده را به موضوع کافکا دیگری ارسال کند. هدف استفاده و شروع. پردازش یا فراخوانی یک سرویس مستقل RESTful بر روی سایر خدمات ساخته شده است.
نوشتن یک تست معنادار برای اجزای میکروسرویس در معماری کار آسانی نیست. در این مقاله، ما بر روی راهنمای تست میکروسرویس تمرکز کرده‌ایم تا تمام جنبه‌های تست در کاربرد را جدا کنیم.
از چه استراتژی هایی می توان برای تست میکروسرویس ها استفاده کرد؟
برای درک تست میکروسرویس، هرمی با سه سطح L2، L1 و L3 را در نظر بگیرید. لایه اول هرم L1، لایه دوم L2 و لایه سوم L3 است. با توجه به هر معماری میکروسرویس، باید سه نوع مختلف تست وجود داشته باشد. این موضوعات به L3، L2، L1 تقسیم می شوند. ما فقط برای ایجاد یک تصویر ذهنی به این لایه ها نگاه می کنیم. سعی کنید برای هر یک از آنها بسته هایی ایجاد کنید. در ادامه برای درک بهتر این مشکل در مورد جزئیات تست لایه صحبت خواهیم کرد.
لایه میکروسرویس L1
در سطح L1، توسعه دهندگان باید کلاس هایی را در کد تعریف کنند که بیشتر با منطق تابع مطابقت داشته باشد. در واقع، شما باید فقط بر روی کلاس های آزمایشی در سطح L1 تمرکز کنید که بیشترین ارتباط را با منطق کار شما دارند، بنابراین باید این کلاس ها را فهرست کرده و مؤلفه های آزمایشی را برای آنها تهیه کنید. تنها قانونی که در این مرحله باید رعایت کنید این است که سعی نکنید چیزی ایجاد کنید (مسخره کنید)، اینها ساده ترین بخش های تست کامپوننت هستند.
لایه میکروسرویس L2
سرویسی را در نظر بگیرید که رکوردها را در پایگاه داده وارد می کند و رویدادهای جدید و گسترده ای را برای موضوعات کافکا ایجاد می کند.
در لایه L2 می توانید تمام اجزای خارجی مانند پایگاه داده ها، کافکا یا سرویس های RESTful را شبیه سازی کنید.
Microservizio Paparanga L3
سخت ترین بخش آزمایش هرم، آزمایش اجزای L3 است. هنگام آزمایش اجزای L3؛ تمام اجزای تست واقعی هستند و اصلا مسخره نیستند. نکته ای که در این مرحله باید از آن آگاه باشید این است که معماری میکروسرویس به دو دلیل نباید بخشی از سرویس در حین تست باشد.
اجرای یک تست زمان ساخت و استقرار سرویس را افزایش می دهد.
انجام آزمایشات احتمال بروز مشکلات در حین ساخت را افزایش می دهد.
اجزای تست باید به صورت جداگانه به عنوان یک سرویس جداگانه ذخیره شوند. این سرویس باید هم توسط QA و هم توسط توسعه دهندگان تایید شود.
از سرگیری
در معماری میکروسرویس، شما باید بتوانید تست های موثر بنویسید. شما باید برنامه را فقط با پوشش کد آزمایش کنید یا آن را با اجزای آزمایشی بی فایده پر کنید. زیرا هیچ کاری برای بهبود کار شما انجام نمی دهد، مانند نوشتن اجزای تست برای Setters/Getters. علاوه بر این، باید روی دروغ نویسی تمرکز کنید. زیرا این قسمت به شما در حل مشکلات توسعه نرم افزار کمک می کند. بخش های آزمایشی باید به طور منظم نوشته شوند تا هر جزء جدید فقط با نگاه کردن به بخش های آزمایشی بتواند برنامه کاربردی را درک کند.