Dysgwch sut i wneud profion yn Laravel gydag enghreifftiau syml, gan ddefnyddio PHPUnit a PEST

O ran profion awtomataidd neu brofion uned, mewn unrhyw iaith raglennu, mae dwy farn gyferbyniol:

• amser coll
• Ni allwch wneud hebddo

Felly, gyda'r erthygl hon byddwn yn ceisio argyhoeddi'r cyntaf, yn enwedig trwy ddangos pa mor hawdd yw hi i ddechrau gyda phrofion awtomataidd yn Laravel.

Yn gyntaf, gadewch i ni siarad am y "pam", ac yna gadewch i ni weld rhai enghreifftiau o sut.

Pam mae angen profion awtomataidd arnom

Mae profion awtomataidd yn rhedeg rhannau o'r cod ac yn adrodd am unrhyw wallau. Dyna'r ffordd symlaf i'w disgrifio. Dychmygwch gyflwyno nodwedd newydd mewn app, ac yna byddai cynorthwyydd robot personol yn mynd i brofi'r nodwedd newydd â llaw, tra hefyd yn profi a oedd y cod newydd ddim yn torri unrhyw un o'r hen nodweddion.

Dyma'r brif fantais: ailbrofi'r holl nodweddion yn awtomatig. Gallai hyn ymddangos fel gwaith ychwanegol, ond os na ddywedwch wrth y “robot” am ei wneud, fel arall dylem ei wneud â llaw, iawn? 

Neu gellid rhyddhau nodweddion newydd heb brofi a ydynt yn gweithio, gan obeithio y bydd defnyddwyr yn riportio chwilod.

Gall profion awtomataidd roi nifer o fanteision i ni:

• Arbed amser profi â llaw;
• Maent yn caniatáu ichi arbed amser ar y swyddogaeth newydd a weithredir ac ar y swyddogaethau cyfunol trwy osgoi atchweliad;
• Lluoswch y budd hwn â'r holl nodweddion newydd a'r holl nodweddion sydd eisoes wedi'u rhoi ar waith;
• Mae'r tri phwynt blaenorol yn berthnasol i bob fersiwn newydd;
• ...

Ceisiwch ddychmygu eich cais mewn blwyddyn neu ddwy, gyda datblygwyr newydd ar y tîm nad ydynt yn gwybod y cod a ysgrifennwyd yn y blynyddoedd blaenorol, neu hyd yn oed sut i'w brofi. 

Ein profion awtomataidd cyntaf

I berfformio'r cyntaf profion awtomataidd yn Laravel, nid oes angen i chi ysgrifennu unrhyw god. Ydw, rydych chi wedi darllen hynny'n iawn. Mae popeth eisoes wedi'i ffurfweddu a'i baratoi yn y rhagosodiaddefinite o Laravel, gan gynnwys yr enghraifft sylfaenol gyntaf.

Gallwch geisio gosod prosiect Laravel a rhedeg y profion cyntaf ar unwaith:

laravel new project
cd project
php artisan test

Dylai hyn fod y canlyniad yn eich consol:

Os cymerwn olwg ar y rhagdefinith o Laravel /tests, mae gennym ddwy ffeil:

profion/Feature/ExampleTest.php :

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

Nid oes angen i chi wybod unrhyw gystrawen i ddeall beth sy'n digwydd yma: llwythwch y dudalen gartref a gwiriwch a yw'r cod statws HTTP è "200 OK".

Gelwir hefyd yn enw'r dull test_the_application_returns_a_successful_response() yn dod yn destun darllenadwy pan fyddwch chi'n edrych ar ganlyniadau'r prawf, dim ond trwy roi gofod yn lle'r symbol tanlinellu.

profion/Unit/ExampleTest.php :

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

Ymddangos braidd yn ddibwrpas, gwirio i weld a yw hyn yn wir? 

Byddwn yn siarad yn benodol am brofion uned ychydig yn ddiweddarach. Am y tro, mae angen i chi ddeall beth sy'n digwydd yn gyffredinol ym mhob prawf.

• Pob ffeil prawf yn y ffolder /tests yn ddosbarth PHP sy'n ymestyn y TestCase o Uned PHP
• O fewn pob dosbarth, gallwch greu dulliau lluosog, fel arfer un dull i sefyllfa brofi
• O fewn pob dull mae tri cham gweithredu: paratoi'r sefyllfa, yna gweithredu ac yna gwirio (cadarnhau) a yw'r canlyniad yn unol â'r disgwyl.

Yn strwythurol, dyna'r cyfan sydd angen i chi ei wybod, mae popeth arall yn dibynnu ar yr union bethau rydych chi am eu profi.

