Alamin kung paano gumawa ng mga pagsubok sa Laravel gamit ang mga simpleng halimbawa, gamit ang PHPUnit at PEST

Pagdating sa mga automated na pagsubok o unit test, sa anumang programming language, mayroong dalawang magkasalungat na opinyon:

• Sayang sa oras
• Hindi mo magagawa kung wala ito

Kaya, sa artikulong ito susubukan naming kumbinsihin ang una, lalo na sa pamamagitan ng pagpapakita kung gaano kadaling magsimula sa awtomatikong pagsubok sa Laravel.

Pag-usapan muna natin ang "bakit", at pagkatapos ay tingnan natin ang ilang halimbawa ng kung paano.

Bakit kailangan namin ng awtomatikong pagsubok

Ang mga awtomatikong pagsubok ay nagpapatakbo ng mga bahagi ng code at nag-uulat ng anumang mga error. Iyan ang pinakasimpleng paraan upang ilarawan ang mga ito. Isipin na maglulunsad ng bagong feature sa isang app, at pagkatapos ay pupunta ang isang personal na robot assistant at manu-manong susubukan ang bagong feature, habang sinusubukan din kung hindi sinira ng bagong code ang alinman sa mga lumang feature.

Ito ang pangunahing bentahe: awtomatikong sinusuri ang lahat ng mga tampok. Maaaring mukhang dagdag na trabaho ito, ngunit kung hindi mo sasabihin sa "robot" na gawin ito, dapat nating gawin ito nang manu-mano, tama ba? 

O maaaring ilabas ang mga bagong feature nang hindi sinusuri kung gumagana ang mga ito, umaasa na mag-uulat ang mga user ng mga bug.

Ang mga awtomatikong pagsubok ay maaaring magbigay sa amin ng ilang mga pakinabang:

• I-save ang manu-manong oras ng pagsubok;
• Hinahayaan ka nitong makatipid ng oras kapwa sa bagong function na ipinatupad at sa pinagsama-samang mga function sa pamamagitan ng pag-iwas sa regression;
• I-multiply ang benepisyong ito sa lahat ng bagong feature at lahat ng feature na naipatupad na;
• Ang nakaraang tatlong puntos ay nalalapat sa bawat bagong bersyon;
• ...

Subukang isipin ang iyong aplikasyon sa isang taon o dalawa, kasama ang mga bagong developer sa koponan na hindi alam ang code na nakasulat sa mga nakaraang taon, o kahit na kung paano ito subukan. 

Ang aming mga unang automated na pagsubok

Upang maisagawa ang una awtomatikong pagsubok sa Laravel, hindi mo kailangang magsulat ng anumang code. Oo, tama ang nabasa mo. Ang lahat ay na-configure na at inihanda sa pre-installationdefigabi ng Laravel, kasama ang pinakaunang pangunahing halimbawa.

Maaari mong subukang mag-install ng proyekto ng Laravel at patakbuhin kaagad ang mga unang pagsubok:

laravel new project
cd project
php artisan test

Ito dapat ang resulta sa iyong console:

Kung titingnan natin predefigabi ni Laravel /tests, mayroon kaming dalawang file:

tests/Feature/ExampleTest.php :

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

Hindi mo kailangang malaman ang anumang syntax upang maunawaan kung ano ang nangyayari dito: i-load ang home page at tingnan kung ang status code HTTP è "200 OK".

Kilala rin bilang pangalan ng pamamaraan test_the_application_returns_a_successful_response() nagiging nababasang teksto kapag tiningnan mo ang mga resulta ng pagsubok, sa pamamagitan lamang ng pagpapalit ng salungguhit na simbolo ng puwang.

tests/Unit/ExampleTest.php :

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

Mukhang medyo walang kabuluhan, tinitingnan kung totoo ito? 

Partikular na pag-uusapan natin ang tungkol sa mga unit test sa ibang pagkakataon. Sa ngayon, kailangan mong maunawaan kung ano ang karaniwang nangyayari sa bawat pagsubok.

• Ang bawat test file sa folder /tests ay isang PHP class na nagpapalawak ng TestCase ng PHPUnit
• Sa loob ng bawat klase, maaari kang lumikha ng maramihang mga pamamaraan, karaniwang isang paraan para sa pagsubok ng isang sitwasyon
• Sa loob ng bawat pamamaraan ay may tatlong aksyon: paghahanda ng sitwasyon, pagkatapos ay pagkilos at pagkatapos ay i-verify (kumpirmahin) kung ang kinalabasan ay tulad ng inaasahan

