PHPUnit اور PEST کا استعمال کرتے ہوئے آسان مثالوں کے ساتھ Laravel میں ٹیسٹ کرنے کا طریقہ سیکھیں۔

جب خودکار ٹیسٹ یا یونٹ ٹیسٹ کی بات آتی ہے، کسی بھی پروگرامنگ زبان میں، دو مخالف آراء ہوتی ہیں:

• وقت کا ضیاع
• آپ اس کے بغیر نہیں کر سکتے

لہذا، اس مضمون کے ساتھ ہم سابقہ ​​کو قائل کرنے کی کوشش کریں گے، خاص طور پر یہ ظاہر کرتے ہوئے کہ Laravel میں خودکار جانچ کے ساتھ شروع کرنا کتنا آسان ہے۔

آئیے پہلے "کیوں" کے بارے میں بات کرتے ہیں، اور پھر آئیے اس کی کچھ مثالیں دیکھتے ہیں۔

ہمیں خودکار جانچ کی ضرورت کیوں ہے۔

خودکار ٹیسٹ کوڈ کے حصے چلاتے ہیں اور کسی بھی غلطی کی اطلاع دیتے ہیں۔ ان کو بیان کرنے کا یہ سب سے آسان طریقہ ہے۔ کسی ایپ میں ایک نئی خصوصیت کو رول آؤٹ کرنے کا تصور کریں، اور پھر ایک ذاتی روبوٹ اسسٹنٹ جائے گا اور دستی طور پر نئے فیچر کی جانچ کرے گا، جبکہ یہ بھی جانچے گا کہ آیا نئے کوڈ نے پرانی خصوصیات میں سے کسی کو توڑا ہے یا نہیں۔

یہ اہم فائدہ ہے: تمام خصوصیات کو خود بخود دوبارہ جانچنا۔ یہ اضافی کام لگتا ہے، لیکن اگر آپ "روبوٹ" کو ایسا کرنے کے لیے نہیں کہتے ہیں، تو ہمیں متبادل طور پر اسے دستی طور پر کرنا چاہیے، ٹھیک ہے؟ 

یا نئی خصوصیات کو جانچے بغیر جاری کیا جا سکتا ہے کہ آیا وہ کام کرتی ہیں، امید ہے کہ صارفین کیڑے کی اطلاع دیں گے۔

خودکار ٹیسٹ ہمیں کئی فوائد دے سکتے ہیں:

• دستی جانچ کے وقت کو بچائیں؛
• وہ آپ کو رجعت سے گریز کر کے لاگو کیے گئے نئے فنکشن اور مستحکم فنکشنز دونوں پر وقت بچانے کی اجازت دیتے ہیں۔
• اس فائدے کو تمام نئی خصوصیات اور پہلے سے نافذ تمام خصوصیات سے ضرب دیں۔
• پچھلے تین نکات ہر نئے ورژن پر لاگو ہوتے ہیں۔
• ...

ایک یا دو سال میں اپنی درخواست کا تصور کرنے کی کوشش کریں، ٹیم میں نئے ڈویلپرز کے ساتھ جو پچھلے سالوں میں لکھے گئے کوڈ کو نہیں جانتے، یا اس کی جانچ کیسے کی جائے۔ 

ہمارے پہلے خودکار ٹیسٹ

پہلے انجام دینے کے لیے Laravel میں خودکار جانچ، آپ کو کوئی کوڈ لکھنے کی ضرورت نہیں ہے۔ جی ہاں، آپ نے اسے صحیح پڑھا۔ سب کچھ پہلے سے ہی ترتیب دیا گیا ہے اور پہلے سے انسٹالیشن میں تیار ہے۔defiنائٹ آف لاراول، بشمول پہلی بنیادی مثال۔

آپ Laravel پروجیکٹ کو انسٹال کرنے کی کوشش کر سکتے ہیں اور فوری طور پر پہلے ٹیسٹ چلا سکتے ہیں:

