فصل دوازدهم: آزمایش افزونه های شما

بیان خلاصه ای از بحث توسط هوش مصنوعی:

هنگام شروع هر پروژه توسعه نرم افزاری، ما معمولاً روی محیط فعلی خود تمرکز می کنیم (در زمان نوشتن این کتاب، ما روی  جوملا 5 و PHP 8.2  به عنوان محیط خود تمرکز میکنیم). اما همانطور که دنیای اطراف ما تکامل می یابد، محیط ما به روز می شود و ما باید مطمئن باشیم که پروژه های ما با الزامات جدید کار می کنند. ما نسخه جدیدی از PHP خواهیم داشت که کارآمدتر خواهد بود و باید مشکلات و ناسازگاری های جدید را در کد خود شناسایی کنیم. تست نرم افزار ما به یک جنبه کلیدی برای پروژه های میان مدت و بلند مدت تبدیل می شود.

در این فصل، ما برخی از گزینه ها برای آزمایش خودکار پروژه های توسعه جوملا را بررسی خواهیم کرد. ما از تست واحد ساده به آزمایش سیستم جامع تر خواهیم رفت و این فصل را با معرفی تست دسترسی با استفاده از یک مرورگر وب به پایان می رسانیم.

پس از خواندن این فصل، می توانید تست های مورد نیاز پروژه خود را توسعه دهید. این باعث افزایش اعتماد و اطمینان شما به کد خود می شود.

موضوعات اصلی این فصل به شرح زیر است:

• آیا نیاز به آزمایش دارم؟
• شامل تست واحد (Unit testing) در جوملا
• نحوه اضافه کردن تست سیستم در جوملا
• آزمایش دسترسی در افزونه های ما

الزامات فنی

در این فصل، ما روی ساختار کد نویسی خود کار می کنیم زیرا آزمایش هایی را به کد خود اضافه می کنیم. بنابراین، به موارد زیر نیاز خواهید داشت:

• Visual Studio Code (یا ویرایشگر کد دلخواه شما)
• PHP Composer  روی کامپیوتر شما نصب شده است

می توانید فایل های کد این فصل را در GitHub بیابید:

https://github.com/PacktPublishing/Developing-Extensions-for-Joomla-5/tree/chapter12 

آیا نیاز به آزمایش دارم؟

در توسعه وب، ما با محیطی همیشه در حال تغییر روبرو هستیم. به عنوان مثال، PHP  از چرخه انتشار جامعه پیروی می کند که در آن ما هر سال یک نسخه جدید PHP داریم و هر نسخه اصلی دارای 3 سال پشتیبانی امنیتی است. این نسخه  های جدید ویژگی های جدید و حذف کدهایی را ارائه می کنند که بر کد ما تأثیر می گذارند.

اگر می خواهیم نرم  افزار ما در آزمون زمان تاب بیاورد، باید به بهبود آن ادامه دهیم و موارد منسوخ شده و قرارداد های قدیمی را اصلاح کنیم.

ما می توانیم به صورت دستی افزونه های خود را تست کنیم. برای آن، ما باید محیط و شرایطی را که می خواهیم نرم افزار خود را در آن آزمایش کنیم، تکرار کنیم، اما می توانیم تست خودکار را نیز به فرآیند کدنویسی خود اضافه کنیم و تا حدودی آن را توسط یک ماشین انجام دهیم.

تست دستی، نقطه شروع خوبی است و آخرین روش آزمایشی است که تضمین می کند افزونه ی ما دقیقاً همان کاری را که ما می خواهیم، انجام می دهد. با این حال، با اضافه کردن محیط های تست بیشتر و رشد نرم افزارمان، انجام تست دستی در همه محیط  هایمان زمان زیادی می برد.

تست خودکار در مقایسه با تست دستی مزایایی دارد:

• می توانید هر چند بار که بخواهید در محیط های مختلفی که نیاز دارید همان آزمایش را انجام دهید.
• تست  های خودکار، اسکریپت  های کوچکی هستند که بررسی می کنند، توسعه شما مطابق انتظار عمل می کند. به این ترتیب، نوشتن کد برای تست های خودکار بسیار خنده دار تر از انجام تست های دستی است.
• نوشتن تست  های خودکار به شما کمک می کند کد بهتری بنویسید، زیرا به روش های ماژولار نیاز دارید که فقط یک عمل را انجام دهند تا یک تست خوب از آنها بنویسید.

تست و آزمایش، یک حوزه کامل از توسعه ی نرم افزار است و بسیاری از فلسفه ها و استراتژی ها وجود دارد که می توانید برای آزمایش افزونه خود استفاده کنید. در این فصل، رایج ترین و مفید ترین تکنیک  ها برای آزمایش مؤثر را بررسی خواهیم کرد. ما با یادگیری در مورد یکی از محبوب ترین تکنیک های تست در PHP شروع خواهیم کرد.

شامل تست واحد (Unit testing) در جوملا

تست واحد (Unit testing) یک استاندارد صنعتی است که به شما کمک می کند، کیفیت پیشرفت های خود را تضمین کنید. تست واحد، شامل آزمایش بخش  های کوچک کد شماست. کوچکترین قطعات قابل آزمایش در PHP متدها یا توابع کلاس هستند. تست های واحد، منطق کد شما را به روشی سریع و قابل اعتماد بررسی می کنند.

هنگام اجرای تست های واحد، نیازی ندارید که کل برنامه شما در حال اجرا باشد یا به یک پایگاه داده متصل باشد. ممکن است آزمایش  های خود را مستقیماً بر اساس کد خود اجرا کنید، اگرچه ممکن است نیاز به راه ا ندازی محیطی داشته باشید.