I gynhyrchu dosbarth prawf gwag, rhedwch y gorchymyn hwn:

php artisan make:test HomepageTest

Mae'r ffeil yn cael ei gynhyrchu 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);
    }
}

Nawr, gadewch i ni weld beth sy'n digwydd os bydd cod prawf yn methu yn Laravel

Gadewch i ni nawr weld beth sy'n digwydd os na fydd yr honiadau prawf yn dychwelyd y canlyniad disgwyliedig.

Gadewch i ni newid y profion enghreifftiol i hyn:

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

Ac yn awr, os ydym yn rhedeg y gorchymyn php artisan test eto:

 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

Mae dau brawf a fethwyd, wedi'u nodi fel METHU, gydag esboniadau isod a saethau'n pwyntio at union linell y profion a fethodd. Mae gwallau yn cael eu nodi fel hyn.

Enghraifft: Profi cod ffurflen gofrestru yn Laravel

Tybiwch fod gennym ffurflen a bod angen i ni brofi achosion amrywiol: rydym yn gwirio a yw'n methu â data annilys, rydym yn gwirio a yw'n llwyddo gyda'r mewnbwn cywir, ac ati.

Y pecyn cychwyn swyddogol gan Laravel Breeze yn cynnwys i profi'r ymarferoldeb ynddo. Edrychwn ar rai enghreifftiau oddi yno:

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

Yma mae gennym ddau brawf mewn un dosbarth, gan fod y ddau ohonynt yn gysylltiedig â'r ffurflen gofrestru: mae un yn gwirio a yw'r ffurflen wedi'i llwytho'n gywir ac un arall yn gwirio a yw'r cyflwyniad yn gweithio'n dda.

Gadewch inni ddod yn gyfarwydd â dau ddull arall o wirio'r canlyniad, dau honiad arall: $this->assertAuthenticated()e $response->assertRedirect(). Gallwch wirio'r holl honiadau sydd ar gael yn nogfennaeth swyddogol Uned PHP e Ymateb Laravel . Sylwch fod rhai haeriadau cyffredinol yn digwydd ar y pwnc $this, tra bod eraill yn gwirio'r penodol $responseo alwad y llwybr.

Peth pwysig arall yw y use RefreshDatabase;datganiad, gyda'r strôc, wedi'i fewnosod uwchben y dosbarth. Mae'n angenrheidiol pan fydd camau prawf yn gallu effeithio ar y gronfa ddata, fel yn yr enghraifft hon, mae logio yn ychwanegu cofnod newydd yn y userstabl cronfa ddata. Ar gyfer hyn, dylech greu cronfa ddata prawf ar wahân a fydd yn cael ei diweddaru gyda php artisan migrate:freshbob tro y cynhelir y profion.

Mae gennych ddau opsiwn: creu cronfa ddata ar wahân yn gorfforol neu ddefnyddio cronfa ddata SQLite er cof. Mae'r ddau wedi'u ffurfweddu yn y ffeil phpunit.xmla ddarperir yn ddiofyndefinita gyda Laravel. Yn benodol, mae angen y rhan hon arnoch chi:

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

Gweler y DB_CONNECTIONe DB_DATABASEpa rai y gwneir sylwadau arnynt? Os oes gennych SQLite ar eich gweinydd, y cam symlaf yw dadwneud y llinellau hynny a bydd eich profion yn rhedeg yn erbyn y gronfa ddata cof honno.

Yn y prawf hwn dywedwn fod y defnyddiwr yn cael ei ddilysu'n llwyddiannus a'i ailgyfeirio i'r hafan gywir, ond gallwn hefyd brofi'r data gwirioneddol yn y gronfa ddata.

Yn ogystal â'r cod hwn:

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

Gallwn hefyd ddefnyddio haeriadau prawf y gronfa ddata a gwneud rhywbeth fel hyn:

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

Enghraifft o'r dudalen Mewngofnodi

Gadewch i ni nawr weld enghraifft arall o dudalen Mewngofnodi gyda 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();
    }
}

Mae'n ymwneud â'r ffurflen mewngofnodi. Mae'r rhesymeg yn debyg i gofrestru, dde? Ond tri dull yn lle dau, felly dyma enghraifft o brofi senarios da a drwg. Felly, y rhesymeg gyffredin yw y dylech brofi'r ddau achos: pan fydd pethau'n mynd yn dda a phan fyddant yn methu.

Hefyd, yr hyn a welwch yn y prawf hwn yw'r defnydd ohono Ffatrïoedd Cronfa Ddata : Mae Laravel yn creu defnyddiwr ffug ( eto, ar eich cronfa ddata prawf wedi'i diweddaru ) ac yna'n ceisio mewngofnodi, gyda manylion cywir neu anghywir.