laravel new project
cd project
php artisan test

یہ آپ کے کنسول میں نتیجہ ہونا چاہئے:

اگر ہم پری پر ایک نظر ڈالیں۔defiلاراویل کی رات /tests، ہمارے پاس دو فائلیں ہیں:

tests/Feature/ExampleTest.php :

class ExampleTest extends TestCase
{
    public function test_the_application_returns_a_successful_response()
    {
        $response = $this->get('/');
 
        $response->assertStatus(200);
    }
}

یہاں کیا ہو رہا ہے یہ سمجھنے کے لیے آپ کو کوئی نحو جاننے کی ضرورت نہیں ہے: ہوم پیج لوڈ کریں اور چیک کریں کہ اسٹیٹس کوڈ ہے یا نہیں۔ HTTP è "200 OK".

طریقہ کار کے نام سے بھی جانا جاتا ہے۔ test_the_application_returns_a_successful_response() جب آپ ٹیسٹ کے نتائج دیکھتے ہیں تو صرف انڈر لائن علامت کو اسپیس سے بدل کر پڑھنے کے قابل متن بن جاتا ہے۔

tests/Unit/ExampleTest.php :

class ExampleTest extends TestCase
{
    public function test_that_true_is_true()
    {
        $this->assertTrue(true);
    }
}

تھوڑا سا فضول لگتا ہے، یہ دیکھنے کے لیے کہ کیا یہ سچ ہے؟ 

ہم خاص طور پر یونٹ ٹیسٹ کے بارے میں تھوڑی دیر بعد بات کریں گے۔ ابھی کے لیے، آپ کو یہ سمجھنے کی ضرورت ہے کہ عام طور پر ہر ٹیسٹ میں کیا ہوتا ہے۔

• فولڈر میں ہر ٹیسٹ فائل /tests ایک پی ایچ پی کلاس ہے جو ٹیسٹ کیس کی توسیع کرتی ہے۔ پی ایچ پی یونٹ
• ہر کلاس کے اندر، آپ ایک سے زیادہ طریقے بنا سکتے ہیں، عام طور پر کسی صورت حال کو جانچنے کے لیے ایک طریقہ
• ہر طریقہ کے اندر تین اعمال ہوتے ہیں: صورت حال کی تیاری، پھر عمل اور پھر تصدیق (تصدیق) کہ آیا نتیجہ توقع کے مطابق ہے۔

ساختی طور پر، آپ کو بس اتنا ہی جاننے کی ضرورت ہے، باقی سب کچھ ان چیزوں پر منحصر ہے جن کی آپ جانچ کرنا چاہتے ہیں۔

خالی ٹیسٹ کلاس بنانے کے لیے، بس یہ کمانڈ چلائیں:

php artisan make:test HomepageTest

فائل تیار ہوتی ہے۔ tests/Feature/HomepageTest.php:

class HomepageTest extends TestCase
{
    // Replace this method with your own ones
    public function test_example()
    {
        $response = $this->get('/');
 
        $response->assertStatus(200);
    }
}

اب دیکھتے ہیں کہ Laravel میں ٹیسٹ کوڈ ناکام ہونے کی صورت میں کیا ہوتا ہے۔

آئیے اب دیکھتے ہیں کہ اگر ٹیسٹ کے دعوے متوقع نتیجہ واپس نہیں کرتے ہیں تو کیا ہوتا ہے۔

آئیے مثال کے ٹیسٹ کو اس میں تبدیل کریں:

class ExampleTest extends TestCase
{
    public function test_the_application_returns_a_successful_response()
    {
        $response = $this->get('/non-existing-url');
 
        $response->assertStatus(200);
    }
}
 
 
class ExampleTest extends TestCase
{
    public function test_that_true_is_false()
    {
        $this->assertTrue(false);
    }
}

