PHPUnit နှင့် PEST ကိုအသုံးပြု၍ ရိုးရှင်းသောဥပမာများဖြင့် Laravel တွင် စာမေးပွဲများပြုလုပ်နည်းကို လေ့လာပါ။

အလိုအလျောက်စမ်းသပ်မှုများ သို့မဟုတ် ယူနစ်စမ်းသပ်မှုများနှင့်ပတ်သက်လာလျှင် မည်သည့်ပရိုဂရမ်းမင်းဘာသာစကားဖြင့်မဆို ဆန့်ကျင်ဘက်ထင်မြင်ယူဆချက်နှစ်ခုရှိသည်။

• အချိန်ဖြုန်းခြင်း။
• မင်းမရှိရင် မလုပ်နိုင်ဘူး။

ထို့ကြောင့်၊ ဤဆောင်းပါးဖြင့်၊ အထူးသဖြင့် Laravel တွင် အလိုအလျောက်စမ်းသပ်ခြင်းစတင်ရန် မည်မျှလွယ်ကူကြောင်း သရုပ်ပြခြင်းဖြင့် ယခင်လူဟောင်းကို ယုံကြည်လာအောင် ကြိုးစားပါမည်။

ပထမဦးစွာ "ဘာကြောင့်" အကြောင်းကိုပြောကြစို့၊ ထို့နောက်မည်သို့လုပ်ဆောင်ပုံ၏ဥပမာအချို့ကိုကြည့်ကြပါစို့။

ကျွန်ုပ်တို့ ဘာကြောင့် အလိုအလျောက် စမ်းသပ်မှု လိုအပ်တာလဲ။

အလိုအလျောက် စမ်းသပ်မှုများသည် ကုဒ်၏ အစိတ်အပိုင်းများကို လုပ်ဆောင်ပြီး အမှားအယွင်းများကို သတင်းပို့ပါသည်။ အဲဒါတွေကို ဖော်ပြဖို့ အရိုးရှင်းဆုံးနည်းလမ်းပါ။ အက်ပ်တစ်ခုတွင် အင်္ဂါရပ်အသစ်တစ်ခုကို လွှင့်တင်ရန် စိတ်ကူးကြည့်ပါ၊ ထို့နောက်တွင် ကိုယ်ပိုင်စက်ရုပ်လက်ထောက်တစ်ဦးသည် ကုဒ်အသစ်သည် အင်္ဂါရပ်ဟောင်းများကို မချိုးဖျက်ဘဲ အင်္ဂါရပ်အသစ်ကို ကိုယ်တိုင်စမ်းသပ်မည်ကို စမ်းသပ်မည်ဖြစ်သည်။

ဤသည်မှာ အဓိကအားသာချက်ဖြစ်သည်- အင်္ဂါရပ်အားလုံးကို အလိုအလျောက် ပြန်လည်စမ်းသပ်ခြင်း ဖြစ်သည်။ ဒါက အပိုအလုပ်လို့ထင်ရပေမယ့် အဲဒါကို "စက်ရုပ်" လို့ မပြောဘူးဆိုရင်၊ ငါတို့က အဲဒါကို ကိုယ်တိုင်လုပ်သင့်တယ် မဟုတ်လား? 

သို့မဟုတ် ဝန်ဆောင်မှုအသစ်များသည် ၎င်းတို့အလုပ်လုပ်ခြင်းရှိ၊

အလိုအလျောက်စမ်းသပ်မှုများသည် ကျွန်ုပ်တို့အား အကျိုးကျေးဇူးများစွာကို ပေးနိုင်သည်-