Sa istruktura, iyon lang ang kailangan mong malaman, lahat ng iba pa ay nakasalalay sa mga eksaktong bagay na gusto mong subukan.

Upang makabuo ng walang laman na klase ng pagsubok, patakbuhin lang ang command na ito:

php artisan make:test HomepageTest

Ang file ay nabuo 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);
    }
}

Ngayon tingnan natin kung ano ang mangyayari kung nabigo ang isang test code sa Laravel

Tingnan natin ngayon kung ano ang mangyayari kung hindi ibinalik ng mga assertion sa pagsubok ang inaasahang resulta.

Baguhin natin ang mga halimbawang pagsubok dito:

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

At ngayon, kung patakbuhin natin ang utos php artisan test muli:

 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

Mayroong dalawang nabigong pagsubok, na minarkahan bilang FAIL, na may mga paliwanag sa ibaba at mga arrow na tumuturo sa eksaktong linya ng mga pagsubok na nabigo. Ang mga error ay ipinahiwatig sa ganitong paraan.

Halimbawa: Pagsubok ng registration form code sa Laravel

Ipagpalagay na mayroon kaming isang form at kailangan naming subukan ang iba't ibang mga kaso: sinusuri namin kung nabigo ito sa hindi wastong data, tinitingnan namin kung nagtagumpay ito sa tamang input, atbp.

Ang opisyal na starter kit ni Laravel Breeze kasama ang i pagsubok sa functionality sa loob nito. Tingnan natin ang ilang mga halimbawa mula doon:

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

Narito mayroon kaming dalawang pagsubok sa isang klase, dahil pareho silang nauugnay sa form ng pagpaparehistro: ang isa ay nagsusuri kung ang form ay na-load nang tama at ang isa ay nagsusuri kung ang pagsusumite ay gumagana nang maayos.

Maging pamilyar tayo sa dalawa pang paraan para sa pag-verify ng resulta, dalawa pang assertion: $this->assertAuthenticated()e $response->assertRedirect(). Maaari mong suriin ang lahat ng mga pahayag na magagamit sa opisyal na dokumentasyon ng PHPUnit e LaravelResponse . Tandaan na ang ilang mga pangkalahatang pahayag ay nangyayari sa paksa $this, habang sinusuri ng iba ang partikular $responsemula sa tawag sa ruta.

Ang isa pang mahalagang bagay ay ang use RefreshDatabase;pahayag, na may stroke, na ipinasok sa itaas ng klase. Ito ay kinakailangan kapag ang mga pagsubok na aksyon ay maaaring makaapekto sa database, tulad ng sa halimbawang ito, ang pag-log ay nagdaragdag ng isang bagong entry sa userstalahanayan ng database. Para dito, dapat kang lumikha ng isang hiwalay na database ng pagsubok na ia-update sa php artisan migrate:freshsa bawat oras na ang mga pagsusulit ay tumatakbo.

Mayroon kang dalawang pagpipilian: pisikal na lumikha ng isang hiwalay na database o gumamit ng isang in-memorya na database ng SQLite. Parehong naka-configure sa file phpunit.xmlibinigay bilang defaultdefinita kasama Laravel. Sa partikular, kailangan mo ang bahaging ito:

<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>

Tingnan ang DB_CONNECTIONe DB_DATABASEalin ang nagkomento? Kung mayroon kang SQLite sa iyong server, ang pinakasimpleng aksyon ay ang alisin lamang sa komento ang mga linyang iyon at ang iyong mga pagsubok ay tatakbo laban sa in-memory na database na iyon.

Sa pagsubok na ito, sinasabi namin na ang user ay matagumpay na napatotohanan at na-redirect sa tamang homepage, ngunit maaari rin naming subukan ang aktwal na data sa database.

Bilang karagdagan sa code na ito:

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

Magagamit din natin ang mga pahayag ng pagsubok sa database at gawin ang isang bagay tulad nito:

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

Halimbawa ng Login page

Tingnan natin ngayon ang isa pang halimbawa ng isang Login page na may 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();
    }
}

Ito ay tungkol sa login form. Ang logic ay katulad ng pagpaparehistro, tama? Ngunit tatlong pamamaraan sa halip na dalawa, kaya ito ay isang halimbawa ng pagsubok sa parehong mabuti at masamang mga senaryo. Kaya, ang karaniwang lohika ay dapat mong subukan ang parehong mga kaso: kapag ang mga bagay ay maayos at kapag sila ay nabigo.

Gayundin, ang nakikita mo sa pagsusulit na ito ay ang paggamit ng Mga Pabrika ng Database : Lumilikha si Laravel ng pekeng user ( muli, sa iyong na-update na database ng pagsubok ) at pagkatapos ay sinusubukang mag-log in, na may tama o maling mga kredensyal.