اور اب، اگر ہم کمانڈ چلاتے ہیں۔ php artisan test دوبارہ:

 FAIL  Tests\Unit\ExampleTest
⨯ that true is true
 
 FAIL  Tests\Feature\ExampleTest
⨯ the application returns a successful response
 
---
 
• Tests\Unit\ExampleTest > that true is true
Failed asserting that false is true.
 
at tests/Unit/ExampleTest.php:16
   12▕      * @return void
   13▕      */
   14▕     public function test_that_true_is_true()
   15▕     {
➜  16▕         $this->assertTrue(false);
   17▕     }
   18▕ }
   19▕
 
• Tests\Feature\ExampleTest > the application returns a successful response
Expected response status code [200] but received 404.
Failed asserting that 200 is identical to 404.
 
at tests/Feature/ExampleTest.php:19
   15▕     public function test_the_application_returns_a_successful_response()
   16▕     {
   17▕         $response = $this->get('/non-existing-url');
   18▕
➜  19▕         $response->assertStatus(200);
   20▕     }
   21▕ }
   22▕
 
 
Tests:  2 failed
Time:   0.11s

دو ناکام ٹیسٹ ہیں، جنہیں FAIL کے طور پر نشان زد کیا گیا ہے، ذیل میں وضاحتیں اور تیر ناکام ہونے والے ٹیسٹوں کی درست لائن کی طرف اشارہ کرتے ہیں۔ غلطیوں کی نشاندہی اس طرح کی جاتی ہے۔

مثال: Laravel میں رجسٹریشن فارم کوڈ کی جانچ کرنا

فرض کریں کہ ہمارے پاس ایک فارم ہے اور ہمیں مختلف کیسز کی جانچ کرنے کی ضرورت ہے: ہم چیک کرتے ہیں کہ آیا یہ غلط ڈیٹا کے ساتھ ناکام ہوتا ہے، ہم چیک کرتے ہیں کہ آیا یہ صحیح ان پٹ وغیرہ کے ساتھ کامیاب ہوتا ہے۔

آفیشل اسٹارٹر کٹ بذریعہ لاریول بریز میں شامل ہیں اس کے اندر فعالیت کی جانچ کرنا. آئیے وہاں سے کچھ مثالیں دیکھتے ہیں:

tests/Feature/RegistrationTest.php

use App\Providers\RouteServiceProvider;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
 
class RegistrationTest extends TestCase
{
    use RefreshDatabase;
 
    public function test_registration_screen_can_be_rendered()
    {
        $response = $this->get('/register');
 
        $response->assertStatus(200);
    }
 
    public function test_new_users_can_register()
    {
        $response = $this->post('/register', [
            'name' => 'Test User',
            'email' => 'test@example.com',
            'password' => 'password',
            'password_confirmation' => 'password',
        ]);
 
        $this->assertAuthenticated();
        $response->assertRedirect(RouteServiceProvider::HOME);
    }
}

یہاں ہمارے پاس ایک کلاس میں دو ٹیسٹ ہیں، کیونکہ وہ دونوں رجسٹریشن فارم سے متعلق ہیں: ایک چیک کرتا ہے کہ آیا فارم صحیح طریقے سے لوڈ ہوا ہے اور دوسرا چیک کرتا ہے کہ آیا جمع کروانا ٹھیک کام کرتا ہے۔

آئیے نتیجہ کی تصدیق کے لیے دو مزید طریقوں سے واقف ہوں، دو مزید دعوے: $this->assertAuthenticated()e $response->assertRedirect(). آپ کی سرکاری دستاویزات میں دستیاب تمام دعووں کو چیک کر سکتے ہیں۔ پی ایچ پی یونٹ e لاریول رسپانس . نوٹ کریں کہ اس موضوع پر کچھ عمومی دعوے ہوتے ہیں۔ $this، جبکہ دوسرے مخصوص چیک کرتے ہیں۔ $responseروٹ کال سے