• ကိုယ်တိုင်စမ်းသပ်ချိန်ကို သိမ်းဆည်းပါ။
• ၎င်းတို့သည် သင့်အား ဆုတ်ယုတ်မှုကို ရှောင်ရှားခြင်းဖြင့် အကောင်အထည်ဖော်သည့် လုပ်ဆောင်ချက်အသစ်နှင့် ပေါင်းစပ်လုပ်ဆောင်မှုများအတွက် အချိန်ကုန်သက်သာစေသည်။
• စွမ်းဆောင်ချက်အသစ်များနှင့် အကောင်အထည်ဖော်ပြီးသော အင်္ဂါရပ်အားလုံးဖြင့် ဤအကျိုးကျေးဇူးကို မြှောက်ပါ။
• ယခင်ဗားရှင်းသုံးမှတ်သည် ဗားရှင်းအသစ်တိုင်းတွင် သက်ရောက်မှုရှိသည်။
• ...

သင့်အပလီကေးရှင်းကို တစ်နှစ် သို့မဟုတ် နှစ်နှစ်အတွင်းတွင်၊ ယခင်နှစ်များကရေးထားသည့်ကုဒ်ကို မသိသော developer အသစ်များ၊ သို့မဟုတ် ၎င်းကို မည်သို့စမ်းသပ်ရမည်ကိုပင် မသိသောအဖွဲ့ရှိ developer အသစ်များဖြင့် စိတ်ကူးကြည့်ကြည့်ပါ။ 

ကျွန်ုပ်တို့၏ ပထမဆုံး အလိုအလျောက် စမ်းသပ်မှုများ

ပထမဆုံးလုပ်ဆောင်ရန် Laravel တွင် အလိုအလျောက်စမ်းသပ်ခြင်း။မည်သည့်ကုဒ်ကိုမျှ ရေးရန် မလိုအပ်ပါ။ ဟုတ်တယ်၊ မင်းပြောတာမှန်တယ်။ ကြိုတင်ထည့်သွင်းမှုတွင် အရာအားလုံးကို ပြင်ဆင်ပြီးဖြစ်သည်။defiပထမဆုံး အခြေခံ ဥပမာ အပါအဝင် Laravel ၏ ည။

Laravel ပရောဂျက်ကို ထည့်သွင်းပြီး ပထမဆုံးစမ်းသပ်မှုများကို ချက်ချင်းလုပ်ဆောင်နိုင်သည်-

laravel new project
cd project
php artisan test

၎င်းသည် သင့်ကွန်ဆိုးလ်တွင် ရလဒ်ဖြစ်သင့်သည်-

ကြိုကြည့်မယ်ဆိုရင်defiLaravel ည /testsကျွန်ုပ်တို့တွင် ဖိုင်နှစ်ခုရှိသည်။

tests/Feature/ExampleTest.php :

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

ဤနေရာတွင်ဖြစ်ပျက်နေသည်ကိုနားလည်ရန် မည်သည့် syntax ကိုမျှ သင်သိရန်မလိုအပ်ပါ- ပင်မစာမျက်နှာကိုဖွင့်ပြီး အခြေအနေကုဒ်ရှိမရှိစစ်ဆေးပါ။ HTTP è "200 OK"။

method name လို့လည်း ခေါ်တယ်။ 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 သည် TestCase ကို တိုးချဲ့သည့် PHP class တစ်ခုဖြစ်သည်။ PHPUnit ပါ
• အတန်းတစ်ခုစီတွင် သင်သည် နည်းလမ်းများစွာကို ဖန်တီးနိုင်ပြီး၊ များသောအားဖြင့် စမ်းသပ်ရန် အခြေအနေတစ်ခုအတွက် နည်းလမ်းတစ်ခုဖြစ်သည်။
• နည်းလမ်းတစ်ခုစီတွင် လုပ်ဆောင်မှု သုံးခုရှိသည်- အခြေအနေပြင်ဆင်မှု၊ ထို့နောက် လုပ်ဆောင်မှု ပြီးနောက် ရလဒ်သည် မျှော်လင့်ထားသည့်အတိုင်း ဟုတ်မဟုတ် စစ်ဆေးရန် (အတည်ပြု)

ဖွဲ့စည်းတည်ဆောက်ပုံအရ၊ သင်သိရန်လိုအပ်သည်မှာ၊ ကျန်အရာအားလုံးသည် သင်စမ်းသပ်လိုသည့် အတိအကျပေါ်တွင်မူတည်ပါသည်။