تست های واحد باید فقط یک عمل خاص یا نتیجه کد شما را آزمایش کنند. بنابراین، زمانی که کد خود را می نویسید، باید تمرکز کنید و متد هایی ایجاد کنید که فقط یک نتیجه داشته باشند. این منجر به کد با کیفیت بالاتر می شود. این بسیار مفید و دلگرم کننده است، یک استراتژی توسعه مبتنی بر آزمایش معروف به test-driven development توسعه آزمایش محور (TDD). 

 TDD چیست؟

 TDD شامل آزمونی است که می خواهید در آن قبول شوید و سپس کدی را برای قبولی در آن بنویسید:

شکل 12.1 - گردش کار  TDD

گردش کارTDD  به شرح زیر است:

1. شما به یک بخش جدید از عملکرد در کد خود فکر می کنید.
2. شما آزمایشی ایجاد می کنید که ثابت می کند عملکرد کار می کند.
3. شما سعی می کنید آزمون را قبول کنید و آن را با شکست مواجه می کنید (شما هیچ کدی برای موفقیت در عملکرد ندارید).
4. شما یک کد برای قبولی در آزمون بنویسید.
5. شما امتحان را قبول می کنید.

این گردش کار، زمانی امکان پذیر است، که شما کد ماژولار را بنویسید که از اصل مسئولیت واحد (single responsibility principle) استفاده می کند. به شما امکان می دهد برای هر یک از متد های خود با خیال راحت تست بنویسید. برای نوشتن این تست ها از فراخوانی فریم ورک PHPUnit استفاده می کنیم.

نصب  PHPUnit

 PHPUnit محبوب ترین فریم ورک برای تست واحد در PHP و همچنین چارچوب تست واحد است که توسط جوملا Project ^SM رسمی استفاده می شود.

ما می توانیم PHPUnit  را با استفاده از  Composerدر مخزن خود نصب کنیم، بیایید نگاهی بیندازیم.

نصب PHPUnit از طریق  Composer

 

برای نصب PHPUnit  از طریق Composer باید  Composer را به صورت سراسری روی رایانه خود یا به صورت محلی در مخزن خود نصب کنیم. بخش مطالعه بیشتر لینکی به وب سایت اصلی Composer  با جزئیات بیشتر با توجه به سیستم عامل شما ارائه می دهد.

هنگامی که Composer را روی رایانه خود نصب کردید، می توانید از آن برای راه اندازی سریع پروژه ما استفاده کنید. اول از همه، از خط فرمان، داخل پوشه اصلی مخزن خود، دستور زیر را اجرا کنید:

 
composer init  

با این کار اسکریپت نصب اولیه Composer راه اندازی می شود. اسکریپت با پرسیدن سوالاتی در مورد پروژه شما شروع می شود. در مورد ما، از این پاسخ ها استفاده خواهیم کرد:

 
Package name: piedpiper/spm 
Description: A simple project management extension 
Author: Carlos Cámara (این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید) 
Minimum Stability: (click enter to use default) 
Package Type: project 
License: GPL v2.0 
dev dependencies: phpunit/phpunit 
version constraint: 8.5.32 
Add PSR-4 autoload mapping: No 

این تنظیمات فایل composer.json زیر را ایجاد می کند:

 
{ 
"name": "piedpiper/spm", 
"description": "A simple project management extension", 
"type": "project", 
"require-dev": { 
"phpunit/phpunit": "8.5.32" 
}, 
"license": "GPL v 2.0", 
"authors": [ 
{ 
"name": "Carlos Cámara", 
"email": "این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید" 
} 
], 
"require": {} 
} 

برای تأیید این تنظیمات روی Enter کلیک کنید و بپذیرید که می خواهید وابستگی  ها را نصب کنید. این فرآیند اولیه نصب را آغاز می کند، جایی که یک فایل جدید به نام composer.json  که حاوی محتوای قبلی است در مخزن ما ایجاد می شود. یک پوشه فروشنده نیز ایجاد خواهد شد.

فایل  composer.json شامل جزئیات پروژه ی ما و وابستگی هایی است که ما داریم با  Composer مدیریت میکردیم،  در حالی که پوشه vendor  ایجاد میشود و شامل تمام کتابخانه  های موجود در وابستگی  های ما است. در اصل این همان چارچوب  PHPUnit است. 

پیکربندی PHPUnit برای جوملا

تست های واحد ما، اسکریپت هایی کوچک هستند که پاسخ ها را در کد اصلی ما بیان می کنند. بنابراین ما به مکانی برای ذخیره آنها نیاز داریم. برای این کار، ما یک پوشه به نام tests/Unit/  ایجاد می کنیم. این پوشه اصلی برای تست های واحد ما خواهد بود.

