PHPUnit మరియు PESTని ఉపయోగించి సాధారణ ఉదాహరణలతో Laravelలో పరీక్షలు ఎలా చేయాలో తెలుసుకోండి

ఆటోమేటెడ్ పరీక్షలు లేదా యూనిట్ పరీక్షల విషయానికి వస్తే, ఏదైనా ప్రోగ్రామింగ్ భాషలో, రెండు వ్యతిరేక అభిప్రాయాలు ఉన్నాయి:

• సమయం వృధా
• మీరు లేకుండా చేయలేరు

కాబట్టి, ఈ కథనంతో మేము లారావెల్‌లో ఆటోమేటెడ్ టెస్టింగ్‌తో ప్రారంభించడం ఎంత సులభమో ప్రదర్శించడం ద్వారా, మునుపటి వారిని ఒప్పించడానికి ప్రయత్నిస్తాము.

మొదట "ఎందుకు" గురించి మాట్లాడుదాం, ఆపై ఎలా అనేదానికి కొన్ని ఉదాహరణలను చూద్దాం.

మనకు స్వయంచాలక పరీక్ష ఎందుకు అవసరం

స్వయంచాలక పరీక్షలు కోడ్ యొక్క భాగాలను అమలు చేస్తాయి మరియు ఏవైనా లోపాలను నివేదించాయి. వాటిని వివరించడానికి ఇది చాలా సులభమైన మార్గం. యాప్‌లో కొత్త ఫీచర్‌ను రూపొందించడం గురించి ఆలోచించండి, ఆపై వ్యక్తిగత రోబోట్ అసిస్టెంట్ వెళ్లి కొత్త ఫీచర్‌ను మాన్యువల్‌గా పరీక్షిస్తారు, అదే సమయంలో కొత్త కోడ్ పాత ఫీచర్‌లలో దేనినీ విచ్ఛిన్నం చేయలేదా అని కూడా పరీక్షిస్తుంది.

ఇది ప్రధాన ప్రయోజనం: అన్ని లక్షణాలను స్వయంచాలకంగా మళ్లీ పరీక్షించడం. ఇది అదనపు పనిలా అనిపించవచ్చు, కానీ మీరు దీన్ని చేయమని “రోబోట్”కి చెప్పకపోతే, మేము ప్రత్యామ్నాయంగా దీన్ని మాన్యువల్‌గా చేయాలి, సరియైనదా? 

లేదా వినియోగదారులు బగ్‌లను నివేదిస్తారనే ఆశతో కొత్త ఫీచర్లు పని చేస్తున్నాయో లేదో పరీక్షించకుండానే విడుదల చేయవచ్చు.

స్వయంచాలక పరీక్షలు మనకు అనేక ప్రయోజనాలను అందిస్తాయి:

• మాన్యువల్ పరీక్ష సమయాన్ని ఆదా చేయండి;
• రిగ్రెషన్‌ను నివారించడం ద్వారా అమలు చేయబడిన కొత్త ఫంక్షన్‌లో మరియు ఏకీకృత ఫంక్షన్‌లలో సమయాన్ని ఆదా చేయడానికి అవి మిమ్మల్ని అనుమతిస్తాయి;
• ఈ ప్రయోజనాన్ని అన్ని కొత్త ఫీచర్లు మరియు ఇప్పటికే అమలు చేసిన అన్ని ఫీచర్లతో గుణించండి;
• మునుపటి మూడు పాయింట్లు ప్రతి కొత్త సంస్కరణకు వర్తిస్తాయి;
• ...

మునుపటి సంవత్సరాల్లో వ్రాసిన కోడ్ లేదా దాన్ని ఎలా పరీక్షించాలో కూడా తెలియని కొత్త డెవలపర్‌లతో మీ అప్లికేషన్‌ను ఒకటి లేదా రెండు సంవత్సరాలలో ఊహించుకోవడానికి ప్రయత్నించండి. 

మా మొదటి ఆటోమేటెడ్ పరీక్షలు

మొదటి నిర్వహించడానికి లారావెల్‌లో ఆటోమేటెడ్ టెస్టింగ్, మీరు ఏ కోడ్ వ్రాయవలసిన అవసరం లేదు. అవును, మీరు చదివింది నిజమే. ప్రతిదీ ఇప్పటికే కాన్ఫిగర్ చేయబడింది మరియు ప్రీ-ఇన్‌స్టాలేషన్‌లో సిద్ధం చేయబడిందిdefiలారావెల్ రాత్రి, మొదటి ప్రాథమిక ఉదాహరణతో సహా.