ایک اور اہم بات یہ ہے۔ use RefreshDatabase;بیان، اسٹروک کے ساتھ، کلاس کے اوپر داخل کیا گیا۔ یہ ضروری ہے جب ٹیسٹ کے اعمال ڈیٹابیس کو متاثر کر سکتے ہیں، جیسا کہ اس مثال میں، لاگنگ میں ایک نئی اندراج شامل ہوتی ہے۔ usersڈیٹا بیس ٹیبل. اس کے لیے، آپ کو ایک علیحدہ ٹیسٹ ڈیٹا بیس بنانا چاہیے جس کے ساتھ اپ ڈیٹ کیا جائے گا۔ php artisan migrate:freshہر بار ٹیسٹ چلائے جاتے ہیں۔

آپ کے پاس دو اختیارات ہیں: جسمانی طور پر ایک علیحدہ ڈیٹا بیس بنائیں یا ان میموری SQLite ڈیٹا بیس استعمال کریں۔ دونوں کو فائل میں ترتیب دیا گیا ہے۔ phpunit.xmlڈیفالٹ کی طرف سے فراہم کیdefiنیتا کے ساتھ Laravel. خاص طور پر، آپ کو اس حصے کی ضرورت ہے:

<php>
    <env name="APP_ENV" value="testing"/>
    <env name="BCRYPT_ROUNDS" value="4"/>
    <env name="CACHE_DRIVER" value="array"/>
    <!-- <env name="DB_CONNECTION" value="sqlite"/> -->
    <!-- <env name="DB_DATABASE" value=":memory:"/> -->
    <env name="MAIL_MAILER" value="array"/>
    <env name="QUEUE_CONNECTION" value="sync"/>
    <env name="SESSION_DRIVER" value="array"/>
    <env name="TELESCOPE_ENABLED" value="false"/>
</php>

دیکھیں DB_CONNECTIONe DB_DATABASEجن پر تبصرہ کیا جاتا ہے؟ اگر آپ کے سرور پر SQLite ہے تو، سب سے آسان عمل صرف ان لائنوں کو غیر تبصرہ کرنا ہے اور آپ کے ٹیسٹ اس ان میموری ڈیٹا بیس کے خلاف چلیں گے۔

اس ٹیسٹ میں ہم کہتے ہیں کہ صارف کی کامیابی سے تصدیق ہو گئی ہے اور اسے صحیح ہوم پیج پر بھیج دیا گیا ہے، لیکن ہم ڈیٹا بیس میں موجود اصل ڈیٹا کی جانچ بھی کر سکتے ہیں۔

اس کوڈ کے علاوہ:

$this->assertAuthenticated();
$response->assertRedirect(RouteServiceProvider::HOME);

ہم بھی استعمال کر سکتے ہیں۔ ڈیٹا بیس ٹیسٹ کے دعوے اور کچھ اس طرح کریں:

$this->assertDatabaseCount('users', 1);
 
// Or...
$this->assertDatabaseHas('users', [
    'email' => 'test@example.com',
]);

لاگ ان صفحہ کی مثال

آئیے اب Laravel Breeze کے ساتھ لاگ ان پیج کی ایک اور مثال دیکھتے ہیں۔

tests/Feature/AuthenticationTest.php:

class AuthenticationTest extends TestCase
{
    use RefreshDatabase;
 
    public function test_login_screen_can_be_rendered()
    {
        $response = $this->get('/login');
 
        $response->assertStatus(200);
    }
 
    public function test_users_can_authenticate_using_the_login_screen()
    {
        $user = User::factory()->create();
 
        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);
 
        $this->assertAuthenticated();
        $response->assertRedirect(RouteServiceProvider::HOME);
    }
 
    public function test_users_can_not_authenticate_with_invalid_password()
    {
        $user = User::factory()->create();
 
        $this->post('/login', [
            'email' => $user->email,
            'password' => 'wrong-password',
        ]);
 
        $this->assertGuest();
    }
}

