وحید نصیری وحید نصیری
آزمایش Web APIs توسط Postman - قسمت چهارم - نوشتن آزمون‌ها و اسکریپت‌ها
‫۵ سال و ۴ ماه قبل، چهارشنبه ۲۵ اردیبهشت ۱۳۹۸، ساعت ۱۴:۰۳
یک نکته‌ی تکمیلی: بهتر است برای چه مواردی در Postman آزمایش بنویسیم؟

یک response از سه قسمت هدر، status code و بدنه‌ی آن تشکیل می‌شود. بنابراین هر سه قسمت را باید آزمایش کرد تا بتوان توسط آن عملکرد یک Web API را بررسی نمود.
برای مثال فرض کنید که می‌خواهید برای متد Put، آزمایش بنویسید. این آزمایش باید شامل موارد زیر باشد:

بررسی موفقیت آمیز بودن عملیات
- آیا هدرهای درستی در response درج شده‌اند؟
- آیا status code دریافتی از سرور برای مثال 200 یا 204 است؟
- آیا عملیات به روز رسانی، موجودیت مشخص و مورد انتظاری را به روز رسانی کرده‌است یا خیر؟
- آیا تمام فیلدها به درستی به روز رسانی شده‌اند؟
- آیا فیلدهایی که در درخواست ارسالی قید نشده‌اند، با مقدار پیش‌فرض خود مقدار دهی شده‌اند؟

بررسی شکست عملیات
- آیا به روز رسانی موجودیتی که وجود ندارد، خروجی 404 را به همراه دارد یا خیر؟
- آیا اگر هدر content-type ذکر نشود، شاهد status code=415 unsupported media type خواهیم بود؟
- آیا اگر هدر content-type نامربوطی ذکر شود، شاهد status code=415 unsupported media type خواهیم بود؟
- آیا اگر بدنه‌ی درخواست خالی را ارسال کنیم، خروجی 400 bad request صادر می‌شود؟
- آیا اگر فیلدها را طوری تنظیم کنیم که سبب مشکلات اعتبارسنجی شوند، خروجی 422 unprocessable entity صادر می‌شود؟

بنابراین در حالت کلی:
- هر دو وضعیت موفقیت آمیز بودن و شکست عملیات باید بررسی شوند.
- مشکلات اعتبارسنجی ورودی‌ها باید بررسی شوند.
- ورودی‌های مورد انتظار را کم و زیاد کنید. اگر درخواستی قرار است کوئری استرینگی را بپذیرد، آن‌را قید نکنید یا برعکس.
وحید نصیری وحید نصیری
انجام کارهای زمانبندی شده در برنامه‌های ASP.NET توسط DNT Scheduler
‫۵ سال و ۴ ماه قبل، سه‌شنبه ۲۴ اردیبهشت ۱۳۹۸، ساعت ۲۳:۲۹
تاریخچه‌ی پشتیبانی از TLS 1.2 در NET. به این صورت است:
وضعیت پشتیبانی از TLS 1.2
 نگارش دات نت
 پشتیبانی نمی‌شود. راه حلی هم ندارد.
  NET 3.5. یا قبل از آن
 پشتیبانی نمی‌شود. اما اگر نگارش بالاتری نصب است، قطعه کد زیر را استفاده کنید:
ServicePointManager.SecurityProtocol = 
  (SecurityProtocolType)3072;
  NET 4.0.
 پشتیبانی می‌شود، اما حالت پیش‌فرض نیست و باید دستی انتخاب شود:
ServicePointManager.SecurityProtocol = 
  SecurityProtocolType.Tls12;
  NET 4.5.
 حالت پیش‌فرض است و نیاز به تنظیمات خاصی ندارد.
  NET 4.6. و یا بالاتر