အချည်းနှီးသောစမ်းသပ်မှုအတန်းကိုဖန်တီးရန်၊ ဤ command ကိုရိုးရှင်းစွာလုပ်ဆောင်ပါ။

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);
    }
}

ယခုလည်း command ကို run ပါ 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 ရှိ မှတ်ပုံတင်ဖောင်ကုဒ်ကို စမ်းသပ်ခြင်း။

ကျွန်ုပ်တို့တွင် ဖောင်တစ်ခုရှိပြီး အမျိုးမျိုးသော အမှုအခင်းများကို စမ်းသပ်ရန် လိုအပ်သည်ဆိုပါစို့၊ မမှန်ကန်သော ဒေတာဖြင့် ပျက်ကွက်ခြင်း ရှိ၊ မရှိ စစ်ဆေးခြင်း၊ မှန်ကန်သော ထည့်သွင်းမှုဖြင့် အောင်မြင်ခြင်း ရှိ၊ မရှိ စစ်ဆေးခြင်း အစရှိသည်တို့ကို စစ်ဆေးပါသည်။

တရားဝင် starter အစုံ Laravel Breeze မှ ဈ ပါဝင်သည်။ ၎င်းအတွင်း လုပ်ဆောင်နိုင်စွမ်းကို စမ်းသပ်ခြင်း။. အဲဒီကနေ ဥပမာတချို့ကို ကြည့်ရအောင်။

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(). တရားဝင်စာရွက်စာတမ်းများတွင် ရရှိနိုင်သော အခိုင်အမာပြောဆိုချက်အားလုံးကို သင်စစ်ဆေးနိုင်ပါသည်။ PHPUnit ပါ e Laravel တုံ့ပြန်မှု . အကြောင်းအရာနှင့် ပတ်သက်၍ ယေဘုယျပြောဆိုချက်အချို့ ဖြစ်ပေါ်လာသည်ကို သတိပြုပါ။ $thisအချို့က သီးခြားစစ်ဆေးနေချိန်တွင်၊ $responseလမ်းကြောင်းခေါ်ဆိုမှုမှ။

နောက်အရေးကြီးတာတစ်ခုကတော့ use RefreshDatabase;အတန်းအထက်တွင် လေဖြတ်ခြင်းနှင့်အတူ ထုတ်ပြန်ချက်၊ ဤဥပမာတွင်၊ လော့ဂ်လုပ်ခြင်းသည် ဒေတာဘေ့စ်ကို သက်ရောက်မှုရှိစေသောအခါတွင်၊ စစ်ဆေးမှုသည် လိုအပ်ပါသည်။ usersဒေတာဘေ့စ်ဇယား။ ၎င်းအတွက်၊ သင်သည် သီးခြားစမ်းသပ်ဒေတာဘေ့စ်တစ်ခုကို ဖန်တီးသင့်သည်။ php artisan migrate:freshစာမေးပွဲတွေ ပြီးတိုင်း

သင့်တွင် ရွေးချယ်စရာ နှစ်ခုရှိသည်- သီးခြားဒေတာဘေ့စ်တစ်ခု ဖန်တီးပါ သို့မဟုတ် မမ်မိုရီ SQLite ဒေတာဘေ့စ်ကို အသုံးပြုပါ။ ဖိုင်နှစ်ခုလုံးကို configure လုပ်ထားသည်။ phpunit.xmlမူရင်းအားဖြင့် ပံ့ပိုးပေးသည်။definita တို့နဲ့ 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 ရှိပါက၊ အရိုးရှင်းဆုံးလုပ်ဆောင်ချက်မှာ အဆိုပါလိုင်းများကို မှတ်ချက်ပေးရုံသာဖြစ်ပြီး သင်၏စစ်ဆေးမှုများသည် ထို in-memory database နှင့် လုပ်ဆောင်မည်ဖြစ်သည်။