یہ لاگ ان فارم کے بارے میں ہے۔ منطق رجسٹریشن کی طرح ہے، ٹھیک ہے؟ لیکن دو کے بجائے تین طریقے، تو یہ اچھے اور برے دونوں منظرناموں کی جانچ کی ایک مثال ہے۔ لہذا، عام منطق یہ ہے کہ آپ کو دونوں صورتوں کی جانچ کرنی چاہئے: جب چیزیں ٹھیک ہوتی ہیں اور کب وہ ناکام ہوتی ہیں۔

اس کے علاوہ، آپ اس ٹیسٹ میں کیا دیکھتے ہیں کا استعمال ہے ڈیٹا بیس فیکٹریاں : Laravel جعلی صارف بناتا ہے ( دوبارہ، آپ کے تازہ ترین ٹیسٹ ڈیٹا بیس پر ) اور پھر درست یا غلط اسناد کے ساتھ لاگ ان کرنے کی کوشش کرتا ہے۔

ایک بار پھر، Laravel فیکٹری پری پیدا کرتا ہے۔defiکے لئے جھوٹے ڈیٹا کے ساتھ nita Userماڈل، باکس کے باہر.

database/factories/UserFactory.php:

class UserFactory extends Factory
{
    public function definition()
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
            'remember_token' => Str::random(10),
        ];
    }
}

آپ نے دیکھا کہ Laravel خود کتنی چیزیں تیار کرتا ہے، تو کیا ہمارے لیے جانچ شروع کرنا آسان ہوگا؟

تو اگر ہم پھانسی دیتے ہیں۔ php artisan testLaravel Breeze کو انسٹال کرنے کے بعد، ہمیں کچھ اس طرح دیکھنا چاہئے:

 PASS  Tests\Unit\ExampleTest
✓ that true is true
 
 PASS  Tests\Feature\Auth\AuthenticationTest
✓ login screen can be rendered
✓ users can authenticate using the login screen
✓ users can not authenticate with invalid password
 
 PASS  Tests\Feature\Auth\EmailVerificationTest
✓ email verification screen can be rendered
✓ email can be verified
✓ email is not verified with invalid hash
 
 PASS  Tests\Feature\Auth\PasswordConfirmationTest
✓ confirm password screen can be rendered
✓ password can be confirmed
✓ password is not confirmed with invalid password
 
 PASS  Tests\Feature\Auth\PasswordResetTest
✓ reset password link screen can be rendered
✓ reset password link can be requested
✓ reset password screen can be rendered
✓ password can be reset with valid token
 
 PASS  Tests\Feature\Auth\RegistrationTest
✓ registration screen can be rendered
✓ new users can register
 
 PASS  Tests\Feature\ExampleTest
✓ the application returns a successful response
 
Tests:  17 passed
Time:   0.61s

یونٹ ٹیسٹ اور دیگر کے مقابلے میں فنکشنل ٹیسٹ

آپ نے ذیلی فولڈرز دیکھے ہیں۔ tests/Feature e tests/Unit ?. 

ان میں کیا فرق ہے؟ 

عالمی سطح پر، Laravel/PHP ماحولیاتی نظام سے باہر، خودکار جانچ کی کئی اقسام ہیں۔ آپ اصطلاحات تلاش کر سکتے ہیں جیسے:

• یونٹ ٹیسٹ
• فیچر ٹیسٹنگ
• انضمام کے ٹیسٹ
• فنکشنل ٹیسٹ
• اینڈ ٹو اینڈ ٹیسٹنگ
• قبولیت کے ٹیسٹ
• دھواں کے ٹیسٹ
• وغیرہ

یہ پیچیدہ لگتا ہے، اور اس قسم کے ٹیسٹوں کے درمیان اصل فرق کبھی کبھی دھندلا ہو جاتا ہے۔ یہی وجہ ہے کہ لاراول نے ان تمام مبہم اصطلاحات کو آسان بنایا ہے اور انہیں دو میں گروپ کیا ہے: یونٹ/خصوصیت۔