Unwaith eto, mae Laravel yn cynhyrchu'r cyn ffatridefinita gyda data ffug ar gyfer y Usermodel, y tu allan i'r blwch.

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

Rydych chi'n gweld, faint o bethau sy'n cael eu paratoi gan Laravel ei hun, felly a fyddai'n hawdd i ni ddechrau profi?

Felly os byddwn yn gweithredu php artisan testar ôl gosod Laravel Breeze, dylem weld rhywbeth fel hyn:

 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

Profion swyddogaethol o'u cymharu â phrofion uned ac eraill

Rydych chi wedi gweld yr is-ffolderi tests/Feature e tests/Unit ?. 

Beth yw'r gwahaniaeth rhyngddynt? 

Yn fyd-eang, y tu allan i ecosystem Laravel/PHP, mae sawl math o brofion awtomataidd. Gallwch ddod o hyd i dermau fel:

• Profion uned
• Profi nodwedd
• Profion integreiddio
• Profion swyddogaethol
• Profion diwedd-i-ddiwedd
• Profion derbyn
• Profion mwg
• etc.

Mae'n swnio'n gymhleth, ac mae'r gwahaniaethau gwirioneddol rhwng y mathau hyn o brofion weithiau'n aneglur. Dyna pam mae Laravel wedi symleiddio'r holl dermau dryslyd hyn a'u grwpio'n ddau: uned/nodwedd.

Yn syml, mae profion nodwedd yn ceisio gweithredu ymarferoldeb gwirioneddol eich cymwysiadau: cael yr URL, ffoniwch yr API, dynwared yr union ymddygiad fel llenwi'r ffurflen. Mae profion nodwedd fel arfer yn perfformio'r un gweithrediadau neu weithrediadau tebyg ag y byddai unrhyw ddefnyddiwr prosiect yn ei wneud, â llaw, mewn bywyd go iawn.

Mae dau ystyr i brofion uned. Yn gyffredinol, efallai y gwelwch fod unrhyw brawf awtomataidd yn cael ei alw’n “brofi uned” a gellir galw’r broses gyfan yn “brofi uned”. Ond yng nghyd-destun ymarferoldeb yn erbyn uned, mae'r broses hon yn ymwneud â phrofi uned god benodol nad yw'n gyhoeddus, ar ei phen ei hun. Er enghraifft, mae gennych chi ddosbarth Laravel gyda dull sy'n cyfrifo rhywbeth, fel cyfanswm pris archeb gyda pharamedrau. Felly, byddai'r prawf uned yn nodi a yw canlyniadau cywir yn cael eu dychwelyd o'r dull hwnnw (uned cod), gyda pharamedrau gwahanol.

I gynhyrchu prawf uned, mae angen i chi ychwanegu baner:

php artisan make:test OrderPriceTest --unit

Mae'r cod a gynhyrchir yr un peth â'r prawf cyn uneddefiSystem Laravel:

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

Fel y gwelwch, nid yw'n bodoli RefreshDatabase, a dyma un o defidiffiniadau prawf uned mwyaf cyffredin: nid yw'n cyffwrdd â'r gronfa ddata, mae'n gweithio fel “blwch du”, wedi'i ynysu o'r cymhwysiad rhedeg.

Gan geisio dynwared yr enghraifft y soniais amdani yn gynharach, gadewch i ni ddychmygu bod gennym ddosbarth gwasanaeth OrderPrice.

app/Services/OrderPriceService.php:

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

Yna, gallai'r prawf uned edrych yn rhywbeth fel hyn:

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
}

Yn fy mhrofiad personol gyda phrosiectau Laravel, mae mwyafrif helaeth y profion yn brofion Nodwedd, nid profion Uned. Yn gyntaf, mae angen i chi brofi a yw'ch cais yn gweithio, y ffordd y byddai pobl go iawn yn ei ddefnyddio.

Nesaf, os oes gennych gyfrifiadau arbennig neu resymeg gallwch chi definire fel uned, gyda pharamedrau, gallwch greu profion uned yn benodol ar gyfer hynny.

Weithiau, mae ysgrifennu profion yn gofyn am addasu'r cod ei hun a'i ail-ffactorio i'w wneud yn fwy "profadwy": rhannu'r unedau yn ddosbarthiadau neu ddulliau arbennig.

Pryd/sut i gynnal y profion?

Beth yw'r defnydd gwirioneddol o hyn php artisan test, pryd ddylech chi ei redeg?