Muli, nabuo ni Laravel ang factory predefinita na may maling data para sa Usermodelo, sa labas ng kahon.

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

Kita mo, kung gaano karaming mga bagay ang inihanda mismo ni Laravel, kaya magiging madali ba para sa amin na simulan ang pagsubok?

Kaya kung ipapatupad natin php artisan testpagkatapos i-install ang Laravel Breeze, dapat tayong makakita ng ganito:

 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

Mga functional na pagsubok kumpara sa mga pagsubok sa yunit at iba pa

Nakita mo na ang mga subfolder tests/Feature e tests/Unit ?. 

Ano ang pagkakaiba sa pagitan nila? 

Sa buong mundo, sa labas ng Laravel/PHP ecosystem, mayroong ilang uri ng automated na pagsubok. Makakahanap ka ng mga termino tulad ng:

• Mga pagsubok sa yunit
• Pagsubok sa tampok
• Mga pagsusulit sa pagsasama
• Mga functional na pagsubok
• End-to-end na pagsubok
• Mga pagsubok sa pagtanggap
• Mga pagsubok sa usok
• atbp.

Mukhang kumplikado, at ang mga aktwal na pagkakaiba sa pagitan ng mga uri ng mga pagsubok na ito ay minsan ay nuanced. Kaya naman pinasimple ni Laravel ang lahat ng nakalilitong terminong ito at pinag-grupo ang mga ito sa dalawa: unit/feature.

Sa madaling salita, sinusubukan ng mga feature test na isagawa ang aktwal na functionality ng iyong mga application: kunin ang URL, tawagan ang API, gayahin ang eksaktong gawi tulad ng pagsagot sa form. Ang mga feature na pagsubok ay karaniwang gumaganap ng pareho o katulad na mga operasyon gaya ng gagawin ng sinumang user ng proyekto, nang manu-mano, sa totoong buhay.

Ang mga pagsubok sa yunit ay may dalawang kahulugan. Sa pangkalahatan, maaari mong makita na ang anumang automated na pagsubok ay tinatawag na "unit testing" at ang buong proseso ay maaaring tawaging "unit testing". Ngunit sa konteksto ng functionality versus unit, ang prosesong ito ay tungkol sa pagsubok sa isang partikular na non-public unit ng code, sa paghihiwalay. Halimbawa, mayroon kang klase ng Laravel na may paraan na kinakalkula ang isang bagay, tulad ng kabuuang presyo ng order na may mga parameter. Samakatuwid, sasabihin ng unit test kung ibinalik ang mga tamang resulta mula sa pamamaraang iyon (unit ng code), na may iba't ibang mga parameter.

Para makabuo ng unit test, kailangan mong magdagdag ng flag:

php artisan make:test OrderPriceTest --unit

Ang nabuong code ay kapareho ng pre unit testdefiLaravel system:

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

Tulad ng nakikita mo, hindi ito umiiral RefreshDatabase, at ito ay isa sa defipinaka-karaniwang mga kahulugan ng pagsubok sa yunit: hindi nito hinawakan ang database, gumagana ito bilang isang "itim na kahon", na nakahiwalay sa tumatakbong application.

Sinusubukang gayahin ang halimbawang nabanggit ko kanina, isipin natin na mayroon tayong klase ng serbisyo OrderPrice.

app/Services/OrderPriceService.php:

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

Pagkatapos, maaaring ganito ang hitsura ng 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
}

Sa aking personal na karanasan sa mga proyekto ng Laravel, ang karamihan sa mga pagsubok ay mga pagsubok sa Tampok, hindi mga pagsubok sa Unit. Una, kailangan mong subukan kung gumagana ang iyong application, kung paano ito gagamitin ng mga totoong tao.

Susunod, kung mayroon kang mga espesyal na kalkulasyon o lohika maaari mo definire bilang isang yunit, na may mga parameter, maaari kang lumikha ng mga pagsubok sa yunit na partikular para doon.

Kung minsan, ang pagsusulat ng mga pagsusulit ay nangangailangan ng pagbabago sa mismong code at pag-refactor nito upang gawin itong mas "masusubok": paghihiwalay ng mga yunit sa mga espesyal na klase o pamamaraan.

Kailan/paano magsagawa ng mga pagsusulit?

Ano ang aktwal na gamit nito php artisan test, kailan mo ito dapat patakbuhin?

Mayroong iba't ibang mga diskarte, depende sa workflow ng iyong negosyo, ngunit sa pangkalahatan kailangan mong tiyakin na ang lahat ng mga pagsubok ay "berde" (ibig sabihin, walang error) bago itulak ang pinakabagong mga pagbabago sa code sa repository.