ဤစမ်းသပ်မှုတွင် သုံးစွဲသူသည် အောင်မြင်စွာ စစ်မှန်ကြောင်း အထောက်အထားပြပြီး မှန်ကန်သော ပင်မစာမျက်နှာသို့ ပြန်လည်ညွှန်းဆိုနိုင်သော်လည်း ဒေတာဘေ့စ်ရှိ အမှန်တကယ်ဒေတာကိုလည်း စမ်းသပ်နိုင်သည်။

ဤကုဒ်အပြင်-

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

သုံးလို့လည်းရပါတယ်။ ဒေတာဘေ့စ်စမ်းသပ်ပြောဆိုချက်များ ဤကဲ့သို့ တစ်ခုခုလုပ်ပါ။

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

Login page ၏ ဥပမာ

ယခု Laravel Breeze ဖြင့် Login စာမျက်နှာ၏ အခြားသော ဥပမာကို ကြည့်ကြပါစို့

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 သည် စက်ရုံကြိုတင်ကို ထုတ်လုပ်သည်။definita သည် မှားယွင်းသော အချက်အလက်များဖြင့် Userမော်ဒယ်၊ box ပြင်ပ။

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 ကိုယ်တိုင်က မည်မျှပြင်ဆင်ထားသည်ကို သင်တွေ့သည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့အတွက် စတင်စမ်းသပ်ရန် လွယ်ကူမည်လား။

အဲဒီတော့ execute လုပ်တယ်။ 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 ဂေဟစနစ်ပြင်ပတွင် အလိုအလျောက်စမ်းသပ်ခြင်း အမျိုးအစားများစွာရှိပါသည်။ ကဲ့သို့သော ဝေါဟာရများကို သင်ရှာတွေ့နိုင်သည်-

• ယူနစ်စစ်ဆေးမှုများ
• အင်္ဂါရပ်စမ်းသပ်ခြင်း။
• ပေါင်းစပ်စစ်ဆေးမှုများ
• လုပ်ဆောင်ချက်ဆိုင်ရာ စမ်းသပ်မှုများ
• အစမှအဆုံးစမ်းသပ်ခြင်း။
• လက်ခံစစ်ဆေးမှုများ
• မီးခိုးစမ်းသပ်မှုများ
• စသည်တို့

၎င်းသည် ရှုပ်ထွေးသည်ဟု ထင်ရပြီး ဤစမ်းသပ်မှုအမျိုးအစားများကြားမှ အမှန်တကယ် ကွဲပြားမှုများသည် တစ်ခါတစ်ရံတွင် မှုန်ဝါးနေပါသည်။ ထို့ကြောင့် Laravel သည် ဤရှုပ်ထွေးနေသော ဝေါဟာရအားလုံးကို ရိုးရှင်းစေပြီး ၎င်းတို့ကို ယူနစ်/အင်္ဂါရပ် နှစ်ခုအဖြစ် အုပ်စုဖွဲ့ထားသည်။

ရိုးရိုးရှင်းရှင်းပြောရလျှင် အင်္ဂါရပ်စမ်းသပ်မှုများသည် သင့်အပလီကေးရှင်းများ၏ အမှန်တကယ်လုပ်ဆောင်နိုင်စွမ်းကို လုပ်ဆောင်ရန်ကြိုးစားသည်- URL ကိုရယူပါ၊ API ကိုခေါ်ပါ၊ ဖောင်ဖြည့်ခြင်းကဲ့သို့အတိအကျအပြုအမူကိုအတုယူပါ။ အင်္ဂါရပ်စမ်းသပ်မှုများသည် အများအားဖြင့် လက်တွေ့ဘဝတွင် ပရောဂျက်အသုံးပြုသူတိုင်း ကိုယ်တိုင်လုပ်ဆောင်ကြသည့်အတိုင်း အလားတူ သို့မဟုတ် အလားတူလုပ်ဆောင်မှုများကို လုပ်ဆောင်သည်။