در توسعه افزونه های جوملا، ما معمولاً از متغیرها، کلاس ها و تعاریف جهانی از کد CMS ^TM جوملا استفاده می کنیم. این بدان معنی است که کد افزونه ما به ندرت خارج از جوملا کار می کند. تست های واحد کاملاً از کد CMS ^TM  جوملا جدا شده اند، بنابراین باید یک فایل Bootstrap اضافه کنیم تا به PHPUnit بگوییم کجا به دنبال تعاریف و کد بگردد. فایل Bootstrap را از مخزن مرتبط با این فصل دانلود کنید و آن را در  tests/Unit/bootstrap.php قرار دهید. کد به شکل زیر خواهد بود:

 
<?php 
define('_JEXEC', 1); 
error_reporting(E_ALL); 
ini_set('display_errors', 1); 
$rootDirectory = '/home/piedpiper/dev/joomla/'; 
if (!defined('JPATH_BASE')) { 
define('JPATH_BASE', $rootDirectory); 
} 
if (!defined('JPATH_ROOT')) { 
define('JPATH_ROOT', JPATH_BASE); 
} 
[LOTS OF EXTRA DEFINITIONS] 
if (!class_exists('JLoader')) { 
require_once JPATH_PLATFORM . '/loader.php'; 
// If JLoader still does not exist, panic. 
if (!class_exists('JLoader')) { 
throw new RuntimeException('Joomla Platform not 
loaded.'); 
} 
} 
JLoader::setup(); 
$loader = require JPATH_LIBRARIES . '/vendor/autoload.php'; 
class_exists('\\Joomla\\CMS\\Autoload\\ClassLoader'); 
$loader->unregister(); 
spl_autoload_register([new \Joomla\CMS\Autoload\ 
ClassLoader($loader), 'loadClass'], true, true); 
require_once JPATH_LIBRARIES . '/classmap.php'; 
require_once JPATH_LIBRARIES . '/namespacemap.php'; 
$extensionPsr4Loader = new \JNamespacePsr4Map(); 
$extensionPsr4Loader->load(); 
defined('JVERSION') or define('JVERSION', (new 
\Joomla\CMS\Version())->getShortVersion()); 

در اینجا، همه متغیرهای محیطی را که احتمالاً در کد افزونه خود استفاده می کنیم، تعریف می کنیم. در این فایل باید مقدار متغیر $rootDirectory  را در خط برجسته شده ویرایش کنیم. این متغیر باید مسیر سایت جوملا 4 نصب شده بر روی کامپیوتر شما را ذخیره کند.

پس از افزودن فایل bootstrap.php ، باید بهPHPUnit  بگوییم که از آن استفاده کند. برای انجام این کار، باید فایل phpunit.xml  را در ریشه پوشه اصلی مخزن خود با محتوای زیر ایجاد کنیم:

 
<?xml version="1.0" encoding="UTF-8"?> 
<phpunit bootstrap="tests/Unit/bootstrap.php" colors= 
"false"> 
<testsuites> 
<testsuite name="Unit"> 
<directory suffix="Test.php">./tests/Unit 
</directory> 
</testsuite> 
</testsuites> 
<php> 
<const name="JPATH_BASE" value="/home/ 
piedpiper/dev/joomla/" /> 
</php> 
</phpunit> 

این فایل XML به PHPUnit می گوید که کجا دستورالعمل های Bootstrap ما را پیدا کند. در بخش، مجموعه آزمایشی خود را Unit  نام گذاری می کنیم و از تگ  directory برای تعیین مسیری که تست های واحد ما قرار دارند، استفاده می کنیم. در این مورد، آن را به عنوان پوشه tests/Unit  خود تنظیم می کنیم. همچنین، با استفاده از ویژگی suffix ، به PHPUnit می گوییم که تمام تست های ما در داخل فایل هایی خواهد بود که به Test.php ختم می شوند.

در فایل phpunit.xml نیز ممکن است ثابت های PHP را تعریف کنیم. در این کد، ما ثابت JPATH_BASE  را برایPHP  تنظیم می کنیم. در این مورد، تعریف ثابت اختیاری است. اگر فایل bootstrap.php  قبلی را به دقت بررسی کنید، خواهید دید که ما کدی برای تعریف این ثابت در زمانی که تنظیم نشده است، داریم.

هنگامی که فایل Bootstrap را در جای خود قرار دادیم، می توانیم شروع به نوشتن اولین تست خود کنیم.

نوشتن اولین آزمون

ما قصد داریم، برای پلاگین SPM – Customers  که در فصل 8 نوشتیم آزمایشی را بنویسیم. در این پلاگین، ما روشی برای تعمیر پوسته ایمیل ها اضافه کردیم.

تا کنون، ما فقط دو الزام برای ساختار پوشه برای تست  های خود داریم:

1.       آنها باید داخل  tests/Unit باشند.

2.       نام فایل ها باید مشابه  NAMETest.php باشد.

اگر ما تست های خود را به شیوه ای منظم ایجاد کنیم و تکثیر محتوای پوشه  srcرا که کد ما در آن زندگی می کند، نتیجه خواهد داد. بنابراین، اجازه دهید با ایجاد فایل tests/Unit/Plugin/Spm/Customers/CustomersPluginTest.php با محتوای زیر شروع کنیم:

 
<?php 
namespace Piedpiper\Tests\Unit\Plugin\Spm\Customers\Extension; 
use Piedpiper\Plugin\Spm\Customers\Extension\Customers; 
use Joomla\CMS\Application\CMSWebApplicationInterface; 
use Joomla\Event\Dispatcher; 
use Joomla\Event\Event; 
class CustomersPluginTest extends \PHPUnit\Framework\ 
TestCase 
{ 
public function testFixCasing() 
{ 
$testString = 'HELLO@PIEDPIPER'; 
$testData = ['email' => $testString]; 
$event = new Event('test'); 
$event->setArgument('data', $testData); 
$app = $this->createStub(CMSWebApplicationInterface::class); 
$dispatcher = new Dispatcher(); 
$plugin = new Customers($dispatcher); 
$plugin->setApplication($app); 
$plugin->fixCasing($event); 
$resultData = $event->getArgument('data'); 
$this->assertEquals(strtolower($testData['email']), 
$resultData['email']); 
} 
} 

در این کد، اولین کاری که انجام می دهیم این است که فضای نام آزمایش خود را تعریف کنیم. این فضای نام با فضای نامی که در فایلcomposer.json  تعریف کردیم مطابقت دارد: (Piedpiper\Tests) 

 پس از آن، ساختار پوشه ای را داریم که فایل در آن قرار دارد. این همان چیزی است که در فضای نام تعریف شده است.

سپس، استفاده از کلاس پلاگین خود را که در Piedpiper\Plugin\Spm\Customers\Extension  است، اعلام می کنیم و در نهایت، کلاس های دیگری را که باید در کد خود استفاده کنیم، اعلام می کنیم.

نام کلاس ما با نام فایل ما مطابقت دارد و کلاس TestCase  استاندارد PHPUnit را گسترش می دهد تا از تمام متد هایی که برای آزمایش ارائه می کند، استفاده کند.

در نهایت، تست ما در یک متد از این کلاس اعلام می شود. نام این متد را هر چه بخواهیم، می توانیم بگذاریم، اما مرسوم است که نام آن را بعد از آزمایشی که می خواهیم انجام دهیم، می  گذاریم.

در این متد باید حداقل محیطی را برای اجرای تست ایجاد کنیم. تست  های واحد نیازی به وب سرور یا پایگاه داده ندارند، زیرا منطق کد شما را بررسی می کنند، اما زمانی که کد خود را در یک CMS بزرگ مانند جوملا اجرا می کنیم، معمولاً از برخی متغیرها و قرارداد هایی استفاده می کنیم که باید برای PHPUnit تعریف کنیم.

به طور خاص، متد  fixCasingکه می خواهیم تست کنیم از آبجکت $event  پلاگین، برای دریافت داده  های ایمیل استفاده می کند. باید این آبجکت $event  را تکثیر کنیم و آرگومان $data  را که می خواهیم تست کنیم، به آن اختصاص دهیم.

در مرحله بعد، باید کلاس پلاگین را نمونه سازی کنیم و آبجکت  $app را اختصاص دهیم. هنگامی که ما آبجکت پلاگین خود را داریم، باید متد fixCasing را فراخوانی کنیم، در حالی که متغیر $event  را که شبیه سازی کرده ایم، ارسال می کنیم، گویی در حال ذخیره یک مشتری در backend  هستیم.

این پلاگین بدنه ی ثابت داخل ویژگی data از آبجکت $event  را بر میگرداند، بنابراین باید از متد  getArgument برای بازیابی آن استفاده کنیم.

در نهایت، ما باید از متد assertEquals  از PHPUnit استفاده کنید تا ببینید آیا رشته اولیه با حروف کوچک است و رشته به دست آمده یکسان است.

این تست خیلی خوب به نظر می رسد. ما نیاز داریم آن را اجرا کنیم تا ببینیم، کار می کند یا خیر.

اولین تست خود را اجرا میکنیم

هنگامی که تست های خود را آماده کردیم، می توانیم با استفاده از دستور phpunit  شروع به آزمایش کنیم.(که پس از اجرای composer init  ، نصب شد)

برای این کار باید به پوشه اصلی مخزن خود بروید و دستور زیر را تایپ کنید:

 
php./vendor/bin/phpunit 

اگر همین الان این کار را امتحان کنید، با خطایی مواجه خواهید شد، زیرا ما هنوز باید قبل از اجرای اولین آزمایش، تنظیماتی را در composer انجام دهیم.

ما باید کلاس های آزمایشی خود را با فضای نام آنها ترسیم کنیم، زیرا آنها در فایل bootstrap.xml  موجود نیستند.

نقشه برداری کلاس ها در  composer.json

فایل composer.json ما فقط لیستی از بسته ها برای نصب نیستند. این فایل همچنین حاوی دستورالعمل  هایی در مورد ساختار کد شما و حتی اسکریپت  های کوچکی است که می توانید اجرا کنید. این به تنظیم برخی از نام های مستعار کمک می کند و به PHPUnit می گوید که کلاس ها در کجا قرار دارند. بنابراین، ما قصد داریم فایل composer.json  را ویرایش کنیم. برای احترام به ساختار JSON، باید خطوط برجسته زیر را اضافه کنیم:

 
{ 
"name": "piedpiper/spm", 
"description": "A simple project management extension", 
"type": "project", 
"require-dev": { 
"phpunit/phpunit": "8.5.32" 
}, 
"license": "GPL v 2.0", 
"authors": [ 
{ 
"name": "Carlos Cámara", 
"email": "این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید" 
} 
], 
"require": {}, 
"autoload-dev": { 
"psr-4": { 
"Piedpiper\\Tests\\": "tests", 
} 
}, 
"scripts": { 
"test": "./vendor/bin/phpunit" 
} 
} 

با پیکربندی autoload-dev ، ما به PHPUnit می  گوییم که بین فضای نام ما و پوشه  ای که کد در آن قرار دارد، ارتباط هست. در این مورد، فضای نام Tests  خود را به پوشه  tests در مخزن خود نشان می دهیم. تنظیمات اسکریپت یک میانبر بسیار راحت ایجاد می کند. بنابراین، زمانی که می خواهیم تست های واحد خود را اجرا کنیم، فقط باید موارد زیر را بنویسیم:

 
composer test 

این بسیار راحت تر از نوشتن هر بار مسیر کامل به  phpunit است.

هنگامی که این تنظیم شد، ممکن است آزمایش خود را انجام دهیم. پیام زیر را دریافت خواهیم کرد:

 
Executing command (CWD): ./vendor/bin/phpunit 
PHPUnit 8.5.33 by Sebastian Bergmann and contributors. 
. 1 / 1 (100%) 
Time: 195 ms, Memory: 10.00 MB 

این به این معنی است که متد ما آزمون را با موفقیت پشت سر گذاشت و ما آماده رفتن هستیم. اگر با مشکل مواجه شدید، باید کد خود را دوباره بررسی کنید و ببینید چه خطایی وجود دارد که مانع از قبولی آزمون شود.

تست واحد برای متد های تست و منطق فایل های ما عالی است، اما طبق تعریف، فقط قطعات کوچک کد را به صورت ایزوله آزمایش می کند. پروژه های توسعه ما توسط این واحدهای کوچک کد تشکیل می شوند که با هم کار می کنند تا چیزهای بزرگتری ایجاد کنند. بنابراین، ما به راهی برای آزمایش توسعه خود به متدی یکپارچه تر نیاز داریم.

آن وقت است که تست های سیستم، عملی می شوند. در بخش بعدی، می خواهیم بررسی کنیم که چگونه می توانیم آزمایش  های سیستمی را برای تضمین یک محصول توسعه با کیفیت بالا شروع کنیم.

نحوه اضافه کردن تست سیستم در جوملا

تست سیستم (System testing) شامل یک مجموعه  ای از تست  ها که بررسی می کنند توسعه شما مطابق با مشخصات طراحی شده، مطابق انتظار عمل می کند. برای توسعه تست های سیستم، باید بدانید که سیستم چگونه باید کار کند و پس از انجام چندین عمل در سیستم خود، چه انتظاری دارید.

روش های مختلفی برای انجام تست سیستم وجود دارد. از تست دستی آسان تر است. شما سایت آزمایشی خود را دارید و باید به آزمایش توسعه خود به صورت دستی ادامه دهید. این دور از ایده آل است، زیرا ممکن است در آزمایشات خود دچار خطاها و حذفیات شوید. اما اگر فردی سیستماتیک باشید و تمام تست ها و نتایج خود را یادداشت کنید، می تواند بسیار موثر باشد. در هر صورت، زمانی که شما نیاز به تست در برابر چندین نسخه های مختلف PHP و جوملا دارید، این نوع تست بسیار زمان بر است و بهترین راه نیست.

تست خودکار سیستم، خود یک موضوع کامل است و می توان چندین کتاب در مورد آن نوشت. در این فصل، ما ساده ترین راه را انتخاب می کنیم و از چارچوب تست Codeception  استفاده می کنیم، با حداقل تنظیماتی که به ما کمک می کند تا آزمایش را سریع و موثر شروع کنیم.

نصب Codeception

درک کد یا Codeception یک چارچوب آزمایشی است که توسط چندین فریمورک PHP از جمله Symfony و Laravel استفاده می شود. تیم جوملا قبل از انتشار هر نسخه از آن استفاده می کند. Codeception به شما این امکان را می دهد که تست های خود را به عنوان یک برنامه PHP بنویسید و می تواند آن برنامه PHP را به یک تست واقعی با مرورگر وب تبدیل کند.

ما می توانیم Codeception  را با استفاده از Composer نصب کنیم، بنابراین باید به پوشه اصلی مخزن خود برویم و موارد زیر را تایپ کنیم:

 
composer require "codeception/codeception" --dev 

کد قبلی چارچوب تست را در پوشه مخزن ما نصب می کند. ما همچنین باید مرورگر PHP و ماژول asserts  را که برای اجرا نیاز دارد نصب کنیم، بنابراین باید دستورات زیر را در پوشه اصلی یا مخزن خود اجرا کنیم:

 
composer require "codeception/module-phpbrowser" --dev 
composer require "codeception/module-asserts" –dev 

وقتی این ماژول ها را نصب کردیم، می توانیم فایل پیکربندی را برای Codeception اضافه کنیم. در پوشه اصلی مخزن ما فایل codeception.yml  را با محتوای زیر اضافه کردیم:

 
# suite config 
suites: 
acceptance: 
actor: AcceptanceTester 
path: . 
modules: 
enabled: 
- PhpBrowser: 
url: https://j4.ddev.site 
- \Helper\Acceptance 
# add Codeception\Step\Retry trait to 
AcceptanceTester to enable retries 
step_decorators: 
- Codeception\Step\ConditionalAssertion 
- Codeception\Step\TryTo 
- Codeception\Step\Retry 
extensions: 
enabled: [Codeception\Extension\RunFailed] 
params: 
- env 
gherkin: [] 
# additional paths 
paths: 
tests: tests/Acceptance/tests 
output: tests/Acceptance/_output 
data: tests/Acceptance/_data 
support: tests/Acceptance/_support 
envs: tests/Acceptance/_envs 
settings: 
shuffle: false 
lint: true 

در این فایل. yaml مسیر محیط آزمایش خود در پارامتر url.  در این فایل، ما https://j4.ddev.site  را به عنوان URL سایت آزمایشی خود قرار داده ایم. شما باید آن را با URL واقعی خود جایگزین کنید. ما پوشه را طوری پیکربندی می کنیم که تست ها و نتایج ما را در قسمت paths  ذخیره کند. در این مورد، من از پوشه test/Acceptance  به عنوان پوشه اصلی برای تست های خود استفاده می کنم.

شایان ذکر است که در این مورد Codeception از مرورگری به نام  PhpBrowser استفاده می کند که یک web scraper[1] است.

اگر پروژه شما نیاز به تست تعاملات جاوا اسکریپت داشته باشد، باید بررسی کنید که آیا نیاز به نصب ماژول مرورگر دیگری مانند Chromedriver  یا GeckoDriver  دارید یا خیر.

همچنین یک فورک[2] PhpBrowser  وجود دارد که برای سایت هایی جوملا بهینه شده است! سایت هایی  به نام مرورگر جوملا کهتوسط (Joomla Browser) که توسط تیم جوملا نگهداری می شود! پروژه ^SM. . (می توانید در بخش خواندن بیشتر در مورد آن بیشتر بخوانید.)

هنگامی که همه چیز پیکربندی شد، می توانیم شروع به نوشتن تست های خود کنیم. ما باید تست های خود را در پوشه tests/Acceptance/tests/  اضافه کنیم زیرا این پوشه ای است که در فایل codeception.yml  در قسمت  paths در ویژگی tests  مشخص کرده ایم. ما باید یک فایل  php ایجاد کنیم که شامل یک کلاس با تمام تست های ما باشد، مشابه آنچه با تست های واحد انجام دادیم. بنابراین، بیایید فایل tests/Acceptance/tests/FirstCest.php  را با محتوای زیر ایجاد کنیم:

 
<?php 
class FirstCest 
{ 
public function frontpageWorks(AcceptanceTester $I) 
{ 
$I->amOnPage('/'); 
$I->see('Home'); 
} 
} 

در این کلاس، ما یک تست را تعریف می کنیم که بررسی می کند صفحه اول سرور آزمایشی ما کار می کند. ما ممکن است از هر نام کلاس یا نام فایلی که می خواهیم استفاده کنیم، اما استفاده از همان نام برای کلاس و نام فایل، تمرین خوبی است. همچنین مرسوم است که پسوند Cest  را به نام کلاس اضافه کنید، اگرچه لازم نیست.

داخل کلاس، برای هر آزمونی که می خواهیم انجام دهیم یک متد ایجاد کنیم. این متدها یک آبجکت AcceptanceTester  دریافت می کنند که شامل مجموعه متد هایی است که برای اجرای آزمایش های خود نیاز داریم. در مثال ما از متد  amOnPage برای رفتن به URL سایت آزمایشی خود و از متد  see برای نشان دادن رشته متنی که باید در صفحه باشد، استفاده می کنیم. یکی از چیزهای خوب در مورد کار با Codeception این است که ما برای یافتن عناصر در صفحه نیازی به استفاده از مشخصات پیچیده یا مسیرهای  DOM  (مخفف "Document Object Model" است. DOM یک مدل برنامه  نویسی برای اسناد HTML و XML است که به شما اجازه می دهد تا ساختار، محتوا و استایل  های یک صفحه وب را به صورت برنامه  نویسی تغییر دهید. به عبارت دیگر، DOM نمایشی از ساختار یک سند HTML یا XML به صورت یک درخت از گره  ها (nodes) است که هر گره نماینده یک بخش از سند است، مانند عناصر، ویژگی  ها و متن  ها.) نداریم. ما می توانیم از زبان طبیعی ساده برای یافتن عناصری که می خواهیم ببینیم، استفاده کنیم.

وقتی اولین متد تست خود را داشتیم، می توانیم به پوشه اصلی مخزن خود برویم و Codeception را با دستور زیر در ترمینال اجرا کنیم:

 
php ./vendor/bin/codecept run 

با این کار پیغام زیر صادر می شود :

 
Acceptance Tests (1) -------------------------------------- 
✔ FirstCest: Frontpage works (0.10s) 

در اینجا، ما می توانیم کلاس حاوی تست و آزمون تکمیل شده را ببینیم. توجه داشته باشید که نام آزمون نام متد ما است که به زبان طبیعی قالب بندی شده است. این به این دلیل است که ما متد را با فرمت camelCase نامگذاری کردیم و Codeception می تواند کلمات را تقسیم کند و فاصله های مورد نیاز را اضافه کند.

با آن، ما اولین آزمایش خود را با Codeception انجام دادیم، اما هنوز برای توسعه Simple Project Manager فایده ای ندارد. بنابراین، بیایید آزمایشی ایجاد کنیم که به آزمایش لیست ویژگی های پروژه ی ما کمک کند.

می توانیم آزمون را به  عنوان روش دیگری به کلاس FirstCest  خود اضافه کنیم، اما بیایید یک کلاس جدید ایجاد کنیم تا همه چیز سازماندهی شود. فایل tests/Acceptance/test/ProjectsViewCest.php  را با محتوای زیر ایجاد کنید:

 
<?php 
class ProjectsViewCest 
{ 
public function projectsViewWorks(AcceptanceTester $I) 
{ 
$I->amOnPage('/index.php/spm'); 
$I->seeElement('.card h2'); 
} 
} 

در این تست ابتدا به نمای پروژه خود می رویم. مسیر باید در سرور محلی ما وجود داشته باشد. در غیر این صورت، ما قادر به آزمایش آن نخواهیم بود.

وقتی که در صفحه هستیم، باید با استفاده از متد seeElement به دنبال عنصری از چیدمان خود بگردیم تا مسیر CSS عنصر را بررسی کنیم.

هنگام اجرایCodeception ، این پیام را خواهیم دید:

 
Acceptance Tests (2) ------------------------------------------------------------------ 
✔ FirstCest: Frontpage works (0.12s) 
✔ ProjectsViewCest: Projects view works (0.10s) 

Codeception، زمانی که با PhpBrowser استفاده می شود، بسیار قدرتمند است و حتی ممکن است از آن برای آزمایش فرم ها و آزمایش سایت خود در هنگام ورود به سیستم استفاده کنید. بیایید ببینیم چگونه می توانیم از آن برای آزمایش قسمت backend کامپوننت خود استفاده کنیم.

فایل tests/Acceptance/tests/AdminCustomersCest.php را با کلاس PHP زیر ایجاد کنید:

 
<?php 
class AdminCustomersCest 
{ 
public function customersTableExists 
(AcceptanceTester $I) 
{ 
$I->amOnPage('/administrator/index.php'); 
$I->fillField('Username', 'tester'); 
$I->fillField('Password', 'testerPassword12345#'); 
$I->click('Log in'); 
$I->amOnPage('/administrator/index.php?option= 
com_spm&view=customers'); 
$I->seeElement('table'); 
} 
} 

در این کلاس، مرورگر را به ناحیه ورود به سیستم مدیریت و از متد fillField برای تکمیل فرم ورود استفاده می کنیم. در این حالت از برچسب های فرم برای مطابقت با عنصر موجود در فرم استفاده می کنیم. می توانیم از نام فیلد (حساس به حروف بزرگ) نیز استفاده کنیم. در حالی که متد click  به دکمه Log in  در فرم ورود به سیستم backend  اشاره می کند، فرم را ارسال می کنیم.

پس از ورود، مرورگر را به صفحه مشتریان خود در backend  هدایت می کنیم و عنصر  <table> را در صفحه بررسی می کنیم.

اجرای Codeception اکنون به خروجی زیر منجر می شود:

 
Acceptance Tests (3) ----------------------------------- 
✔ AdminCustomersCest: Customers table exists works (0.41s) 
✔ FirstCest: Frontpage works (0.09s) 
✔ ProjectsViewCest: Projects view works (0.10s) 

این نتیجه نشان می دهد که آزمایشات ما موفقیت آمیز بوده است. ممکن است متوجه شوید که زمان آخرین آزمون کمی بیشتر از بقیه است. این منطقی است زیرا مراحل بیشتری دارد.

ما می توانیم به افزودن تست  های جدید به سایت ادامه دهیم و تمام ویژگی های توسعه خود را با این تست  های کاربردی پوشش دهیم. این تضمین می کند که پروژه های ما قوی  تر هستند و می توانیم فقط با تغییر پیکربندی وب سرور محلی، پیکربندی  های مختلف را بطور خودکار آزمایش کنیم.

تست واحد و تست سیستم، راه های عالی برای توسعه پروژه های قوی تر هستند که از تغییرات بروزرسانی  های نرم افزاری محافظت می شوند، اما هنگام توسعه یک پروژه وب، باید جنبه های دیگر مانند دسترسی را نیز آزمایش کنیم.

در بخش بعدی، خواهیم دید که چه استراتژی هایی را می توانیم به عنوان توسعه دهندگان برای ارائه پروژه های قابل دسترس، دنبال کنیم.

آزمایش دسترسی در افزونه های ما

وقتی با دسترسی آشنایی ندارید ، معمولاً آن را چیزی در نظر میگیرید که افراد دارای معلولیت به آن نیاز دارند. اما در هر زمانی از زندگی ما، همه در موقعیتی قرار می گیرند که محیط مناسب نیست و نمی توانند از حواس خود با تمام توان استفاده کنند. به عنوان مثال، زمانی که در حال چک کردن تلفن همراه خود در زیر نور مستقیم خورشید هستید یا هنگام برداشتن کیف خود در حین رانندگی هستید و نیاز به بررسی سریع مسیر در دستگاه خود دارید، فکر کنید. شما به یک رابط خوب نیاز دارید که به شما امکان می دهد در زیر کنتراست کم و با حداقل تعامل به درستی ببینید، زیرا فقط می توانید از یک دست به درستی استفاده کنید.

افسانه در مورد دسترسی در توسعه وب، این است که ارائه یک محصول قابل دسترس، بسیار گران است، و این به دور از واقعیت است. هنگامی که از استانداردهای فعلی وب پیروی می کنید و از HTML معنایی در ظاهر خود استفاده می کنید، می توانید به سطح بالایی از دسترسی دست پیدا کنید.

این افسانه احتمالاً از این واقعیت ناشی می شود که یک روش خودکار خوب برای آزمایش دسترسی وجود ندارد. در یک برنامه وب، قابلیت دسترسی به معنای کمک به انسان برای درک یک وب سایت است، بنابراین فقط افراد واقعی می توانند یک تست دسترسی کامل را انجام دهند.

همچنین، دسترس  پذیری باید در شرایط مختلف، آزمایش شود، بنابراین در برخی از وب  سایت ها، افزونه های شما قابل دسترسی خواهند بود و در وب  سایت های دیگر، ممکن است حاوی خطاهای دسترسی باشند.

با این حال، تست نیمه اتوماتیک بسیار بهتر از عدم آزمایش است. و همانطور که معمولاً اتفاق می افتد، بررسی این خطاها و گذراندن این تست ها به شما کمک می کند محصول بهتری را به کاربران خود ارائه دهید.

قبل از شروع آزمایش قابلیت دسترسی برای افزونه خود، باید بدانید که گذراندن تمام تست  هایی که در بخش های زیر می خواهیم بررسی کنیم، تضمینی برای دسترسی نیست. اما هر گونه خطای دسترسی که در حین آزمایش پیدا می کنید، مشکلی است که باید برای بهبود دسترسی به افزونه، آن را برطرف کنید.

قابلیت دسترسی به نحوه کدنویسی HTML حاصل بستگی دارد. بنابراین، ما باید شروع به بررسی HTML با استفاده از مرورگر وب خود کنیم و به چند ابزار اضافی که می توانیم برای آزمایش بهتر نصب کنیم، نگاه کنیم.

تست دسترسی با مرورگر شما

این روزها دو بازیگر اصلی در بازار مرورگرها وجود دارد: مرورگر کروم و مشتقات آن مقل (...Chromium, Edge,) و فایرفاکس و مشتقات آن مثل (Tor Browser, Pale Moon,…) . در هر دو خانواده، می توانید ابزارهایی را برای آزمایش خودکار دسترسی به توسعه خود بیابید.

برای شروع تست دسترسی، باید مرورگر وب مورد علاقه خود را انتخاب کرده و سایت آزمایشی خود را باز کنید. هنگام انجام آزمایش  های قبلی، نیازی به تنظیم خاصی برای سایت نداشتیم، اما از آنجایی که دسترسی به زمینه ی سایت بستگی دارد، باید سعی کنید آن را به بهترین زمینه ممکن تبدیل کنید، بنابراین توصیه کنم که شما از قالب های پیش فرض جوملا استفاده کنید، برای قسمت ادمین سایت از( Atum )  و برای نمایش وبسایت ( Cassiopeia )  را تنظیم کنید. هر دو قالب به سطوح بالایی از دسترسی دست پیدا می کنند، بنابراین هر خطایی که پیدا کنید احتمالاً به توسعه شما مربوط می شود.

هنگامی که در سایت آزمایشی خود هستید، می توانید صفحه پروژه های ما را آزمایش کنید. بنابراین، مرورگر خود را به https://yourtestingsite/index.php/spm  هدایت کنید و هنگامی که آماده شدید، با کلیک بر روی کلید F12 ، ابزار توسعه دهندگان مرورگر خود را باز کنید.

هنگام استفاده از گوگل کروم، باید به تب  Lighthouse ابزار Developer رفته و گزینه  Accessibility را در قسمت  Categories  علامت بزنید. وقتی آماده شدید، می توانید روی Analyze page load کلیک کنید، در این مرحله وب  سایت برای چندین پارامتر تجزیه و تحلیل می شود:

شکل 12.2 - تنظیمات برای تولید گزارش فانوس دریایی

پس از تکمیل این کار، با توجه به هر یک از دسته بندی هایی که آنالیز شده اند، نتیجه آزمون خود را دریافت خواهید کرد. وقتی روی Accessibility  کلیک می کنید، لیستی از مشکلات را در صفحه خود مشاهده می کنید. در مورد ما، با این مشکل مواجه می  شویم: Select elements do not have associated label elements (عناصر انتخابی دارای عناصر برچسب مرتبط نیستند)

 وقتی روی آن عنصر کلیک می کنید، یک کشو با جزئیات بیشتر از موضوع و یک اسکرین شات از عنصر مشاهده خواهید کرد. همچنین، هنگامی که ماوس را روی جزئیات می  برید، قسمت توهین  آمیز صفحه شما برجسته می شود. می توانید روی آن کلیک کنید و به کد خاصی در تب Elements  هدایت شوید.

هنگام استفاده فایرفاکس، شما می توانید Developer Tools خود را باز کرده و به تب Accessibility  بروید. این Accessibility فایرفاکس است. این بازرس دسترسی دو صفحه را نشان می دهد.

شکل 12.3 - تب Accessibility در فایرفاکس Developer Tools

پنجره سمت چپ شامل درخت دسترسی (Accessibility tree) است که HTML صفحه شما را در یک ساختار درختی لیست می کند و با تگ سند (document) شروع می شود. پنجره سمت راست ویژگی های عنصر علامت زده شده را نشان می دهد. در بالای پنجره ها، در سمت چپ، سه کنترل دارید:

• بررسی مشکلات (Check for issues) : این تنظیم مشکلاتی را که می خواهید در درخت دسترسی ببینید، کنترل می کند.
• شبیه سازی (Simulate) : این تنظیم، پارامترهای رنگی پنجره را با هر یک از ناتوانی های بینایی پیکربندی شده تنظیم می کند. این یک راه عالی برای دیدن پیشرفت شما به همان شیوه افرادی است که نمی توانند کنتراست را در جزئیات درک کنند.
• نمایش ترتیب زبانه ها (Show Tabbing Order) : این تنظیم کنترل می کند که افرادی که فقط از صفحه کلید استفاده می کنند چگونه در صفحه شما پیمایش کنند و ترتیب دسترسی به پیوندها و دکمه  های صفحه شما را نشان می  دهد.

در فایرفاکس، ما همچنین می توانیم صفحه پروژه های خود را مرور کنیم تا قابلیت دسترسی را آزمایش کنیم. هنگامی که در صفحه  https://yourtestingsite/index.php/spm  قرار گرفتید، بازرس دسترسی را باز کنید و بررسی مشکلات (Check for issues) را روی همه مسائل (All issues) تنظیم کنید. این کار جایگزین درخت دسترسی با تمام برگ های درخت می شود که مسائل دسترسی و توضیح مختصری از موضوع را ارائه می دهند.

ابزارهای مرورگر حداقل بررسی دسترسی را ارائه می دهند. در بخش مطالعه بیشتر این فصل، پیوندهایی به WAVE  و AX را خواهید یافت. اینها مجموعه ای از ابزارهای ارزیابی دسترسی هستند که می توانند به شما کمک کنند تا جلوتر بروید و بسیاری از جنبه های دسترسی را تجزیه و تحلیل کنید.

علاوه بر این تست های نیمه اتوماتیک، یک تست سریعی وجود دارد که می توانیم در توسعه وب خود انجام دهیم: تست صفحه کلید (keyboard testing). در این تست، مرورگر خود را به صفحه پروژه های خود https://yourtestingsite/index.php/spm هدایت میکنیم و سپس از کلید  Tab برای مرور صفحه استفاده می کنیم. شما باید بتوانید به تمام لینک ها، تب ها و دکمه های سایت خود دسترسی داشته باشید و روی آنها کلیک کنید. هنگامی که این امکان پذیر نیست، باید شاخص های تمرکز و ترتیب ناوبر خود را بررسی کنید. بخش خواندن بیشتر پیوندی با اطلاعات بیشتر در مورد این تکنیک ارائه می دهد.

 

منابع فصل

• می توانید اطلاعات بیشتر در مورد PHPUnit و روش های آن را در آدرس زیر بیابید:

https://phpunit.de/

• Composer یک وب سایت عالی با تمام منابعی که برای کسب اطلاعات بیشتر در مورد آن نیاز دارید، دارد:

 https://getcomposer.org/

• یک سند خوب در مورد درایور های وب Codeception در اسناد رسمی آنها وجود دارد :

 https://codeception.com/docs/modules/WebDriver

• با مراجعه به مخزن GitHub میتوانید درباره مرورگر جوملا اطلاعات بیشتری کسب کنید:

 https://github.com/joomla-projects/joomla-browser

• اسناد Codeception شامل تمام متدهایی است که برای کار با PhpBrowser  در دسترس هستند:

 https://codeception.com/docs/AcceptanceTests#PhpBrowser

• ابزارهای WAVE یک جعبه ابزار عالی برای بررسی دسترسی به توسعه  های وب ما است:

 https://wave.webaim.org/

• ابزارهای AX همچنین کمک بزرگی در تست دسترسی ارائه می کنند:

 https://www.deque.com/axe/

• WCAG مطالب مقدماتی خوبی را برای توسعه دهندگانی که می خواهند در مورد دسترسی بیشتر بدانند، ارائه می دهد:

 https://www.w3.org/WAI/roles/developers/

• دانشگاه متروپولیتن تورنتو یک کتاب الکترونیکی رایگان برای توسعه دهندگانی که می خواهند درباره دسترسی بیشتر بدانند ارائه می دهد:

 https://pressbooks.library.torontomu.ca/wafd/

• ممکن است یک راهنمای عالی در مورد تست صفحه کلید در وب سایت WCAG پیدا کنید:

 https://webaim.org/techniques/keyboard/#testing

• در مجله جوملا یک مقاله عالی در مورد تست سرتاسری وجود دارد :

 https://magazine.joomla.org/all-issues/june/end-to-end-testing-with-joomla-and-cypress