Mae yna wahanol ddulliau, yn dibynnu ar lif gwaith eich busnes, ond yn gyffredinol mae angen i chi sicrhau bod pob prawf yn “wyrdd” (h.y. heb wallau) cyn gwthio’r newidiadau cod terfynol i’r gadwrfa.

Yna, rydych chi'n gweithio'n lleol ar eich tasg, a phan fyddwch chi'n meddwl eich bod chi wedi gorffen, yn rhedeg rhai profion i wneud yn siŵr nad ydych chi wedi torri unrhyw beth. Cofiwch, efallai y bydd eich cod yn achosi chwilod nid yn unig yn eich rhesymeg ond hefyd yn torri rhyw ymddygiad arall yn anfwriadol yng nghod rhywun arall a ysgrifennwyd ers talwm.

Os awn ni gam ymhellach, mae'n bosibl awtomeiddio llawer pethau. Gydag amrywiol offer CI/CD, gallwch nodi profion i'w rhedeg pryd bynnag y bydd rhywun yn gwthio newidiadau i gangen Git benodol neu cyn uno cod â'r gangen gynhyrchu. Y llif gwaith symlaf fyddai defnyddio Github Actions, mae gen i fideo ar wahân sy'n ei brofi.

Beth ddylech chi ei brofi?

Mae yna wahanol farnau ar ba mor fawr y dylai'r “sylw prawf” fel y'i gelwir fod: rhowch gynnig ar bob gweithrediad ac achos posibl ar bob tudalen, neu cyfyngwch y gwaith i'r rhannau pwysicaf.

Mewn gwirionedd, dyma lle rwy’n cytuno â phobl sy’n cyhuddo profion awtomataidd o gymryd mwy o amser na darparu budd gwirioneddol. Gall hyn ddigwydd os byddwch yn ysgrifennu profion ar gyfer pob manylyn. Wedi dweud hynny, efallai y bydd ei angen ar eich prosiect: y prif gwestiwn yw “beth yw pris gwall posibl”.

Mewn geiriau eraill, mae angen i chi flaenoriaethu eich ymdrechion profi trwy ofyn y cwestiwn “Beth fyddai'n digwydd pe bai'r cod hwn yn methu?” Os oes bygiau yn eich system dalu, bydd yn effeithio'n uniongyrchol ar y busnes. Felly os yw ymarferoldeb eich rolau/caniatâd yn cael ei dorri, mae hwn yn fater diogelwch enfawr.

Rwy’n hoffi’r ffordd y gwnaeth Matt Stauffer ei roi mewn cynhadledd: “Rhaid i chi yn gyntaf brofi’r pethau hynny, os ydyn nhw’n methu, a fyddai’n eich diswyddo o’ch swydd.” Wrth gwrs mae hynny'n or-ddweud, ond fe gewch chi'r syniad: rhowch gynnig ar y pethau pwysig yn gyntaf. Ac yna nodweddion eraill, os oes gennych amser.

PEST: dewis arall yn lle PHPUnit

Mae'r holl enghreifftiau uchod yn seiliedig ar offeryn rhag-brofi Laraveldefineis: Uned PHP . Ond dros y blynyddoedd mae offer eraill wedi ymddangos yn yr ecosystem ac un o'r rhai poblogaidd diweddaraf yw PLA . Wedi'i greu gan weithiwr swyddogol Laravel Nuno Maduro , yn anelu at symleiddio'r gystrawen, gan wneud cod ysgrifennu ar gyfer profion hyd yn oed yn gyflymach.

O dan y cwfl, mae'n rhedeg su PHPUnit, fel haen ychwanegol, dim ond ceisio lleihau rhai rhannau a ailadroddir ymlaen llawdefinite o'r cod PHPUnit.

Gadewch i ni edrych ar enghraifft. Cofiwch y dosbarth prawf cyn nodwedddefinited yn Laravel? Byddaf yn eich atgoffa:

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

Ydych chi'n gwybod sut olwg fyddai ar yr un prawf gyda PEST?

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

Ie, UN llinell o god a dyna ni. Felly, nod PEST yw cael gwared ar orbenion:

• Creu dosbarthiadau a dulliau ar gyfer popeth;
• Estyniad achos prawf;
• Trwy roi gweithredoedd ar linellau ar wahân: yn PEST gallwch eu cadwyno gyda'i gilydd.

I gynhyrchu prawf PEST yn Laravel, mae angen i chi nodi baner ychwanegol:

php artisan make:test HomepageTest --pest

O'r ysgrifennu hwn, mae PEST yn eithaf poblogaidd ymhlith datblygwyr Laravel, ond eich dewis personol chi yw defnyddio'r offeryn ychwanegol hwn a dysgu ei gystrawen, yn ogystal â nodyn PHPUnit.

BlogInnovazione.it