ယူနစ်စစ်ဆေးမှုများသည် အဓိပ္ပါယ်နှစ်မျိုးရှိသည်။ ယေဘူယျအားဖြင့်၊ အလိုအလျောက်စမ်းသပ်မှုတိုင်းကို "ယူနစ်စမ်းသပ်ခြင်း" ဟုခေါ်ပြီး လုပ်ငန်းစဉ်တစ်ခုလုံးကို "ယူနစ်စမ်းသပ်ခြင်း" ဟုခေါ်ဆိုနိုင်သည်။ သို့သော် လုပ်ဆောင်နိုင်စွမ်းနှင့် ယူနစ်နှင့် ဆက်စပ်မှုတွင်၊ ဤလုပ်ငန်းစဉ်သည် သီးခြားအများပြည်သူမဟုတ်သော ကုဒ်ယူနစ်တစ်ခုကို စမ်းသပ်ခြင်းအကြောင်းဖြစ်သည်။ ဥပမာအားဖြင့်၊ သင့်တွင် ဘောင်များပါသည့် စုစုပေါင်းမှာယူမှုစျေးနှုန်းကဲ့သို့ တစ်စုံတစ်ခုကို တွက်ချက်သည့်နည်းလမ်းဖြင့် Laravel အတန်းရှိသည်။ ထို့ကြောင့်၊ ယူနစ်စစ်ဆေးမှုသည် ကွဲပြားသောဘောင်များနှင့်အတူ ထိုနည်းလမ်း (ကုဒ်ယူနစ်) မှ မှန်ကန်သောရလဒ်များကို ပြန်ပေးမည်ဆိုသည်ကို ဖော်ပြမည်ဖြစ်သည်။

ယူနစ်စမ်းသပ်မှုတစ်ခုဖန်တီးရန်၊ အလံတစ်ခုထည့်ရန် လိုအပ်သည်-

php artisan make:test OrderPriceTest --unit

ထုတ်လုပ်လိုက်သောကုဒ်သည် ကြိုတင်ယူနစ်စမ်းသပ်မှုနှင့် အတူတူပင်ဖြစ်ပါသည်။defiLaravel စနစ်-

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 ပရောဂျက်များနှင့် ပတ်သက်၍ ကျွန်ုပ်၏ ကိုယ်ရေးကိုယ်တာ အတွေ့အကြုံအရ၊ စမ်းသပ်မှုအများစုသည် အင်္ဂါရပ်စမ်းသပ်မှုများမဟုတ်ဘဲ ယူနစ်စမ်းသပ်မှုများဖြစ်သည်။ ပထမဦးစွာ၊ သင်သည်သင်၏အပလီကေးရှင်းအလုပ်လုပ်သည်ရှိမရှိ၊ စစ်မှန်သောလူများအသုံးပြုပုံ၊

နောက်တစ်ခု၊ သင့်တွင် အထူးတွက်ချက်မှုများ သို့မဟုတ် ယုတ္တိဗေဒရှိပါက သင်လုပ်ဆောင်နိုင်သည်။ defiကန့်သတ်ချက်များဖြင့် ယူနစ်တစ်ခုအနေဖြင့် nire၊ သင်သည် ၎င်းအတွက် အထူးပြုလုပ်ထားသည့် ယူနစ်စမ်းသပ်မှုများကို ဖန်တီးနိုင်သည်။

တခါတရံတွင်၊ စာရေးစမ်းသပ်မှုများသည် ကုဒ်ကို သူ့ဘာသာသူ ပြုပြင်ပြီး ၎င်းကို ပိုမို “စမ်းသပ်နိုင်သည်” ဖြစ်စေရန် ပြန်လည်ပြင်ဆင်ရန် လိုအပ်သည်- ယူနစ်များကို အထူးအတန်းများ သို့မဟုတ် နည်းလမ်းများအဖြစ် ခွဲခြားထားသည်။

စာမေးပွဲများကို မည်သည့်အချိန်တွင်/မည်ကဲ့သို့လုပ်ဆောင်မည်နည်း။

ဤအရာကို အမှန်တကယ်အသုံးပြုခြင်းကား အဘယ်နည်း php artisan test၊ ဘယ်အချိန်မှာ ပြေးသင့်လဲ။