Pagkatapos, nagtatrabaho ka nang lokal sa iyong gawain, at kapag sa tingin mo ay tapos ka na, magpatakbo ng ilang pagsubok upang matiyak na wala kang nasira. Tandaan, ang iyong code ay maaaring magdulot ng mga bug hindi lamang sa sarili mong lohika ngunit hindi sinasadyang masira ang ilang iba pang pag-uugali sa code ng ibang tao na isinulat noong nakalipas na panahon.

Kung gagawin pa natin ito ng isang hakbang, posibleng mag-automate marami bagay. Sa iba't ibang tool ng CI/CD, maaari mong tukuyin ang mga pagsubok na tatakbo sa tuwing may magtutulak ng mga pagbabago sa isang partikular na sangay ng Git o bago pagsamahin ang code sa sangay ng produksyon. Ang pinakasimpleng daloy ng trabaho ay ang paggamit ng Github Actions, mayroon ako isang hiwalay na video na nagpapatunay nito.

Ano ang dapat mong subukan?

Mayroong iba't ibang mga opinyon sa kung gaano kalaki ang tinatawag na "test coverage" ay dapat: subukan ang bawat posibleng operasyon at kaso sa bawat pahina, o limitahan ang trabaho sa pinakamahalagang bahagi.

Sa katunayan, dito ako sumasang-ayon sa mga taong nag-aakusa ng automated na pagsubok ng mas maraming oras kaysa sa pagbibigay ng aktwal na benepisyo. Maaaring mangyari ito kung magsusulat ka ng mga pagsubok para sa bawat solong detalye. Iyon ay sinabi, maaaring kailanganin ito ng iyong proyekto: ang pangunahing tanong ay "ano ang presyo ng potensyal na error".

Sa madaling salita, kailangan mong unahin ang iyong mga pagsusumikap sa pagsubok sa pamamagitan ng pagtatanong ng tanong na "Ano ang mangyayari kung nabigo ang code na ito?" Kung may mga bug ang iyong sistema ng pagbabayad, direktang makakaapekto ito sa negosyo. Kaya kung nasira ang functionality ng iyong mga tungkulin/pahintulot, isa itong malaking isyu sa seguridad.

Gusto ko kung paano ito sinabi ni Matt Stauffer sa isang kumperensya: "Kailangan mo munang subukan ang mga bagay na, kung mabibigo ang mga ito, ay magpapatalsik sa iyo sa iyong trabaho." Siyempre pagmamalabis iyon, ngunit nakuha mo ang ideya: subukan muna ang mahahalagang bagay. At pagkatapos ay iba pang mga tampok, kung mayroon kang oras.

PEST: bagong alternatibo sa PHPUnit

Ang lahat ng mga halimbawa sa itaas ay batay sa Laravel pre testing tooldefigabi: PHPUnit . Ngunit sa paglipas ng mga taon iba pang mga tool ang lumitaw sa ecosystem at isa sa mga pinakahuling sikat ay PEST . Nilikha ng opisyal na empleyado ng Laravel Nuno Maduro , ay naglalayong gawing simple ang syntax, na ginagawang mas mabilis ang pagsulat ng code para sa mga pagsubok.

Sa ilalim ng talukbong, ito ay tumatakbo su Ang PHPUnit, bilang karagdagang layer, sinusubukan lamang na bawasan ang ilang mga paunang paulit-ulit na bahagidefigabi ng PHPUnit code.

Tingnan natin ang isang halimbawa. Tandaan ang pre feature test classdefinited sa Laravel? Ipapaalala ko sa iyo:

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

Alam mo ba kung ano ang magiging hitsura ng parehong pagsubok sa PEST?

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

Oo, ISANG linya ng code at iyon na. Kaya, ang layunin ng PEST ay alisin ang overhead ng:

• Paglikha ng mga klase at pamamaraan para sa lahat;
• Extension ng test case;
• Sa pamamagitan ng paglalagay ng mga aksyon sa magkahiwalay na linya: sa PEST maaari mong i-chain ang mga ito nang magkasama.

Para makabuo ng PEST test sa Laravel, kailangan mong tumukoy ng karagdagang flag:

php artisan make:test HomepageTest --pest

Sa pagsulat na ito, medyo sikat ang PEST sa mga developer ng Laravel, ngunit personal mong kagustuhan kung gagamitin ang karagdagang tool na ito at matutunan ang syntax nito, pati na rin ang isang PHPUnit note.

BlogInnovazione.it