మీరు లారావెల్ ప్రాజెక్ట్‌ను ఇన్‌స్టాల్ చేయడానికి ప్రయత్నించవచ్చు మరియు వెంటనే మొదటి పరీక్షలను అమలు చేయవచ్చు:

laravel new project
cd project
php artisan test

ఇది మీ కన్సోల్‌లో ఫలితం అయి ఉండాలి:

మనం ముందుగా పరిశీలిస్తేdefiలారావెల్ రాత్రి /tests, మాకు రెండు ఫైల్‌లు ఉన్నాయి:

పరీక్షలు/ఫీచర్/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 యొక్క TestCaseని విస్తరించే PHP తరగతి 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);
    }
}

లారావెల్‌లో టెస్ట్ కోడ్ విఫలమైతే ఏమి జరుగుతుందో ఇప్పుడు చూద్దాం

పరీక్ష నిర్థారణలు ఆశించిన ఫలితాన్ని అందించకపోతే ఏమి జరుగుతుందో ఇప్పుడు చూద్దాం.

ఉదాహరణ పరీక్షలను దీనికి మారుద్దాం:

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 అని గుర్తు పెట్టబడింది, దిగువ వివరణలు మరియు విఫలమైన పరీక్షల యొక్క ఖచ్చితమైన రేఖను సూచించే బాణాలు ఉన్నాయి. లోపాలు ఈ విధంగా సూచించబడ్డాయి.

ఉదాహరణ: లారావెల్‌లో రిజిస్ట్రేషన్ ఫారమ్ కోడ్‌ని పరీక్షించడం

మనకు ఒక ఫారమ్ ఉందని అనుకుందాం మరియు మేము వివిధ కేసులను పరీక్షించాల్సిన అవసరం ఉంది: ఇది చెల్లని డేటాతో విఫలమైతే మేము తనిఖీ చేస్తాము, సరైన ఇన్‌పుట్‌తో అది విజయవంతమైందో లేదో తనిఖీ చేస్తాము.

అధికారిక స్టార్టర్ కిట్ లారావెల్ బ్రీజ్ ద్వారా 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 లారావెల్ ప్రతిస్పందన . ఈ అంశంపై కొన్ని సాధారణ వాదనలు జరుగుతాయని గమనించండి $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',
]);

లాగిన్ పేజీకి ఉదాహరణ

లారావెల్ బ్రీజ్‌తో లాగిన్ పేజీ యొక్క మరొక ఉదాహరణను ఇప్పుడు చూద్దాం

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

ఇది లాగిన్ ఫారమ్ గురించి. లాజిక్ రిజిస్ట్రేషన్ మాదిరిగానే ఉంటుంది, సరియైనదా? కానీ రెండింటికి బదులుగా మూడు పద్ధతులు, కాబట్టి ఇది మంచి మరియు చెడు దృశ్యాలను పరీక్షించడానికి ఒక ఉదాహరణ. కాబట్టి, సాధారణ తర్కం ఏమిటంటే, మీరు రెండు కేసులను పరీక్షించాలి: విషయాలు సరిగ్గా జరిగినప్పుడు మరియు అవి విఫలమైనప్పుడు.

అలాగే, ఈ పరీక్షలో మీరు చూసేది వాడుక డేటాబేస్ ఫ్యాక్టరీలు : లారావెల్ నకిలీ వినియోగదారుని సృష్టిస్తుంది ( మళ్ళీ, మీ నవీకరించబడిన పరీక్ష డేటాబేస్లో ) ఆపై సరైన లేదా తప్పు ఆధారాలతో లాగిన్ చేయడానికి ప్రయత్నిస్తుంది.

మరోసారి, లారావెల్ ఫ్యాక్టరీ ప్రీని ఉత్పత్తి చేస్తుందిdefiకోసం తప్పుడు డేటాతో nita 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 testలారావెల్ బ్రీజ్‌ని ఇన్‌స్టాల్ చేసిన తర్వాత, మనం ఇలాంటివి చూడాలి:

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

వాటి మధ్య తేడా ఏమిటి? 

ప్రపంచవ్యాప్తంగా, లారావెల్/PHP పర్యావరణ వ్యవస్థ వెలుపల, అనేక రకాల ఆటోమేటెడ్ టెస్టింగ్‌లు ఉన్నాయి. మీరు ఇలాంటి నిబంధనలను కనుగొనవచ్చు:

• యూనిట్ పరీక్షలు
• ఫీచర్ టెస్టింగ్
• ఇంటిగ్రేషన్ పరీక్షలు
• ఫంక్షనల్ పరీక్షలు
• ఎండ్-టు-ఎండ్ టెస్టింగ్
• అంగీకార పరీక్షలు
• పొగ పరీక్షలు
• మొదలైనవి

ఇది సంక్లిష్టంగా అనిపిస్తుంది మరియు ఈ రకమైన పరీక్షల మధ్య వాస్తవ వ్యత్యాసాలు కొన్నిసార్లు అస్పష్టంగా ఉంటాయి. అందుకే లారావెల్ ఈ గందరగోళ నిబంధనలన్నింటినీ సరళీకృతం చేసింది మరియు వాటిని రెండుగా వర్గీకరించింది: యూనిట్/ఫీచర్.

సరళంగా చెప్పాలంటే, ఫీచర్ పరీక్షలు మీ అప్లికేషన్‌ల యొక్క వాస్తవ కార్యాచరణను అమలు చేయడానికి ప్రయత్నిస్తాయి: 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
}

లారావెల్ ప్రాజెక్ట్‌లతో నా వ్యక్తిగత అనుభవంలో, చాలా వరకు పరీక్షలు ఫీచర్ పరీక్షలు, యూనిట్ పరీక్షలు కాదు. ముందుగా, మీరు మీ అప్లికేషన్ పని చేస్తుందో లేదో పరీక్షించాలి, నిజమైన వ్యక్తులు దానిని ఉపయోగించే విధంగా.

తర్వాత, మీకు ప్రత్యేక గణనలు లేదా తర్కం ఉంటే మీరు చేయగలరు definire ఒక యూనిట్‌గా, పారామితులతో, మీరు దాని కోసం ప్రత్యేకంగా యూనిట్ పరీక్షలను సృష్టించవచ్చు.

కొన్నిసార్లు, పరీక్షలు రాయడానికి కోడ్‌ను సవరించడం మరియు దానిని మరింత “పరీక్షించదగినది” చేయడానికి రీఫ్యాక్టరింగ్ చేయడం అవసరం: యూనిట్‌లను ప్రత్యేక తరగతులుగా లేదా పద్ధతులుగా విభజించడం.

పరీక్షలు ఎప్పుడు/ఎలా చేయాలి?

అసలు దీని వల్ల ఉపయోగం ఏమిటి php artisan test, మీరు దీన్ని ఎప్పుడు అమలు చేయాలి?

మీ వ్యాపార వర్క్‌ఫ్లో ఆధారంగా విభిన్న విధానాలు ఉన్నాయి, కానీ సాధారణంగా మీరు తుది కోడ్ మార్పులను రిపోజిటరీకి నెట్టడానికి ముందు అన్ని పరీక్షలు “ఆకుపచ్చ” (అంటే లోపం లేనివి) ఉండేలా చూసుకోవాలి.

అప్పుడు, మీరు మీ పనిపై స్థానికంగా పని చేస్తారు మరియు మీరు పూర్తి చేసినట్లు మీరు భావించినప్పుడు, మీరు ఏదైనా విచ్ఛిన్నం చేయలేదని నిర్ధారించుకోవడానికి కొన్ని పరీక్షలను అమలు చేయండి. గుర్తుంచుకోండి, మీ కోడ్ మీ లాజిక్‌లో బగ్‌లకు కారణం కావచ్చు కానీ చాలా కాలం క్రితం వ్రాసిన వేరొకరి కోడ్‌లో అనుకోకుండా కొన్ని ఇతర ప్రవర్తనను విచ్ఛిన్నం చేయవచ్చు.

మనం ఒక అడుగు ముందుకు వేస్తే, ఆటోమేట్ చేయడం సాధ్యమవుతుంది అనేక విషయాలు. వివిధ CI/CD టూల్స్‌తో, ఎవరైనా నిర్దిష్ట Git బ్రాంచ్‌కి మార్పులు చేసినప్పుడు లేదా ప్రొడక్షన్ బ్రాంచ్‌లో కోడ్‌ను విలీనం చేసే ముందు అమలు చేయడానికి మీరు పరీక్షలను పేర్కొనవచ్చు. Github చర్యలను ఉపయోగించడం సరళమైన వర్క్‌ఫ్లో, నా దగ్గర ఉంది ఒక ప్రత్యేక వీడియో ఇది రుజువు చేస్తుంది.

మీరు ఏమి పరీక్షించాలి?