سیدھے الفاظ میں، فیچر ٹیسٹ آپ کی ایپلی کیشنز کی اصل فعالیت کو انجام دینے کی کوشش کرتے ہیں: URL حاصل کریں، API کو کال کریں، فارم کو پُر کرنے جیسے درست رویے کی نقل کریں۔ فیچر ٹیسٹ عام طور پر وہی یا اسی طرح کے کام انجام دیتے ہیں جیسا کہ کوئی پروجیکٹ صارف دستی طور پر، حقیقی زندگی میں کرتا ہے۔

یونٹ ٹیسٹ کے دو معنی ہیں۔ عام طور پر، آپ کو معلوم ہو سکتا ہے کہ کسی بھی خودکار ٹیسٹ کو "یونٹ ٹیسٹنگ" کہا جاتا ہے اور پورے عمل کو "یونٹ ٹیسٹنگ" کہا جا سکتا ہے۔ لیکن فعالیت بمقابلہ یونٹ کے تناظر میں، یہ عمل تنہائی میں، کوڈ کی ایک مخصوص غیر عوامی اکائی کی جانچ کے بارے میں ہے۔ مثال کے طور پر، آپ کے پاس ایک طریقہ کے ساتھ Laravel کلاس ہے جو کسی چیز کا حساب لگاتا ہے، جیسے پیرامیٹرز کے ساتھ کل آرڈر کی قیمت۔ لہذا، یونٹ ٹیسٹ یہ بتائے گا کہ آیا اس طریقہ (کوڈ یونٹ) سے مختلف پیرامیٹرز کے ساتھ صحیح نتائج واپس آئے ہیں۔

یونٹ ٹیسٹ بنانے کے لیے، آپ کو ایک جھنڈا شامل کرنا ہوگا:

php artisan make:test OrderPriceTest --unit

تیار کردہ کوڈ پری یونٹ ٹیسٹ جیسا ہی ہے۔defiلاریول سسٹم:

class OrderPriceTest extends TestCase
{
    public function test_example()
    {
        $this->assertTrue(true);
    }
}

جیسا کہ آپ دیکھ سکتے ہیں، یہ موجود نہیں ہے۔ RefreshDatabase، اور یہ ان میں سے ایک ہے۔ defiسب سے عام یونٹ ٹیسٹ کی تعریفیں: یہ ڈیٹا بیس کو نہیں چھوتا، یہ ایک "بلیک باکس" کے طور پر کام کرتا ہے، جو چل رہی ایپلیکیشن سے الگ تھلگ ہے۔

اس مثال کی نقل کرنے کی کوشش کرتے ہوئے جس کا میں نے پہلے ذکر کیا تھا، آئیے تصور کریں کہ ہمارے پاس سروس کلاس ہے۔ OrderPrice.

app/Services/OrderPriceService.php:

class OrderPriceService
{
    public function calculatePrice($productId, $quantity, $tax = 0.0)
    {
        // Some kind of calculation logic
    }
}

پھر، یونٹ ٹیسٹ کچھ اس طرح نظر آسکتا ہے:

class OrderPriceTest extends TestCase
{
    public function test_single_product_no_taxes()
    {
        $product = Product::factory()->create(); // generate a fake product
        $price = (new OrderPriceService())->calculatePrice($product->id, 1);
        $this->assertEquals(1, $price);
    }
 
    public function test_single_product_with_taxes()
    {
        $price = (new OrderPriceService())->calculatePrice($product->id, 1, 20);
        $this->assertEquals(1.2, $price);
    }
 
    // More cases with more parameters
}

