ისწავლეთ როგორ გააკეთოთ ტესტები Laravel-ში მარტივი მაგალითებით, PHPUnit-ისა და PEST-ის გამოყენებით

რაც შეეხება ავტომატურ ტესტებს ან ერთეულ ტესტებს, ნებისმიერ პროგრამირების ენაზე, არსებობს ორი საპირისპირო მოსაზრება:

• Დროის დაკარგვა
• თქვენ არ შეგიძლიათ ამის გარეშე

ასე რომ, ამ სტატიით ჩვენ შევეცდებით დავარწმუნოთ პირველი, განსაკუთრებით იმის დემონსტრირებით, თუ რამდენად ადვილია ლარაველში ავტომატური ტესტირების დაწყება.

ჯერ „რატომ“-ზე ვისაუბროთ, შემდეგ კი ვნახოთ რამდენიმე მაგალითი.

რატომ გვჭირდება ავტომატური ტესტირება

ავტომატური ტესტები აწარმოებენ კოდის ნაწილებს და აცნობებენ შეცდომებს. ეს მათი აღწერის უმარტივესი გზაა. წარმოიდგინეთ, რომ აპლიკაციის ახალი ფუნქცია გამოვა, შემდეგ კი პერსონალური რობოტი ასისტენტი წავა და ხელით ამოწმებს ახალ ფუნქციას და ასევე ამოწმებს, არ არღვევს თუ არა ახალ კოდს ძველი ფუნქციები.

ეს არის მთავარი უპირატესობა: ხელახლა ტესტირება ყველა ფუნქცია ავტომატურად. ეს შეიძლება ჩანდეს დამატებით სამუშაოდ, მაგრამ თუ არ ეტყვით „რობოტს“ ამის გაკეთებას, ჩვენ უნდა გავაკეთოთ ეს ხელით, არა? 

ან ახალი ფუნქციები შეიძლება გამოქვეყნდეს ტესტირების გარეშე, მუშაობს თუ არა, იმ იმედით, რომ მომხმარებლები შეატყობინებენ შეცდომებს.

ავტომატურმა ტესტებმა შეიძლება მოგვცეს რამდენიმე უპირატესობა:

• დაზოგეთ ხელით ტესტირების დრო;
• ისინი საშუალებას გაძლევთ დაზოგოთ დრო როგორც ახალ განხორციელებულ ფუნქციაზე, ასევე კონსოლიდირებულ ფუნქციებზე რეგრესიის თავიდან აცილებით;
• გაამრავლეთ ეს სარგებელი ყველა ახალ ფუნქციაზე და უკვე დანერგილ ყველა ფუნქციაზე;
• წინა სამი პუნქტი ვრცელდება ყოველ ახალ ვერსიაზე;
• ...

შეეცადეთ წარმოიდგინოთ თქვენი აპლიკაცია ერთ ან ორ წელიწადში, გუნდში ახალი დეველოპერებით, რომლებმაც არ იციან წინა წლებში დაწერილი კოდი, ან თუნდაც როგორ შეამოწმონ იგი. 

ჩვენი პირველი ავტომატური ტესტები

პირველის შესასრულებლად ავტომატური ტესტირება Laravel-ში, თქვენ არ გჭირდებათ რაიმე კოდის დაწერა. დიახ, თქვენ სწორად წაიკითხეთ. ყველაფერი უკვე კონფიგურირებული და მომზადებულია წინასწარ ინსტალაციაშიdefinite of Laravel, პირველივე ძირითადი მაგალითის ჩათვლით.

შეგიძლიათ სცადოთ 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() იკითხებადი ტექსტი ხდება ტესტის შედეგების ნახვისას, უბრალოდ ხაზგასმული სიმბოლოს ინტერვალით შეცვლით.

ტესტები/ერთეული/ExampleTest.php :

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

როგორც ჩანს, ცოტა უაზროა, შეამოწმეთ ეს მართალია? 

კონკრეტულად ერთეულ ტესტებზე ცოტა მოგვიანებით ვისაუბრებთ. ახლა თქვენ უნდა გესმოდეთ, რა ხდება ზოგადად თითოეულ ტესტში.

• თითოეული სატესტო ფაილი საქაღალდეში /tests არის PHP კლასი, რომელიც აფართოებს TestCase-ს PHP ერთეული
• თითოეულ კლასში შეგიძლიათ შექმნათ მრავალი მეთოდი, ჩვეულებრივ ერთი მეთოდი სიტუაციის შესამოწმებლად
• თითოეული მეთოდის ფარგლებში არის სამი მოქმედება: სიტუაციის მომზადება, შემდეგ მოქმედება და შემდეგ გადამოწმება (დადასტურება) არის თუ არა შედეგი მოსალოდნელი.