- بنابراین اگر از Full .NET استفاده می‌شود، فقط کافی است که Target Framework برنامه را به بالاتر از NET 4.6. تنظیم کنید (الان نگارش 4.8 ارائه شده) و سرور هم همان نگارش را نصب کند. نیاز به تنظیم بیشتری ندارد. در مورد NET Core. هم به همین صورت است و HttpClient آن برای دریافت صفحات ارائه شده‌ی با TLS 1.2 هیچ مشکلی ندارد.
- سطر ServerCertificateValidationCallback که true کردید یعنی مجوز SSL سرور شما حتی اگر معتبر نبود (و همچنین کل اینترنت؛ چون این تنظیم سراسری است)، معتبر تشخیص داده شود که غیرضروری است.
- مورد لاگ کردن، وابستگی به بانک اطلاعاتی خاصی ندارد. این سطرها را حذف کنید و بجای آن کدهای بانک اطلاعاتی خودتان را قرار دهید. یا اگر logger پیش‌فرض سیستم شما اطلاعات را بجای کنسول یا صفحه‌ی Debug، در بانک اطلاعاتی ذخیره می‌کند (^ یا ^)، این قسمت نیازی به تغییر ندارد.
وحید نصیری وحید نصیری
انجام کارهای زمانبندی شده در برنامه‌های ASP.NET توسط DNT Scheduler
‫۵ سال و ۴ ماه قبل، یکشنبه ۲۲ اردیبهشت ۱۳۹۸، ساعت ۲۳:۰۳
چون یک async void را ایجاد کردید و به صورت fire-and-forget کار می‌کند. یعنی IoCWrapper.RunAndDispose بلافاصله خاتمه پیدا خواهد.
امضای مدنظر شما چنین چیزی باید باشد:
public static Task RunAndDispose(Func<Task> action)
تا خود RunAndDispose هم قابلیت await پیدا کند.
وحید نصیری وحید نصیری
آزمایش Web APIs توسط Postman - قسمت دوم - ایجاد گردش کاری بین درخواست‌ها
‫۵ سال و ۴ ماه قبل، شنبه ۲۱ اردیبهشت ۱۳۹۸، ساعت ۱۶:۵۴
یک نکته‌ی تکمیلی: مدیریت گردش‌های کاری بین درخواست‌ها با کد نویسی

در مطلب جاری، برای اینکه یک گردش کاری، بین درخواست‌ها صورت گیرد، ترتیب اجرای آن‌ها را به صورت دستی، با drag & drop آن‌ها در مجموعه‌ای که در آن قرار داشتند، مشخص کردیم. اینکار را توسط کدنویسی نیز می‌توان انجام داد و در این حالت گردش‌های کاری پیچیده‌تری را می‌توان خلق کرد. برای مثال، ابتدا اجرای درخواست 1، بعدر درخواست 3، بعد بازگشت به 2، بعد بازگشت به 1 و سپس ادامه‌ی کار و یا حتی توقف آن.
برای مشخص سازی اجرای درخواست بعدی، پس از پایان درخواست جاری، می‌توان از متد زیر استفاده کرد:
postman.setNextRequest("Request name");
محل درج آن نیز در قسمت Tests درخواست جاری است.

Request name نیز همان نامی است که در حین ذخیره سازی یک درخواست در مجموعه‌‌ای، برای آن مشخص کرده‌ایم. اگر در تشخیص آن دچار مشکل هستید، در قسمت Tests، مقدار آن‌را لاگ کنید:
console.log(pm.info.requestName);
پس از اجرای درخواست و اجرای قسمت Tests آن، این مقدار را در کنسول postman، که آیکن ظاهر شدن آن در status bar آن قرار دارد، می‌توان مشاهده کرد.

نکته: اگر در اینجا بجای نام درخواست، مقدار null تنظیم شود، سبب خاتمه‌ی اجرای گردش کاری خواهد شد.
در همان مطلب، پروژه‌ی ارسال شده را یکبار اجرا کنید. بعد از لیست «var allUserClaims = ((ClaimsIdentity)User.Identity).Claims» یک خروجی بگیرید. همین خروجی و لیست مسطح claims یک کاربر را اینطرف به Identity server اضافه کنید، کار می‌کند. چرا؟ چون در ساختار درونی سیستم ASP.NET Core Identity، در عمل چیزی به نام Role وجود خارجی ندارد. برای مثال Roleها هم در این سیستم یک User-Claim از نوع ClaimTypes.Role هستند. تمام سیستم Identity بر اساس User Claims کار می‌کند. تمام Roleها و غیره در پشت صحنه ابتدا تبدیل به user claims می‌شوند (یعنی یک لیست ساده و مسطح) و سپس استفاده خواهند شد. بنابراین اگر لیست نهایی (و مسطح) User Claims را در Identity server شبیه سازی کنید، به عملکرد یکسانی خواهید رسید.
وحید نصیری وحید نصیری
آزمایش Web APIs توسط Postman - قسمت چهارم - نوشتن آزمون‌ها و اسکریپت‌ها
‫۵ سال و ۴ ماه قبل، جمعه ۲۰ اردیبهشت ۱۳۹۸، ساعت ۱۷:۴۰
یک نکته‌ی تکمیلی: پردازش سایر فرمت‌های دریافتی از سرور
در این مطلب نحوه‌ی تبدیل response دریافتی را به json بررسی کردیم. سایر حالات زیر نیز توسط postman پشتیبانی می‌شوند:
عملکرد
 متد
 تبدیل XML به شیء JSON
 