Laravel پروجیکٹس کے ساتھ میرے ذاتی تجربے میں، ٹیسٹوں کی اکثریت فیچر ٹیسٹ ہیں، یونٹ ٹیسٹ نہیں۔ سب سے پہلے، آپ کو یہ جانچنے کی ضرورت ہے کہ آیا آپ کی درخواست کام کرتی ہے، جس طرح سے حقیقی لوگ اسے استعمال کریں گے۔

اگلا، اگر آپ کے پاس خاص حساب یا منطق ہے تو آپ کر سکتے ہیں۔ definire ایک یونٹ کے طور پر، پیرامیٹرز کے ساتھ، آپ خاص طور پر اس کے لیے یونٹ ٹیسٹ بنا سکتے ہیں۔

بعض اوقات، ٹیسٹ لکھنے کے لیے خود کوڈ میں ترمیم کرنے اور اسے مزید "ٹیسٹ ایبل" بنانے کے لیے ری فیکٹرنگ کی ضرورت ہوتی ہے: اکائیوں کو خصوصی کلاسوں یا طریقوں میں الگ کرنا۔

ٹیسٹ کب/کیسے کریں؟

اس کا اصل استعمال کیا ہے۔ php artisan testآپ کو اسے کب چلانا چاہئے؟

آپ کے کاروباری ورک فلو کے لحاظ سے مختلف طریقے ہیں، لیکن عام طور پر آپ کو یہ یقینی بنانے کی ضرورت ہوتی ہے کہ ریپوزٹری میں تازہ ترین کوڈ تبدیلیوں کو آگے بڑھانے سے پہلے تمام ٹیسٹ "سبز" (یعنی غلطی سے پاک) ہوں۔

اس کے بعد، آپ اپنے کام پر مقامی طور پر کام کرتے ہیں، اور جب آپ کو لگتا ہے کہ آپ نے کام کر لیا ہے، تو اس بات کو یقینی بنانے کے لیے کچھ ٹیسٹ چلائیں کہ آپ نے کچھ نہیں توڑا ہے۔ یاد رکھیں، آپ کا کوڈ نہ صرف آپ کی منطق میں بگ پیدا کر سکتا ہے بلکہ بہت پہلے لکھے گئے کسی اور کے کوڈ میں غیر ارادی طور پر کچھ دوسرے رویے کو بھی توڑ سکتا ہے۔

اگر ہم اسے ایک قدم آگے بڑھاتے ہیں تو یہ خودکار ہونا ممکن ہے۔ بہت چیزیں مختلف CI/CD ٹولز کے ساتھ، جب بھی کوئی شخص کسی مخصوص Git برانچ میں تبدیلیاں کرتا ہے یا کوڈ کو پروڈکشن برانچ میں ضم کرنے سے پہلے آپ ٹیسٹ چلانے کے لیے مخصوص کر سکتے ہیں۔ سب سے آسان ورک فلو گیتھب ایکشنز کو استعمال کرنا ہوگا، میرے پاس ہے۔ ایک الگ ویڈیو جو ثابت کرتا ہے.

آپ کو کیا ٹیسٹ کرنا چاہئے؟

اس بارے میں مختلف آراء ہیں کہ نام نہاد "ٹیسٹ کوریج" کتنی بڑی ہونی چاہیے: ہر ممکن آپریشن اور کیس کو ہر صفحے پر آزمائیں، یا کام کو انتہائی اہم حصوں تک محدود رکھیں۔

درحقیقت، یہیں پر میں ان لوگوں سے اتفاق کرتا ہوں جو خودکار جانچ پر اصل فائدہ فراہم کرنے سے زیادہ وقت لینے کا الزام لگاتے ہیں۔ یہ ہو سکتا ہے اگر آپ ہر ایک تفصیل کے لیے ٹیسٹ لکھیں۔ اس نے کہا، یہ آپ کے پروجیکٹ کے لیے درکار ہو سکتا ہے: اہم سوال یہ ہے کہ "ممکنہ غلطی کی قیمت کیا ہے"۔