"పరీక్ష కవరేజ్" అని పిలవబడేది ఎంత పెద్దదిగా ఉండాలనే దానిపై భిన్నమైన అభిప్రాయాలు ఉన్నాయి: ప్రతి పేజీలో సాధ్యమయ్యే ప్రతి ఆపరేషన్ మరియు కేసును ప్రయత్నించండి లేదా పనిని అత్యంత ముఖ్యమైన భాగాలకు పరిమితం చేయండి.

వాస్తవానికి, ఆటోమేటెడ్ టెస్టింగ్ వాస్తవ ప్రయోజనాన్ని అందించడం కంటే ఎక్కువ సమయం తీసుకుంటోందని ఆరోపించే వ్యక్తులతో నేను ఏకీభవిస్తున్నాను. మీరు ప్రతి ఒక్క వివరాల కోసం పరీక్షలు వ్రాస్తే ఇది జరుగుతుంది. ఇది మీ ప్రాజెక్ట్‌కి అవసరం కావచ్చు: "సంభావ్య లోపం యొక్క ధర ఎంత" అనేది ప్రధాన ప్రశ్న.

మరో మాటలో చెప్పాలంటే, “ఈ కోడ్ విఫలమైతే ఏమి జరుగుతుంది?” అనే ప్రశ్నను అడగడం ద్వారా మీరు మీ పరీక్ష ప్రయత్నాలకు ప్రాధాన్యత ఇవ్వాలి. మీ చెల్లింపు వ్యవస్థలో బగ్‌లు ఉంటే, అది నేరుగా వ్యాపారాన్ని ప్రభావితం చేస్తుంది. కాబట్టి మీ పాత్రలు/అనుమతుల కార్యాచరణ విచ్ఛిన్నమైతే, ఇది భారీ భద్రతా సమస్య.

మాట్ స్టాఫర్ ఒక కాన్ఫరెన్స్‌లో ఎలా చెప్పారో నాకు చాలా ఇష్టం: "మీరు మొదట వాటిని పరీక్షించాలి, అవి విఫలమైతే, మీ ఉద్యోగం నుండి మిమ్మల్ని తొలగిస్తారు." వాస్తవానికి ఇది అతిశయోక్తి, కానీ మీకు ఆలోచన వస్తుంది: ముందుగా ముఖ్యమైన అంశాలను ప్రయత్నించండి. ఆపై ఇతర లక్షణాలు, మీకు సమయం ఉంటే.

PEST: PHPUnitకి కొత్త ప్రత్యామ్నాయం

పై ఉదాహరణలన్నీ లారావెల్ ప్రీ టెస్టింగ్ టూల్‌పై ఆధారపడి ఉన్నాయిdefiరాత్రి: PHPU యూనిట్ . కానీ సంవత్సరాలుగా పర్యావరణ వ్యవస్థలో ఇతర సాధనాలు కనిపించాయి మరియు తాజా జనాదరణ పొందిన వాటిలో ఒకటి PEST . అధికారిక లారావెల్ ఉద్యోగి సృష్టించారు నునో మదురో , వాక్యనిర్మాణాన్ని సులభతరం చేయడం, పరీక్షల కోసం కోడ్ రాయడాన్ని మరింత వేగవంతం చేయడం లక్ష్యంగా పెట్టుకుంది.

హుడ్ కింద, అది నడుస్తుంది su PHPUnit, ఒక అదనపు లేయర్‌గా, కొన్ని ముందుగా పునరావృతమయ్యే భాగాలను తగ్గించడానికి ప్రయత్నిస్తోందిdefiPHPUnit కోడ్ యొక్క నైట్.

ఒక ఉదాహరణ చూద్దాం. ప్రీ ఫీచర్ పరీక్ష తరగతిని గుర్తుంచుకోండి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లో మీరు వాటిని కలిసి బంధించవచ్చు.

లారావెల్‌లో PEST పరీక్షను రూపొందించడానికి, మీరు అదనపు ఫ్లాగ్‌ను పేర్కొనాలి:

php artisan make:test HomepageTest --pest

ఈ రచన ప్రకారం, PEST లారావెల్ డెవలపర్‌లలో బాగా ప్రాచుర్యం పొందింది, అయితే ఈ అదనపు సాధనాన్ని ఉపయోగించాలా మరియు దాని సింటాక్స్‌తో పాటు PHPUnit నోట్‌ను నేర్చుకోవాలా అనేది మీ వ్యక్తిగత ప్రాధాన్యత.

BlogInnovazione.it