သင်၏လုပ်ငန်းလည်ပတ်မှုအပေါ်မူတည်၍ ကွဲပြားသောချဉ်းကပ်မှုများရှိသော်လည်း၊ ယေဘုယျအားဖြင့် သင်သည် စမ်းသပ်မှုအားလုံးသည် "အစိမ်းရောင်" (ဆိုလိုသည်မှာ အမှားအယွင်းမရှိ) ကို repository သို့မတွန်းပို့မီ နောက်ဆုံးကုဒ်အပြောင်းအလဲများကို မတွန်းပို့မီ သေချာရန် လိုအပ်ပါသည်။

ထို့နောက်၊ သင်သည် သင်၏လုပ်ငန်းတာဝန်ကို ပြည်တွင်း၌သာ လုပ်ဆောင်ပြီး၊ သင် ပြီးသွားသည်ဟု သင်ထင်သောအခါ၊ သင်သည် တစ်စုံတစ်ရာ မပျက်စီးကြောင်း သေချာစေရန် စမ်းသပ်မှုအချို့ကို လုပ်ဆောင်ပါ။ သင့်ကုဒ်သည် သင့်ယုတ္တိဗေဒတွင်သာမက ဟိုးရှေးရှေးတုန်းက ရေးသားခဲ့သော အခြားသူတစ်ဦး၏ကုဒ်တွင် အခြားအပြုအမူအချို့ကို မရည်ရွယ်ဘဲ ချိုးဖျက်သွားသည်ကို သတိရပါ။

အဲဒါကို နောက်ထပ်တစ်လှမ်း လှမ်းလိုက်ရင်တော့ အလိုအလျောက် ပြန်ဖြစ်သွားနိုင်ပါတယ်။ အများကြီး အရာများ။ အမျိုးမျိုးသော CI/CD ကိရိယာများဖြင့်၊ တစ်စုံတစ်ဦးမှ သတ်မှတ်ထားသော Git ဌာနခွဲသို့ ပြောင်းလဲမှုများကို တွန်းအားပေးသည့်အခါတိုင်း သို့မဟုတ် ထုတ်လုပ်မှုဌာနခွဲသို့ ကုဒ်ကို ပေါင်းစည်းခြင်းမပြုမီတွင် လုပ်ဆောင်ရန် စမ်းသပ်မှုများကို သင်သတ်မှတ်နိုင်ပါသည်။ အရိုးရှင်းဆုံး အလုပ်အသွားအလာမှာ Github လုပ်ဆောင်ချက်များကို အသုံးပြုရန်ဖြစ်သည်။ သီးခြားဗီဒီယိုတစ်ခု အဲဒါကို သက်သေပြတယ်။

ဘာကို စမ်းသပ်သင့်လဲ။

“စမ်းသပ်မှုလွှမ်းခြုံမှု” ဟုခေါ်သည့် မည်မျှကြီးမားသင့်သည်အပေါ် ကွဲပြားသောထင်မြင်ယူဆချက်များ ရှိသည်- ဖြစ်နိုင်ချေရှိသော လုပ်ဆောင်ချက်တိုင်းနှင့် စာမျက်နှာတိုင်းရှိ ကိစ္စရပ်တိုင်းကို စမ်းကြည့်ပါ သို့မဟုတ် အရေးကြီးဆုံးအပိုင်းများတွင် အလုပ်အား ကန့်သတ်ပါ။

တကယ်တော့၊ ဒီနေရာဟာ အမှန်တကယ်အကျိုးရှိဖို့ထက် အချိန်ပိုယူပြီး အလိုအလျောက်စမ်းသပ်မှုလို့ အစွပ်စွဲခံရသူတွေနဲ့ သဘောတူပါတယ်။ အသေးစိတ်တိုင်းအတွက် စာမေးပွဲများကို ရေးထားလျှင် ၎င်းသည် ဖြစ်နိုင်သည်။ ဆိုလိုသည်မှာ၊ သင်၏ပရောဂျက်အတွက် လိုအပ်နိုင်သည်- အဓိကမေးခွန်းမှာ “ဖြစ်နိုင်ချေရှိသော အမှားအယွင်း၏စျေးနှုန်းမှာ အဘယ်နည်း” ဖြစ်သည်။

