داستان Watir, Selenium و دیگران
تاریخ انتشار نسخه اصلی اکتبر 30, 2016
وقتی تصمیم به نوشتن این پست گرفتم، اول فکر کردم که خب باید ابتدا در مورد نقش اتوماسیون در QA بنویسم، بعد از آن Test Automation برای برنامه تحت وب را بدون اشاره به جزییات فنی تعریف کنم و تازه بعد از آن بروم سراغ مقایسه ابزارها و Framework های موجود در این زمینه (که مثل خانواده خوشحال تو عکس هستند). اما بعدش فکر کردم که مخاطب این وبلاگ که احتمالا یک برنامه نویس یا QA هست، حوصله خواندن تعاریف و بحثهای روش شناسی را نداشته باشد. پس بگذارید اول بروم سراغ مسائل کاربری و بعد از آن اتوماسیون در تست و صحبتهای کلی تر. امروزه بسیاری از شرکتهای نرم افزاری که راه کاره مبتنی بر Desktop دارند، به دلایل واضحی مثل هزینه کمتر توسعه و نگهداری، به سمت وب حرکت میکنند. در نتیجه نیاز به اتوماسیون تست برای این پلتفرم هم بیش از پیش احساس میشود. بطوریکه تعدادی از شرکتها بزرگ عنوانهای شغلی مثل Web Test Automation یا حتی Selenium Test Engineer دارند.
اصلی که در تمامی ابزارهای اتوماسیون تست به صورت Black box مشترک است 1) خودکارسازی سناریوهایی (مثل ثبت نام، اضافه کردن به سبد خرید) است که قرار است کاربردر هنگام استفاده از نرم افزار انجام میدهد و 2) Assertion هایی که تعیین میکند که آیا تست با موفقیت انجام شده است یا خیر. مثلا آیا بعد از ثبت نام اسم کاربری در منو دیده میشود یا خیر. در مورد وب، هر دو بخش احتیاج به locator هایی دارند که DOM object ها (مثل یک لینک) را در صفحات HTML شناسایی کنند و بروی آنها عملی مانند کلیک یا خواندن مقدار آن انجام دهند. در مقایسه میان ابزارهای اتوماسیون وب هم اصل بر توانایی آنها در تشخیص این object ها در مرورگرهای مختلف، سرعت انجام سناریوهای تست و binding هایی است که برنامه نویس بتواند در زبان مورد نظر از آن استفاده کند.در بین ابزارهای تست Selenium webdriver امروزه به نوعی ابزار استاندار شده یا de facto بحساب میاید. ولی Selenium از ابتدا به این شکل نبوده است. Selenium 1.0 برای اجرای تستها نوشته شده در test client (برنامه ای که کدهای تست با استفاده از Selenium API در ان نوشته شده) بر روی مرورگر از برنامه ای مبتنی بر JavaScript بنام Selenium Core استفاده میکرد. در واقع Selenium Server ابتدا Core را به مرورگر تزریق و سپس دستورات نوشته در client را به آن منتقل میکند.
مزیت این روش این بوده که Core قابل استفاده در تمام مرورگرهای رایج آن زمان یعنی FireFox، IE , Safari بوده است ولی مشکل آن تفاوت دستورات برای هرکدام از مرورگرها بود که ارتباط با object ها را مشکل میکرد. بطوری که برنامه نویس نمیدانست مثلا برای تایپ در یک text field در یک مرورگر از کدام تابع استفاده کند. علاوه بر این 0.Selenium 1 از مرورگرهای headless هم پشتیبانی نمیکرد (در مورد این مرورگرها در پستهای بعدی خواهم نوشت). اما با آمدن webdriver در Selenium این مشکلات تا اندازه زیادی حل شد: 1) Core حذف شد و هر مرورگری درایور مجزایی دارد که بجز IE و FireFox، باقی آنها توسط شرکتهای تولید کننده یا طرف سوم (3rd party) نوشته میشوند که مشهورترین آنها chromdriver، Selenroid و Edge webdriver هستند. Selenium نیز از طریق پروتکل JsonWire با این درایورهای در ارتباط است. این کار پیچیدگی استفاده از توابع مختلف در Selenium API را برای برنامه نویسان برداشت. بطور مثال ()click بروی تمام مرورگرها ثابت است. 2) اگر مرورگر و test client هر دو روی یک ماشین باشند، Selenium Server قالب حذف است (در مورد نقش Selenium Server بیشتر خواهم نوشت) و دستورات مستقیماً برروی مرورگر انجام میشود. این کار اجرای تست را سریعتر میکند. 3) مرورگرهای headless هم پشتیبانی میشوند. جدایی از موارد بالا، webdriver یک مشکل نسبتاً مهم دارد و آن سرعت پایین آن در اتوماسیون IE است که البته تلاشی چندانی هم در بهبود آن انجام نشده است. شاید به علت آنکه سهم IE به شدت در حال کاهش است و Edge هم در آینده جای آن را میگیرد.
اما در سالهایی که IE فراگیر بود این کند بودن مشکل مهمی محسوب میشد. یکی از ابزارهای اتوماسیون وب اما این مشکل را نداشت. Watir ابزاریست که توسط توسعه دهندگان Ruby تولید شده و مورد استفاده قرار میگیرد. تفاوت آن با Selenium در استفاده از پروتکل OLE ساخت مایکروسافت برای ارتباط با IE و در واقع علت سریعتر بودن آن هم در اتوماسیون به همین پروتکل برمیگردد. برنامه نویسان مایکروسافتی هم از نسخه طراحی شده آن برای dotNET یعنی WatiN استفاده میکرند که از طریق Nugget قابل اضافه شده به پروژه بود. البته بعدها با فراگیر شدن دیگر مرورگرها مانند Chrome و برنامه های موبایلی، توسعه دهندگان Watir از webdriver هم در بسته خود استفاده کردند. یکی از مشکلات Watir این است که برای اجرای تست ها به صورت از راه دور یا grid راه حلی ساده یا اصطلاحاً out of box وجود ندارد اما دلیل اصلی عدم رقبت برنامه نویسان به استفاده از Watir جامعه کوچک توسعه دهندگان (Ruby کارها) و کاربران آن است که یافتن پاسخ برای سوالات رایج کاربران در اینترنت را بسیار سخت میکند. نبود پشتیبانی قوی باعث شد که بعد از 2009 نسخه دیگری از WatiN بیرون داده نشود. در نتیجه برنامه نویسان dotNET به Coypu روی آوردند. این که Coypu چیست میتواند موضوع پست دیگری باشد ?
از زمانی که webdriver حرف اول را در اتوماسیون تستهای برنامه تحت وب میزند، wrapper های بسیاری برایش نوشته شده است که استفاده از آن را در زبانهای برنامه نویسی مختلف ساده تر و آن را کاراتر کرده است. Protractor، Selenide و Coypu نمونه های از آنها هستند که هرکدام سعی در بهبود اتوماسیون در تکنولوژی های مختلف مثل Ajax یا AngularJS داشته اند. در آینده در مورد آنها بیشتر مینویسم.