let jsonObject = xml2Json(responseBody);
 تبدیل JSON به شیء JSON
 
let jsonData = pm.response.json();
 تبدیل بدنه‌ی response به متن ساده
 
let text = pm.response.text();
 تبدیل HTML بدنه‌ی response به یک شیء از نوع cheerio؛ مانند:
let titleText = html.find('h1').text();
 
let html = cheerio(responseBody);
وحید نصیری وحید نصیری
آزمایش Web APIs توسط Postman - قسمت چهارم - نوشتن آزمون‌ها و اسکریپت‌ها
‫۵ سال و ۴ ماه قبل، جمعه ۲۰ اردیبهشت ۱۳۹۸، ساعت ۱۶:۵۴
یک نکته‌ی تکمیلی: آشنایی با Chai Assertion Library

Postman به صورت پیش‌فرض به همراه کتابخانه‌ی Chai Assertion است و روش fluent ای را که برای نوشتن آزمون‌های آن مشاهده می‌کنید، توسط همین کتابخانه ارائه می‌دهد و برای استفاده‌ی از آن، نیازی به تنظیمات خاصی نیست. مثال‌های بیشتری از این کتابخانه 
pm.test("Test Name", function(){
 let a= {
  "name" : "Vahid"
 };

 let b= {
  "name" : "Vahid"
 };

 pm.expect(a).to.eql(b);
});
همانطور که در این مثال نیز مشاهده می‌کنید، syntax کتابخانه‌ی Chai Assertion، شروع شده‌ی با یک .pm، در postman قابل تعریف و استفاده‌است.
وحید نصیری وحید نصیری
آزمایش Web APIs توسط Postman - قسمت چهارم - نوشتن آزمون‌ها و اسکریپت‌ها
‫۵ سال و ۴ ماه قبل، جمعه ۲۰ اردیبهشت ۱۳۹۸، ساعت ۱۴:۱۴
یک نکته‌ی تکمیلی: اجرای دستوراتی پیش از اجرای درخواست‌ها در postman

همانطور که در مطلب جاری نیز عنوان شد، آزمون‌های Postman، پس از پایان اجرای یک درخواست و بر روی محتوای response دریافتی از سرور، اجرا می‌شوند. اگر نیاز به اجرای دستوراتی پیش از اجرای یک درخواست وجود داشته باشد، می‌توان از گزینه‌ی Pre-request script استفاده کرد:


مهم‌ترین کاربرد آن، تنظیم یکسری متغیر، پیش از اجرای درخواست اصلی است. برای مثال فرض کنید که می‌خواهید id ارسالی به سمت سرور را random کنید. برای این منظور یک متغیر محیطی جدید را در قسمت Pre-request script درخواست جاری، تنظیم می‌کنیم (در مورد متغیرهای محیطی در قسمت بعد، مفصل بحث می‌شود):
pm.environment.set("newId", "name " + parseInt(Math.random() * 10000));
سپس برای استفاده‌ی از آن، اینبار url را به صورت زیر تنظیم می‌کنیم:
https://localhost:5001/users/{{newId}}
که در اینجا متغیر {{newId}} هربار پیش از اجرای درخواست، به یک مقدار اتفاقی تنظیم شده و سپس از آن برای ساخت URL نهایی استفاده می‌شود.
وحید نصیری وحید نصیری
آزمایش Web APIs توسط Postman - قسمت چهارم - نوشتن آزمون‌ها و اسکریپت‌ها
‫۵ سال و ۴ ماه قبل، جمعه ۲۰ اردیبهشت ۱۳۹۸، ساعت ۱۴:۱۲
یک نکته‌ی تکمیلی: روش Debug آزمون‌های postman

اگر به status bar برنامه‌ی postman دقت کنید، یکی از آیکن‌های آن به کنسول آن اشاره می‌کند:


در اینجا می‌توان توسط دستورات معروف console.log، تمام اشیاء و متغیرهای دریافتی از سرور را لاگ کرد و سپس مقدار آن‌ها را در کنسول postman بررسی نمود:
const jsonData = pm.response.json();
console.log(jsonData);