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

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

من ارسلان میربزرگی هستم. میکروسرویس‏ها به طور طبیعی توزیع شده هستند. در هر معماری، میکروسرویس‏های زیادی وجود دارد. هر میکروسرویس دارای اجزای مختلفی است، مثلاً سرویسی که می‌تواند رویدادها را از ActiveMQ یا یک topic کافکا استفاده کند، داده‌ها را در هر دو پایگاه داده RDBMS یا NoSQL به طور همزمان ذخیره می‌کند و سپس یک event توسعه یافته جدید را در تاپیک دیگر کافکا به منظور استفاده و شروع پردازش یا فراخوانی کامل یک سرویس RESTful مستقل، در سایر سرویس‌ها می‌سازد.

نوشتن یک تست معنی‌دار برای اجزای میکروسرویس‌ها در معماری، کار ساده ای نیست. ما در این مقاله روی یک استراتژی تست میکروسرویس تمرکز کرده ایم به طوریکه می‌توان تمام اجزای تست در اپلیکیشن را جدا کرد.

 برای تست میکروسرویس از چه استراتژی می‌توان استفاده کرد؟

برای درک تست میکروسرویس یک هرم را با سه لایه L2، L1 و L3 در نظر بگیرید. اولین لایه هرم L1 است، لایه دوم L2 و لایه سوم L3 نام دارند. طبق معماری هر میکروسرویس باید سه نوع تست متفاوت وجود داشته باشد. این آزمودن‌ها با عناوین L3، L2، L1 طبقه بندی می‌شوند. ما فقط این لایه ها را برای ایجاد یک تصویر ذهنی در نظر گرفته ایم. سعی کنید برای هر یک از آن‌ها پکیج‌هایی را ایجاد کنید. در ادامه به جزییات تست در لایه ها می‌پردازیم تا بهتر این موضوع را درک کنید.

• لایه L1

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

•  لایه L2

یک سرویس را در نظر بگیرید که رکوردها را در پایگاه داده قرار می‌دهد و یک event توسعه یافته جدید را برای topic کافکا ایجاد می‌کند.

 در لایه L2 می‌توانید تمام اجزای خارجی مانند پایگاه داده، کافکا یا سرویس RESTful را شبیه سازی کنید.

• لایه L3

پیچیده ترین بخش از تست هرم، تست اجزای L3 است. هنگام تست اجزای L3، تمام اجزای تست واقعی هستند و به هیچ وجه شبیه سازی نمی‌شوند(mock نمیشوند). نکته ای باید در این مرحله توجه کنید این است که در هنگام تست، به دو دلیل نباید معماری میکروسرویس، بخشی از خود سرویس باشد:

• اجرای تست، زمان ساخت و استقرار سرویس را افزایش می‌دهند.
• اجرای تست احتمال ایجاد مشکل در build را افزایش می‌دهند.

اجزای تست باید به طور جداگانه به عنوان یک سرویس مجزا ذخیره شوند. این سرویس باید هم توسط QA و هم توسط توسعه‌دهندگان تایید شوند.

 نتیجه گیری

 در معماری میکروسرویس‌ها، شما باید بتوانید تست کارآمد بنویسید. شما نباید اپلیکیشن را فقط با code coverage آزمایش کنید و یا از اجزا آزمایشی بی‌فایده پُرکنید؛ زیرا این کار مانند نوشتن اجزای تست برای Setters/Getters هیچ کمکی به بهبود کار شما نمی‌کند. علاوه بر این، شما باید روی نوشتن mock تمرکز کنید؛ زیرا این بخش به شما در رفع مشکلات ساخت نرم افزار کمک می‌کند. بخش‌های تست باید به طور منظم نوشته شوند تا هر جزء جدید بتواند فقط با نگاه کردن بخش‌هایی از تست، اپلیکیشن را درک کند.