เรียนรู้วิธีการทดสอบใน Laravel ด้วยตัวอย่างง่ายๆ โดยใช้ PHPUnit และ PEST

เมื่อพูดถึงการทดสอบอัตโนมัติหรือการทดสอบหน่วย ในภาษาการเขียนโปรแกรมใดๆ มีความคิดเห็นที่ขัดแย้งกันสองประการ:

• เสียเวลา
• คุณไม่สามารถทำได้หากไม่มีมัน

ดังนั้น ในบทความนี้ เราจะพยายามโน้มน้าวให้คนกลุ่มแรก โดยเฉพาะอย่างยิ่งด้วยการแสดงให้เห็นว่าการเริ่มต้นการทดสอบอัตโนมัติใน Laravel นั้นง่ายดายเพียงใด

ก่อนอื่นเรามาพูดถึง "ทำไม" ก่อน จากนั้นเรามาดูตัวอย่างบางส่วนของวิธีการกัน

เหตุใดเราจึงต้องมีการทดสอบอัตโนมัติ

การทดสอบอัตโนมัติเรียกใช้โค้ดบางส่วนและรายงานข้อผิดพลาดใดๆ นั่นเป็นวิธีที่ง่ายที่สุดในการอธิบายพวกเขา ลองนึกภาพการเปิดตัวฟีเจอร์ใหม่ในแอป จากนั้นผู้ช่วยหุ่นยนต์ส่วนตัวจะไปทดสอบฟีเจอร์ใหม่ด้วยตนเอง ขณะเดียวกันก็ทดสอบด้วยว่าโค้ดใหม่ไม่ทำลายฟีเจอร์เก่าใดๆ

นี่คือข้อได้เปรียบหลัก: การทดสอบคุณสมบัติทั้งหมดซ้ำโดยอัตโนมัติ นี่อาจดูเหมือนเป็นงานพิเศษ แต่ถ้าคุณไม่บอกให้ “หุ่นยนต์” ทำ เราก็ควรทำแบบ manual แทนใช่ไหม? 

หรือฟีเจอร์ใหม่อาจเปิดตัวโดยไม่ต้องทดสอบว่าใช้งานได้หรือไม่ โดยหวังว่าผู้ใช้จะรายงานจุดบกพร่อง

การทดสอบอัตโนมัติให้ข้อดีหลายประการแก่เรา:

• ประหยัดเวลาในการทดสอบด้วยตนเอง
• ช่วยให้คุณประหยัดเวลาทั้งกับฟังก์ชันใหม่ที่ใช้งานและฟังก์ชันที่รวมเข้าด้วยกัน โดยหลีกเลี่ยงการถดถอย
• ทวีคูณผลประโยชน์นี้ด้วยคุณสมบัติใหม่ทั้งหมดและคุณสมบัติทั้งหมดที่ใช้งานอยู่แล้ว
• สามประเด็นก่อนหน้านี้ใช้กับทุกเวอร์ชันใหม่
• ...

ลองจินตนาการถึงแอปพลิเคชันของคุณในหนึ่งปีหรือสองปี กับนักพัฒนาใหม่ในทีมที่ไม่รู้โค้ดที่เขียนในปีก่อนหน้า หรือแม้แต่วิธีทดสอบ 

การทดสอบอัตโนมัติครั้งแรกของเรา

เพื่อดำเนินการครั้งแรก การทดสอบอัตโนมัติใน Laravelคุณไม่จำเป็นต้องเขียนโค้ดใดๆ ใช่คุณอ่านถูกต้องแล้ว ทุกอย่างได้รับการกำหนดค่าและเตรียมไว้แล้วในการติดตั้งล่วงหน้าdefinite of Laravel รวมถึงตัวอย่างพื้นฐานแรกสุดด้วย

คุณสามารถลองติดตั้งโปรเจ็กต์ Laravel และรันการทดสอบแรกทันที:

laravel new project
cd project
php artisan test

นี่ควรเป็นผลลัพธ์ในคอนโซลของคุณ:

หากเราพิจารณาดูก่อนdefiคืนแห่ง Laravel /testsเรามีสองไฟล์:

การทดสอบ/คุณลักษณะ/ตัวอย่างTest.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() กลายเป็นข้อความที่อ่านง่ายเมื่อคุณดูผลการทดสอบ เพียงแค่แทนที่สัญลักษณ์ขีดเส้นใต้ด้วยการเว้นวรรค

การทดสอบ/หน่วย/ตัวอย่างTest.php :

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

ดูเหมือนไม่มีจุดหมายเลย ตรวจสอบดูว่าจริงหรือไม่? 

เราจะพูดถึง Unit Tests โดยเฉพาะในภายหลัง สำหรับตอนนี้ คุณต้องทำความเข้าใจว่าโดยทั่วไปแล้วจะเกิดอะไรขึ้นในการทดสอบแต่ละครั้ง

• แต่ละไฟล์ทดสอบในโฟลเดอร์ /tests เป็นคลาส PHP ที่ขยาย TestCase ของ PHPUnit
• ภายในแต่ละคลาส คุณสามารถสร้างได้หลายวิธี โดยปกติจะเป็นวิธีเดียวสำหรับสถานการณ์ที่จะทดสอบ
• ภายในแต่ละวิธีมีการดำเนินการ XNUMX ประการ คือ การเตรียมสถานการณ์ จากนั้น ดำเนินการ แล้วตรวจสอบ (ยืนยัน) ว่าผลลัพธ์เป็นไปตามที่คาดหวังหรือไม่