دوسرے لفظوں میں، آپ کو یہ سوال پوچھ کر اپنی جانچ کی کوششوں کو ترجیح دینے کی ضرورت ہے کہ "اگر یہ کوڈ ناکام ہو گیا تو کیا ہوگا؟" اگر آپ کے ادائیگی کے نظام میں کیڑے ہیں، تو اس کا اثر براہ راست کاروبار پر پڑے گا۔ لہذا اگر آپ کے کردار/اجازت کی فعالیت ٹوٹ گئی ہے، تو یہ ایک بہت بڑا سیکیورٹی مسئلہ ہے۔

مجھے پسند ہے کہ میٹ سٹافر نے ایک کانفرنس میں یہ کیسے کہا: "آپ کو پہلے ان چیزوں کی جانچ کرنی چاہئے جو، اگر وہ ناکام ہو جائیں تو، آپ کو آپ کی ملازمت سے برطرف کر دیں گے۔" یقیناً یہ ایک مبالغہ آرائی ہے، لیکن آپ کو خیال آتا ہے: پہلے اہم چیزوں کو آزمائیں۔ اور پھر دوسری خصوصیات، اگر آپ کے پاس وقت ہے۔

PEST: PHPUnit کا نیا متبادل

مندرجہ بالا تمام مثالیں Laravel پری ٹیسٹنگ ٹول پر مبنی ہیں۔defiرات: پی ایچ پی یونٹ . لیکن کئی سالوں میں ماحولیاتی نظام میں دوسرے ٹولز نمودار ہوئے ہیں اور ایک تازہ ترین مقبول ہے۔ کیڑے . Laravel کے سرکاری ملازم کے ذریعہ تخلیق کیا گیا۔ نونو مادورو ، کا مقصد نحو کو آسان بنانا ہے، ٹیسٹ کے لیے تحریری کوڈ کو اور بھی تیز تر بنانا ہے۔

ہڈ کے نیچے، یہ چلتا ہے su PHPUnit، ایک اضافی پرت کے طور پر، صرف کچھ پہلے سے دہرائے جانے والے حصوں کو کم سے کم کرنے کی کوشش کر رہا ہے۔defiPHPUnit کوڈ کی نائٹ۔

آئیے ایک مثال دیکھتے ہیں۔ پری فیچر ٹیسٹ کلاس کو یاد رکھیںdefiLaravel میں nited؟ میں آپ کو یاد دلاؤں گا:

namespace Tests\Feature;
 
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
 
class ExampleTest extends TestCase
{
    public function test_the_application_returns_a_successful_response()
    {
        $response = $this->get('/');
 
        $response->assertStatus(200);
    }
}

کیا آپ جانتے ہیں کہ PEST کے ساتھ وہی ٹیسٹ کیسا نظر آئے گا؟

test('the application returns a successful response')->get('/')->assertStatus(200);

ہاں، کوڈ کی ایک لائن اور بس۔ لہذا، PEST کا ہدف ان کے اوور ہیڈ کو ہٹانا ہے:

• ہر چیز کے لیے کلاسز اور طریقے بنانا؛
• ٹیسٹ کیس کی توسیع؛
• کارروائیوں کو الگ الگ لائنوں پر رکھ کر: PEST میں آپ انہیں ایک ساتھ جوڑ سکتے ہیں۔

Laravel میں PEST ٹیسٹ بنانے کے لیے، آپ کو ایک اضافی جھنڈا متعین کرنا ہوگا:

php artisan make:test HomepageTest --pest

اس تحریر کے مطابق، PEST Laravel ڈویلپرز میں کافی مقبول ہے، لیکن یہ آپ کی ذاتی ترجیح ہے کہ آیا اس اضافی ٹول کو استعمال کرنا ہے اور اس کی نحو کے ساتھ ساتھ PHPUnit نوٹ بھی سیکھنا ہے۔

BlogInnovazione.it