برنامه ما شامل بسیاری از توابع است که داده های ذخیره شده در Azure Data Explorer (ADX) را برمی گرداند. ما این توابع را در Kusto Query Language (KQL) نوشتیم و هر تابع مجموعه ای از داده ها را بر اساس آرگومان های ارسال شده برمی گرداند. اگرچه توسعه دهندگان این توابع را در حین نوشتن آزمایش کردند، اما ما به راهی نیاز داشتیم تا تأیید کنیم که با تغییر کد و داده ها، عملکردها همچنان به کار خود ادامه می دهند. تست واحد خودکار بخشی ضروری از چرخه عمر توسعه برنامه است. تأیید می کند که کد به درستی کار می کند و خطر اینکه تغییرات کد آتی باعث از بین رفتن عملکرد موجود شود را به حداقل می رساند. در این مقاله، رویکردی را که در خودکارسازی تست توابع ADX اتخاذ کردیم، مورد بحث قرار خواهم داد.
تابع ادعای KQL
ADX با یک چارچوب تست واحد ارسال نمی شود، اما KQL دارای یک تابع استاتیک است که می تواند برای آزمایش توابع و پرس و جوها استفاده شود.
تابع assert دو آرگومان را می پذیرد: یک شرط بولی و یک رشته. اگر شرط Boolean false را برگرداند، یک خطا ایجاد می شود و رشته برگردانده می شود. ما می‌توانیم از این برای آزمایش اینکه عملکردهای ADX ما مطابق انتظار عمل می‌کنند استفاده کنیم.
یک تست نمونه
به عنوان مثال، کد زیر بررسی می کند که آیا جدول 1 دارای هر ردیفی است یا خیر.
کد بالا یک استثنا ایجاد می‌کند و اگر داده‌ای در جدول 1 وجود نداشته باشد، «table1 باید برخی از ردیف‌ها را برگرداند» را خروجی می‌دهد. اگر جداول خود را با داده‌های شناخته شده پر کنیم، می‌توانیم در آزمایش‌های خود دقیق‌تر عمل کنیم و جریان داده‌ها را در جدول (از طریق سیاست‌های به‌روزرسانی یا نماهای Materialized) آزمایش کنیم. ADX دستور . ingest را ارائه می‌کند که به ما امکان می‌دهد تا اسکریپت دریافت داده‌ها را بنویسیم. برای مجموعه داده های کوچک، می توانیم از دستور درون خطی . ingest استفاده کنیم. برای مجموعه داده‌های بزرگ‌تر، می‌توانیم از فضای ذخیره‌سازی Azure استفاده کنیم. فرض کنید یک جدول AssetHistory با داده های زیر داریم:
| مهر زمان | شناسه سازمان | شناسه دارایی | محل |
|---|---|---|---|
| 2022-02-08T21:25:03Z | ORG-0001 | 90000001 | |
| 2022-02-08T21:25:04Z | ORG-0001 | 99999934 | |
| 2022-02-08T21:25:04Z | ORG-0001 | 99999939 | |
| 2022-02-08T21:25:06Z | ORG-0001 | 90000003 | |
| 2022-02-08T21:25:36Z | ORG-0001 | 99999931 | |
| 2022-02-08T21:27:08Z | ORG-0001 | 99999935 | |
| 2022-02-08T21:29:28Z | ORG-0001 | 99999936 | |
| 2022-02-08T21:29:38Z | ORG-0001 | 99991000 | |
| 2022-02-08T21:30:04Z | ORG-0001 | 99999939 | |
| 2022-02-08T21:30:04Z | ORG-0001 | 99999934 | |
| 2022-02-08T21:30:06Z | ORG-0001 | 90000003 | |
| 2022-02-08T21:32:08Z | ORG-0001 | 99999935 | |
| 2022-03-12T21:32:08Z | ORG-0001 | 99999935 |
تابع getassetHistory فهرست شده در زیر جدول AssetHistory را با آرگومان های ورودی فیلتر می کند. با این حال، منطقی برای نادیده گرفتن فیلترها در صورت عدم ارسال آرگومان به تابع نیز دارد.
ما می توانیم از ادعا برای نوشتن برخی از تست ها استفاده کنیم. ما از قبل داده های موجود در جدول را می دانیم ، بنابراین می دانیم که چند ردیف عملکرد باید برای مجموعه مشخصی از آرگومان های ورودی برگردد. در اینجا چند مثال آورده شده است:
همانطور که مشاهده می کنید ، هر یک از تست های فوق مجموعه ای از آرگومان ها را به عملکرد منتقل می کند ، به طوری که هر آزمون جدول را برای محدوده زمانی متفاوت فیلتر می کند. هر آزمون تأیید می کند که عملکرد به درستی فیلترها را با تأیید اینکه تعداد صحیح ردیف ها را برمی گرداند ، اعمال می کند. اما همچنین تأیید می کند که عملکرد هنگام تصویب یک آرگومان تهی یا هنگامی که یک آرگومان (به عنوان مثال ، socationinpolygon) حذف می شود ، به درستی کار می کند.
ما حتی می توانیم داده های پویا عبور را آزمایش کنیم ، مانند این تماس عملکرد ، که یک شیء چند ضلعی را به عملکرد منتقل می کند:
هر یک از آزمایشات توضیح داده شده در بالا انتظار دارند که داده ها در حالت شناخته شده قرار بگیرند ، بنابراین مهم است که داده ها را به درستی اولیه کنید.
برای پروژه ما ، ما اسکریپت های خودکار ایجاد کردیم که تمام اشیاء پایگاه داده را بازآفرینی می کند. سپس جداول را با داده های آزمون جمع کنید. ما این اسکریپت را قبل از اجرای هر آزمون اجرا می کنیم ، بنابراین همیشه با یک پایگاه داده تمیز شروع می کنیم. این باعث می شود داده ها قابل پیش بینی باشند ، و این باعث می شود تماس های عملکردی ما با مجموعه ای از ورودی ها Idempotentent باشد.
سایر رویکردهای آزمایش
از طرف دیگر ، ما می توانیم با استفاده از SDK مناسب ، یک پرس و جو را آزمایش کنیم تا آن را از برنامه ای که در جاوا ، دات نت یا برخی از زبان های سطح بالا نوشته شده است ، فراخوانی کنیم. این مزیت این است که به ما اجازه می دهد تست ها را در یک چارچوب تست قوی مانند XUNIT یا JUNIT بنویسیم.
با این حال ، این رویکرد پیچیدگی را به تست های ما اضافه می کند و این احتمال را ایجاد می کند که ممکن است خطاها در کد ما در خارج از ADX رخ دهد. نگه داشتن تمام تست های ما در ADX تمایل دارد میزان کدی را که برای نوشتن نیاز داریم کاهش دهد و آزمایشات را بر روی توابع KQL که نوشتیم متمرکز می کند.
مشارکت کنندگان
کد موجود در این مقاله بر اساس کارهایی است که توسط تیم GT مهندسی نرم افزار تجاری مایکروسافت انجام شده است. بسیاری از تست های اصلی توسط برادن اریکسن برای مشتری ما نوشته شده است.
نتیجه
تست های KQL فوق نحوه استفاده از عملکرد Assert را برای ایجاد تست های واحد خودکار نشان می دهد که اعتبارسنجی می کند که عملکردهای ADX ما به درستی کار می کنند. این یک ابزار قدرتمند برای بهبود و حفظ کیفیت کد است.
می توانید اطلاعات بیشتر در مورد این الگوی را در سایت مستندات مایکروسافت بخوانید.