นั่นคือทั้งหมดที่คุณต้องรู้ในเชิงโครงสร้าง ส่วนอย่างอื่นขึ้นอยู่กับสิ่งที่คุณต้องการทดสอบ

หากต้องการสร้างคลาสทดสอบว่าง เพียงรันคำสั่งนี้:

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

มีการทดสอบที่ล้มเหลว XNUMX รายการ ทำเครื่องหมายว่า 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(). คุณสามารถตรวจสอบคำยืนยันทั้งหมดที่มีอยู่ในเอกสารอย่างเป็นทางการของ PHPUnit e การตอบสนองของ Laravel . โปรดทราบว่าการยืนยันทั่วไปบางอย่างเกิดขึ้นกับเรื่องนี้ $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นิต้ากับข้อมูลเท็จสำหรับ 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 testหลังจากติดตั้ง Laravel 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
    }
}

จากนั้น Unit Test อาจมีลักษณะดังนี้:

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 Actions ที่ฉันมี วิดีโอแยกต่างหาก ซึ่งพิสูจน์ได้

คุณควรทดสอบอะไร?

มีความคิดเห็นที่แตกต่างกันเกี่ยวกับว่าสิ่งที่เรียกว่า "ความครอบคลุมการทดสอบ" ควรมีขนาดใหญ่เพียงใด: ลองใช้การดำเนินการและตัวพิมพ์ทุกประการที่เป็นไปได้ในทุกหน้า หรือจำกัดงานให้เหลือเพียงส่วนที่สำคัญที่สุด

ที่จริงแล้ว นี่คือประเด็นที่ฉันเห็นด้วยกับผู้ที่กล่าวหาว่าการทดสอบอัตโนมัติใช้เวลามากกว่าการให้ผลประโยชน์ที่แท้จริง สิ่งนี้สามารถเกิดขึ้นได้หากคุณเขียนการทดสอบในทุกรายละเอียด อย่างไรก็ตาม โครงการของคุณอาจต้องการสิ่งนี้: คำถามหลักคือ “ราคาของข้อผิดพลาดที่อาจเกิดขึ้นคือเท่าไร”

กล่าวอีกนัยหนึ่ง คุณต้องจัดลำดับความสำคัญของความพยายามในการทดสอบโดยถามคำถาม “จะเกิดอะไรขึ้นหากรหัสนี้ล้มเหลว” หากระบบการชำระเงินของคุณมีข้อบกพร่อง ก็จะส่งผลโดยตรงต่อธุรกิจ ดังนั้นหากฟังก์ชันการทำงานของบทบาท/สิทธิ์ของคุณเสียหาย นี่ถือเป็นปัญหาด้านความปลอดภัยครั้งใหญ่

ฉันชอบวิธีที่ Matt Stauffer พูดในที่ประชุม: “ก่อนอื่นคุณต้องทดสอบสิ่งเหล่านั้นว่าหากล้มเหลวจะทำให้คุณถูกไล่ออกจากงาน” แน่นอนว่านั่นเป็นการพูดเกินจริง แต่คุณเข้าใจแล้ว: ลองทำสิ่งที่สำคัญก่อน แล้วคุณสมบัติอื่น ๆ หากคุณมีเวลา

PEST: ทางเลือกใหม่แทน PHPUnit

ตัวอย่างข้างต้นทั้งหมดขึ้นอยู่กับเครื่องมือทดสอบเบื้องต้นของ Laraveldefiไนท์: PHPUnit . แต่ในช่วงหลายปีที่ผ่านมา มีเครื่องมืออื่นๆ ปรากฏในระบบนิเวศ และหนึ่งในเครื่องมือยอดนิยมล่าสุดก็คือ ศัตรูพืช . สร้างโดยพนักงาน Laravel อย่างเป็นทางการ นูโน มาดูโร มีเป้าหมายเพื่อลดความซับซ้อนของไวยากรณ์ ทำให้การเขียนโค้ดสำหรับการทดสอบเร็วยิ่งขึ้น

ใต้ฝากระโปรงมันวิ่ง su PHPUnit เป็นเลเยอร์เพิ่มเติม เพียงพยายามย่อส่วนที่ทำซ้ำไว้ล่วงหน้าให้เหลือน้อยที่สุดdefiไนท์โค้ด PHPUnit

ลองดูตัวอย่าง จำคลาสการทดสอบคุณสมบัติเบื้องต้น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 คุณสามารถโยงการดำเนินการเหล่านั้นเข้าด้วยกันได้

ในการสร้างการทดสอบ PEST ใน Laravel คุณต้องระบุแฟล็กเพิ่มเติม:

php artisan make:test HomepageTest --pest

ในขณะที่เขียนบทความนี้ PEST ค่อนข้างได้รับความนิยมในหมู่นักพัฒนา Laravel แต่เป็นความชอบส่วนตัวของคุณว่าจะใช้เครื่องมือเพิ่มเติมนี้และเรียนรู้ไวยากรณ์ของมัน รวมถึงบันทึก PHPUnit หรือไม่

BlogInnovazione.it