Իմացեք, թե ինչպես կատարել թեստեր Laravel-ում պարզ օրինակներով՝ օգտագործելով PHPUnit և PEST

Երբ խոսքը վերաբերում է ավտոմատացված թեստերին կամ միավորի թեստերին, ցանկացած ծրագրավորման լեզվում կա երկու հակադիր կարծիք.

• Ժամանակի վատնում
• Դուք չեք կարող անել առանց դրա

Այսպիսով, այս հոդվածով մենք կփորձենք համոզել առաջինին, հատկապես ցույց տալով, թե որքան հեշտ է սկսել ավտոմատացված թեստավորումը Laravel-ում:

Նախ խոսենք «ինչու»-ի մասին, իսկ հետո տեսնենք, թե ինչպես:

Ինչու մեզ պետք է ավտոմատացված թեստավորում

Ավտոմատացված թեստերը գործարկում են կոդի մասեր և հայտնում ցանկացած սխալ: Դա դրանք նկարագրելու ամենապարզ ձևն է: Պատկերացրեք, որ հավելվածում նոր գործառույթ բացեք, այնուհետև անձնական ռոբոտի օգնականը կգնա և ձեռքով փորձարկի նոր գործառույթը, միաժամանակ ստուգելով, թե արդյոք նոր կոդը չի խախտում հին գործառույթներից որևէ մեկը:

Սա հիմնական առավելությունն է՝ բոլոր հնարավորությունների ինքնաբերաբար փորձարկումը: Սա կարող է թվալ լրացուցիչ աշխատանք, բայց եթե դուք չեք ասում «ռոբոտին» անել դա, մենք պետք է դա անենք ձեռքով, այնպես չէ՞: 

Կամ նոր գործառույթները կարող են թողարկվել առանց փորձելու, թե արդյոք դրանք աշխատում են, հուսալով, որ օգտվողները կհայտնեն սխալների մասին:

Ավտոմատացված թեստերը կարող են մեզ տալ մի քանի առավելություններ.

• Խնայել ձեռքով փորձարկման ժամանակը;
• Դրանք թույլ են տալիս ժամանակ խնայել ինչպես նոր ներդրված, այնպես էլ համախմբված գործառույթների վրա՝ խուսափելով հետընթացից.
• Բազմապատկեք այս առավելությունը բոլոր նոր հնարավորություններով և արդեն իսկ ներդրված բոլոր հնարավորություններով.
• Նախորդ երեք կետերը վերաբերում են յուրաքանչյուր նոր տարբերակին.
• ...

Փորձեք պատկերացնել ձեր դիմումը մեկ-երկու տարուց՝ թիմում նոր մշակողների հետ, ովքեր չգիտեն նախորդ տարիներին գրված կոդը կամ նույնիսկ ինչպես փորձարկել այն: 

Մեր առաջին ավտոմատացված թեստերը

Առաջինը կատարելու համար ավտոմատացված թեստավորում Laravel-ում, ոչ մի կոդ գրելու կարիք չկա։ Այո, ճիշտ եք կարդացել: Ամեն ինչ արդեն կազմաձևված և պատրաստված է նախնական տեղադրման մեջdefinite of 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);
    }
}

Ձեզ հարկավոր չէ որևէ շարահյուսություն իմանալ՝ հասկանալու համար, թե ինչ է կատարվում այստեղ. բեռնեք գլխավոր էջը և ստուգեք՝ արդյոք կարգավիճակի կոդը 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 դաս է, որը ընդլայնում է TestCase of-ը PHPU միավոր
• Յուրաքանչյուր դասի ներսում դուք կարող եք ստեղծել մի քանի մեթոդներ, սովորաբար մեկ մեթոդ իրավիճակի փորձարկման համար
• Յուրաքանչյուր մեթոդի շրջանակներում կան երեք գործողություն՝ իրավիճակի նախապատրաստում, այնուհետև գործողություն և այնուհետև ստուգում (հաստատում), թե արդյոք արդյունքը սպասվածի նման է։

Կառուցվածքային առումով, դա այն ամենն է, ինչ դուք պետք է իմանաք, մնացած ամեն ինչ կախված է ճշգրիտ բաներից, որոնք ցանկանում եք փորձարկել:

Դատարկ թեստային դաս ստեղծելու համար պարզապես գործարկեք այս հրամանը.

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-ում գրանցման ձևի կոդի փորձարկում

Ենթադրենք, մենք ունենք ձև, և մենք պետք է փորձարկենք տարբեր դեպքեր. մենք ստուգում ենք, թե արդյոք այն ձախողվում է անվավեր տվյալներով, մենք ստուգում ենք, արդյոք այն հաջողվում է ճիշտ մուտքագրմամբ և այլն:

Պաշտոնական մեկնարկային հավաքածու Laravel Breeze-ի կողմից ներառում է i դրա ներսում ֆունկցիոնալության փորձարկում. Դիտարկենք մի քանի օրինակ այնտեղից.

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(). Դուք կարող եք ստուգել բոլոր պնդումները, որոնք առկա են պաշտոնական փաստաթղթերում PHPU միավոր e Laravel արձագանք . Նկատի ունեցեք, որ թեմայի վերաբերյալ որոշ ընդհանուր պնդումներ են տեղի ունենում $this, մինչդեռ մյուսները ստուգում են կոնկրետ $responseերթուղու զանգից։

Մեկ այլ կարևոր բան է use RefreshDatabase;հայտարարությունը, հարվածով, որը տեղադրված է դասի վերևում: Դա անհրաժեշտ է, երբ թեստային գործողությունները կարող են ազդել տվյալների բազայի վրա, ինչպես այս օրինակում, գրանցումն ավելացնում է նոր մուտք usersտվյալների բազայի աղյուսակ. Դրա համար դուք պետք է ստեղծեք առանձին թեստային տվյալների բազա, որը կթարմացվի php artisan migrate:freshամեն անգամ, երբ թեստերն անցկացվում են:

Դուք ունեք երկու տարբերակ՝ ֆիզիկապես ստեղծել առանձին տվյալների բազա կամ օգտագործել հիշողության մեջ SQLite տվյալների բազա: Երկուսն էլ կազմաձևված են ֆայլում phpunit.xmlլռելյայն տրամադրվածdefiնիտա հետ Լարավել. Մասնավորապես, ձեզ անհրաժեշտ է այս մասը.

<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-ը ստեղծում է գործարանային նախնական տարբերակըdefinita հետ կեղծ տվյալների համար 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 էկոհամակարգից դուրս, կան ավտոմատացված թեստավորման մի քանի տեսակներ: Դուք կարող եք գտնել այնպիսի տերմիններ, ինչպիսիք են.

• Միավոր թեստեր
• Առանձնահատկությունների փորձարկում
• Ինտեգրման թեստեր
• Ֆունկցիոնալ թեստեր
• End-to-end փորձարկում
• Ընդունման թեստեր
• Ծխի թեստեր
• և այլն:

Այն հնչում է բարդ, և այս տեսակի թեստերի միջև իրական տարբերությունները երբեմն լղոզվում են: Ահա թե ինչու 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 նախագծերի իմ անձնական փորձի, թեստերի ճնշող մեծամասնությունը Feature թեստեր են, այլ ոչ թե Unit թեստեր: Նախ, դուք պետք է ստուգեք, թե արդյոք ձեր հավելվածն աշխատում է, ինչպես իրական մարդիկ կօգտագործեն այն:

Հաջորդը, եթե դուք ունեք հատուկ հաշվարկներ կամ տրամաբանություն, կարող եք definire որպես միավոր, պարամետրերով, կարող եք հատուկ դրա համար ստեղծել միավորի թեստեր:

Երբեմն, թեստեր գրելը պահանջում է ինքնին փոփոխել կոդը և վերամշակել այն ավելի «փորձարկելի» դարձնելու համար՝ բաժանելով միավորները հատուկ դասերի կամ մեթոդների:

Ե՞րբ/ինչպես կատարել թեստերը:

Ո՞րն է սրա իրական օգտագործումը php artisan test, ե՞րբ պետք է գործարկել այն:

Կան տարբեր մոտեցումներ՝ կախված ձեր բիզնեսի աշխատանքային հոսքից, բայց, ընդհանուր առմամբ, դուք պետք է համոզվեք, որ բոլոր թեստերը «կանաչ» են (այսինքն՝ առանց սխալների), նախքան կոդի վերջին փոփոխությունները պահոց մղելը:

Այնուհետև դուք աշխատում եք տեղում ձեր առաջադրանքի վրա, և երբ կարծում եք, որ ավարտել եք, մի քանի թեստեր անցկացրեք՝ համոզվելու համար, որ ոչինչ չեք կոտրել: Հիշեք, որ ձեր կոդը կարող է սխալներ առաջացնել ոչ միայն ձեր տրամաբանության մեջ, այլև ակամա կոտրել ուրիշի կոդում վաղուց գրված որոշ այլ վարքագիծ:

Եթե ​​մի քայլ առաջ գնանք, ապա հնարավոր է ավտոմատացնել շատերը բաներ. Տարբեր CI/CD գործիքների միջոցով դուք կարող եք նշել թեստերը, որոնք պետք է գործարկվեն, երբ ինչ-որ մեկը փոփոխություններ է կատարում Git-ի որոշակի ճյուղում կամ նախքան կոդը միացնելը արտադրության ճյուղին: Ամենապարզ աշխատանքային հոսքը կլինի Github Actions-ի օգտագործումը, ես ունեմ առանձին տեսանյութ ինչը ապացուցում է դա:

Ի՞նչ պետք է փորձարկեք:

Տարբեր կարծիքներ կան այն մասին, թե որքան մեծ պետք է լինի այսպես կոչված «թեստային ծածկույթը». փորձեք ամեն հնարավոր գործողություն և դեպք յուրաքանչյուր էջում, կամ սահմանափակեք աշխատանքը ամենակարևոր մասերով:

Իրականում, այստեղ ես համաձայն եմ այն ​​մարդկանց հետ, ովքեր մեղադրում են ավտոմատացված թեստավորումն ավելի շատ ժամանակ հատկացնելու համար, քան իրական օգուտ տալու համար: Դա կարող է տեղի ունենալ, եթե յուրաքանչյուր մանրուքի համար թեստեր գրեք: Ասել է թե, դա կարող է պահանջվել ձեր նախագծի կողմից. հիմնական հարցն է «որն է հավանական սխալի գինը»:

Այլ կերպ ասած, դուք պետք է առաջնահերթություն տաք ձեր փորձարկման ջանքերին՝ տալով «Ի՞նչ կլիներ, եթե այս կոդը ձախողվեր» հարցը: Եթե ​​ձեր վճարային համակարգը սխալներ ունի, դա ուղղակիորեն կազդի բիզնեսի վրա: Այսպիսով, եթե ձեր դերերի/թույլտվությունների ֆունկցիոնալությունը խախտված է, սա անվտանգության հսկայական խնդիր է:

Ինձ դուր է գալիս, թե ինչպես է Մեթ Ստաուֆերը դա արտահայտել կոնֆերանսի ժամանակ. «Դուք նախ պետք է փորձեք այն բաները, որոնք, եթե դրանք ձախողվեն, կհեռացնեն ձեզ աշխատանքից»: Իհարկե, դա չափազանցություն է, բայց դուք հասկացաք. նախ փորձեք կարևոր բաները: Եվ հետո այլ հնարավորություններ, եթե ժամանակ ունեք:

PEST. PHPUnit-ի նոր այլընտրանք

Վերոնշյալ բոլոր օրինակները հիմնված են Laravel-ի նախնական փորձարկման գործիքի վրաdefiգիշերը: PHPU միավոր . Սակայն տարիների ընթացքում էկոհամակարգում հայտնվեցին այլ գործիքներ, և ամենահայտնիներից մեկն այն է Վնասատու . Ստեղծվել է Laravel-ի պաշտոնական աշխատակցի կողմից Նունո Մադուրո , նպատակ ունի պարզեցնել շարահյուսությունը՝ ավելի արագ դարձնելով թեստերի կոդ գրելը։

Կափարիչի տակ, այն անցնում է su PHPUnit, որպես լրացուցիչ շերտ, պարզապես փորձում է նվազագույնի հասցնել որոշ նախապես կրկնվող մասերdefiPHPUnit կոդը:

Դիտարկենք մի օրինակ։ Հիշեք խաղարկային թեստի նախնական դասըdefiտեղավորված է Laravel-ում? Ես ձեզ հիշեցնեմ.

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