სტრუქტურულად, ეს არის ყველაფერი, რაც თქვენ უნდა იცოდეთ, ყველაფერი დანარჩენი დამოკიდებულია ზუსტად იმ ნივთებზე, რის გამოც გსურთ.

ცარიელი ტესტი კლასის შესაქმნელად, უბრალოდ გაუშვით ეს ბრძანება:

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-ის მიერ მოიცავს ი ფუნქციონირების ტესტირება მასში. მოდით გადავხედოთ რამდენიმე მაგალითს იქიდან:

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(). თქვენ შეგიძლიათ შეამოწმოთ ყველა მტკიცება, რომელიც ხელმისაწვდომია ოფიციალურ დოკუმენტაციაში PHP ერთეული 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 ქმნის ქარხნის წინასწარ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),
        ];
    }
}

ხედავთ, რამდენ რამეს ამზადებს თავად ლარაველი, ასე რომ, ადვილი იქნება ჩვენთვის ტესტირების დაწყება?

ასე რომ, თუ აღვასრულებთ 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

გენერირებული კოდი იგივეა, რაც წინა ერთეულის ტესტი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 ფილიალში ან კოდის შერწყმამდე წარმოების ფილიალში. უმარტივესი სამუშაო პროცესი იქნება Github მოქმედებების გამოყენება, მე მაქვს ცალკე ვიდეო რაც ამას ამტკიცებს.

რა უნდა გამოსცადო?

არსებობს განსხვავებული მოსაზრებები იმის შესახებ, თუ რამდენად დიდი უნდა იყოს ეგრეთ წოდებული „სატესტო დაფარვა“: სცადეთ ყველა შესაძლო ოპერაცია და შემთხვევა ყველა გვერდზე, ან შეზღუდეთ სამუშაო ყველაზე მნიშვნელოვანი ნაწილებით.

ფაქტობრივად, სწორედ აქ ვეთანხმები ადამიანებს, რომლებიც ადანაშაულებენ ავტომატურ ტესტირებას იმაზე მეტი დროის დახარჯვაში, ვიდრე რეალური სარგებლის მიცემაში. ეს შეიძლება მოხდეს, თუ დაწერთ ტესტებს თითოეული დეტალისთვის. ამის თქმით, ეს შეიძლება მოითხოვოს თქვენს პროექტს: მთავარი კითხვაა „რა არის პოტენციური შეცდომის ფასი“.

სხვა სიტყვებით რომ ვთქვათ, თქვენ უნდა დააფიქსიროთ თქვენი ტესტირების მცდელობები პრიორიტეტული კითხვის დასმით "რა მოხდებოდა, თუ ეს კოდი ვერ მოხერხდა?" თუ თქვენს გადახდის სისტემას აქვს შეცდომები, ეს პირდაპირ გავლენას მოახდენს ბიზნესზე. ასე რომ, თუ თქვენი როლების/ნებართვების ფუნქციონირება დაირღვა, ეს უსაფრთხოების უზარმაზარი პრობლემაა.

მომწონს, როგორ თქვა მეთ შტაუფერმა კონფერენციაზე: „პირველ რიგში უნდა გამოსცადო ის, რაც, თუ ისინი ვერ მოხერხდება, სამსახურიდან გაგათავისუფლებენ“. რა თქმა უნდა, ეს გაზვიადებულია, მაგრამ თქვენ გესმით იდეა: ჯერ სცადეთ მნიშვნელოვანი რამ. შემდეგ კი სხვა ფუნქციები, თუ დრო გაქვთ.

PEST: PHPUnit-ის ახალი ალტერნატივა

ყველა ზემოთ მოყვანილი მაგალითი ეფუძნება Laravel-ის წინასწარი ტესტირების ხელსაწყოსdefinite: PHP ერთეული . მაგრამ წლების განმავლობაში ეკოსისტემაში სხვა ინსტრუმენტები გამოჩნდა და ერთ-ერთი უახლესი პოპულარულია PEST . შექმნილია Laravel-ის ოფიციალური თანამშრომლის მიერ ნუნო მადურო , მიზნად ისახავს სინტაქსის გამარტივებას, რაც ტესტებისთვის კოდის დაწერას კიდევ უფრო აჩქარებს.

ქუდის ქვეშ, ის ეშვება su PHPUnit, როგორც დამატებითი ფენა, უბრალოდ ცდილობს მინიმუმამდე დაიყვანოს რამდენიმე წინასწარ განმეორებადი ნაწილიdefiPHPUnit კოდის nite.

მოდით შევხედოთ მაგალითს. დაიმახსოვრე წინა ფუნქციის ტესტის კლასიdefiლარაველში ნაყიდი? შეგახსენებთ:

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