တစ်နည်းဆိုရသော် "ဤကုဒ်မအောင်မြင်ပါက ဘာဖြစ်မည်နည်း" ဟု မေးခွန်းမေးခြင်းဖြင့် သင်၏စမ်းသပ်မှုအားထုတ်မှုများကို ဦးစားပေးလုပ်ဆောင်ရန် လိုအပ်ပါသည်။ သင့်ငွေပေးချေမှုစနစ်တွင် ချို့ယွင်းချက်များရှိနေပါက၊ ၎င်းသည် လုပ်ငန်းကို တိုက်ရိုက်အကျိုးသက်ရောက်မည်ဖြစ်သည်။ ထို့ကြောင့် သင်၏ အခန်းကဏ္ဍ/ခွင့်ပြုချက်များ၏ လုပ်ဆောင်နိုင်စွမ်း ပျက်သွားပါက၊ ၎င်းသည် ကြီးမားသော လုံခြုံရေး ပြဿနာဖြစ်သည်။

Matt Stauffer က ကွန်ဖရင့်တစ်ခုမှာ ပြောတာကို သဘောကျတယ်- "သူတို့ ပျက်ကွက်ရင် မင်းအလုပ်က ထုတ်ပစ်မယ့် အရာတွေကို အရင်ဆုံး စမ်းသပ်ရမယ်။" ဟုတ်ပါတယ် အဲဒါက ချဲ့ကားတာဘဲ၊ ဒါပေမယ့် မင်း စိတ်ကူးရလာတယ်၊ အရေးကြီးတဲ့အရာတွေကို အရင်စမ်းကြည့်ပါ။ ပြီးမှ တခြား features တွေရှိရင် အချိန်ရနိုင်ပါတယ်။

PEST- PHPUnit အတွက် အစားထိုးအသစ်

အထက်ဖော်ပြပါ ဥပမာများအားလုံးသည် Laravel အကြိုစမ်းသပ်ခြင်းကိရိယာကို အခြေခံထားသည်။defiည- PHPUnit ပါ . ဒါပေမယ့် နှစ်တွေကြာလာတာနဲ့အမျှ တခြားကိရိယာတွေက ဂေဟစနစ်မှာ ပေါ်လာပြီး နောက်ဆုံးပေါ်ရေပန်းစားတဲ့ ကိရိယာတစ်ခုဖြစ်ပါတယ်။ ပိုးမွှား . တရားဝင် Laravel ဝန်ထမ်းမှ ဖန်တီးထားသည်။ နူနိုမာဒူရို ၊ အထားအသိုကို ရိုးရှင်းစေရန် ရည်ရွယ်ပြီး စမ်းသပ်မှုများအတွက် ကုဒ်ရေးခြင်းကို ပိုမိုမြန်ဆန်စေသည်။

ခေါင်းအုံးအောက်မှာ ပြေးနေတယ်။ su PHPUnit၊ နောက်ထပ်အလွှာတစ်ခုအနေဖြင့်၊ အချို့သောကြိုတင်ထပ်ခါတလဲလဲအစိတ်အပိုင်းများကိုလျှော့ချရန်ကြိုးစားနေပါသည်။defiPHPUnit ကုဒ်၏နေ့။

ဥပမာတစ်ခုကိုကြည့်ရအောင်။ အကြိုအင်္ဂါရပ်စမ်းသပ်မှုအတန်းကိုသတိရပါ။defiLaravel တွင် ဆက်စပ်နေပါသလား။ ငါ မင်းကို သတိပေးမယ်

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 developer များကြားတွင် အတော်လေးရေပန်းစားသော်လည်း ၎င်းသည် ဤအပိုဆောင်းကိရိယာကိုအသုံးပြုပြီး ၎င်း၏ syntax နှင့် PHPUnit မှတ်စုကို လေ့လာရန်ရှိမရှိ သင့်ကိုယ်ပိုင်ဦးစားပေးဖြစ်သည်။

BlogInnovazione.it