לערנען ווי צו טאָן טעסץ אין Laravel מיט פּשוט ביישפילן ניצן PHPUnit און PEST

ווען עס קומט צו אָטאַמייטיד טעסץ אָדער אַפּאַראַט טעסץ, אין קיין פּראָגראַממינג שפּראַך, עס זענען צוויי אַפּאָוזינג מיינונגען:

• א שאד די צייט
• איר קענט נישט טאָן אָן עס

אַזוי, מיט דעם אַרטיקל מיר וועלן פּרובירן צו איבערצייגן די ערשטע, ספּעציעל דורך דעמאַנסטרייטינג ווי גרינג עס איז צו אָנהייבן מיט אָטאַמייטיד טעסטינג אין Laravel.

קודם לאמיר רעדן וועגן דעם "פארוואס", און דערנאָך לאָמיר זען עטלעכע ביישפילן פון ווי.

פארוואס מיר דאַרפֿן אָטאַמייטיד טעסטינג

אָטאַמייטיד טעסץ לויפן פּאַרץ פון די קאָד און באַריכט קיין ערראָרס. דאָס איז דער סימפּלאַסט וועג צו באַשרייַבן זיי. ימאַגינע לאָנטשינג אַ נייַע שטריך אין אַן אַפּ, און אַ פערזענלעכע ראָבאָט אַסיסטאַנט וואָלט גיין און מאַניואַלי פּרובירן די נייַע שטריך, און אויך טעסטינג צי די נייַע קאָד האט נישט ברעכן קיין פון די אַלט פֿעיִקייטן.

דאָס איז דער הויפּט מייַלע: טעסטינג אַלע פֿעיִקייטן אויטאָמאַטיש. דאָס קען ויסקומען ווי עקסטרע אַרבעט, אָבער אויב איר טאָן ניט זאָגן דעם "ראָבאָט" צו טאָן דאָס, מיר זאָל אַלטערנאַטיוועלי טאָן דאָס מאַניואַלי, רעכט? 

אָדער נייַע פֿעיִקייטן קען זיין רעלעאַסעד אָן טעסטינג צי זיי אַרבעט, כאָופּינג אַז יוזערז וועלן באַריכט באַגז.

אָטאַמייטיד טעסץ קענען געבן אונדז עטלעכע אַדוואַנטידזשיז:

• שפּאָרן מאַנואַל טעסטינג צייט;
• זיי לאָזן איר צו שפּאָרן צייט אויף די ימפּלאַמענאַד נייַ פאַנגקשאַנז און אויף די קאַנסאַלאַדייטאַד פאַנגקשאַנז דורך ויסמיידן ראַגרעשאַן;
• מערן דעם נוץ מיט אַלע נייַע פֿעיִקייטן און אַלע שוין ימפּלאַמענאַד פֿעיִקייטן;
• די פריערדיקע דריי פונקטן זענען גילטיק אויף יעדער נייע ווערסיע;
• ...

פּרוּווט צו ימאַדזשאַן דיין אַפּלאַקיישאַן אין אַ יאָר אָדער צוויי, מיט נייַע דעוועלאָפּערס אין די מאַנשאַפֿט וואָס טאָן ניט וויסן דעם קאָד געשריבן אין די פריערדיקע יאָרן, אָדער אפילו ווי צו פּרובירן עס. 

אונדזער ערשטער אָטאַמייטיד טעסץ

צו דורכפירן די ערשטער אָטאַמייטיד טעסטינג אין Laravel, איר טאָן ניט דאַרפֿן צו שרייַבן קיין קאָד. יא, איר לייענען אַז רעכט. אַלץ איז שוין קאַנפיגיערד און צוגעגרייט אין די פאַר-ינסטאַלירונגdefiנייט פון לאַראַוועל, אַרייַנגערעכנט די זייער ערשטער ביישפּיל.

איר קענען פּרובירן צו ינסטאַלירן אַ לאַראַוועל פּרויעקט און לויפן די ערשטער טעסץ גלייך:

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() ווערט ליינעוודיק טעקסט ווען איר זען די פּראָבע רעזולטאַטן, פשוט דורך ריפּלייסינג די אַנדערליין סימבאָל מיט אַ פּלאַץ.

tests/Unit/ExampleTest.php:

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

סימז אַ ביסל ומזיניק, טשעק צו זען אויב דאָס איז אמת? 

מיר וועלן רעדן ספּעציעל וועגן אַפּאַראַט טעסץ אַ ביסל שפּעטער. איצט איר דאַרפֿן צו פֿאַרשטיין וואָס בכלל כאַפּאַנז אין יעדער פּראָבע.

• יעדער פּראָבע טעקע אין דער טעקע /tests איז אַ PHP קלאַס וואָס יקסטענדז די TestCase פון PHPUnit
• אין יעדער קלאַס, איר קענען מאַכן קייפל מעטהאָדס, יוזשאַוואַלי איין אופֿן פֿאַר אַ סיטואַציע צו פּרובירן
• אין יעדער אופֿן עס זענען דריי אַקשאַנז: פּריפּערינג די סיטואַציע, דאַן נעמען קאַמף און דאַן וועראַפייינג (אַפערמינג) צי די אַוטקאַם איז ווי דערוואַרט.

סטראַקטשעראַלי, דאָס איז אַלע איר דאַרפֿן צו וויסן, אַלץ אַנדערש דעפּענדס אויף די פּינטלעך טינגז איר ווילן צו פּרובירן.

צו דזשענערייט אַ ליידיק פּרובירן קלאַס, פשוט לויפן דעם באַפֿעל:

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, מיט דערקלערונגען אונטן און אַראָוז וואָס ווייזן צו די פּינטלעך שורה פון טעסץ וואָס האָבן ניט אַנדערש. ערראָרס זענען אנגעוויזן דעם וועג.

בייַשפּיל: טעסטינג רעגיסטראַציע פאָרעם קאָד אין לאַראַוועל

רעכן מיר האָבן אַ פאָרעם און מיר דאַרפֿן צו פּרובירן פאַרשידן קאַסעס: מיר טשעק אויב עס פיילז מיט פאַרקריפּלט דאַטן, מיר טשעק אויב עס איז געראָטן מיט די ריכטיק אַרייַנשרייַב, אאז"ו ו.

דער באַאַמטער סטאַרטער קיט דורך 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(). איר קענען קאָנטראָלירן אַלע די אַסערטשאַנז בנימצא אין דער באַאַמטער דאַקיומענטיישאַן פון PHPUnit 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),
        ];
    }
}

איר זען, ווי פילע טינגז זענען צוגעגרייט דורך 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, נאָכקרימען די פּינטלעך נאַטור ווי צו פּלאָמבירן די פאָרעם. שטריך טעסץ יוזשאַוואַלי דורכפירן די זעלבע אָדער ענלעך אַפּעריישאַנז ווי קיין פּרויעקט באַניצער וואָלט טאָן מאַניואַלי אין פאַקטיש לעבן.

אַפּאַראַט טעסץ האָבן צוויי מינינגז. אין אַלגעמיין, איר קען געפֿינען אַז קיין אָטאַמייטיד פּראָבע איז גערופֿן " אַפּאַראַט טעסטינג " און דער גאנצער פּראָצעס קענען זיין גערופֿן " אַפּאַראַט טעסטינג ". אָבער אין דעם קאָנטעקסט פון פאַנגקשאַנאַליטי קעגן אַפּאַראַט, דעם פּראָצעס איז וועגן טעסטינג אַ ספּעציפיש ניט-ציבור אַפּאַראַט פון קאָד, אין אפגעזונדערטקייט. פֿאַר בייַשפּיל, איר האָבן אַ לאַראַוועל קלאַס מיט אַ מעטאָד וואָס קאַלקיאַלייץ עפּעס, ווי די גאַנץ סדר פּרייַז מיט פּאַראַמעטערס. דעריבער, דער אַפּאַראַט פּרובירן וואָלט זאָגן צי ריכטיק רעזולטאַטן זענען אומגעקערט פֿון דעם אופֿן (קאָד אַפּאַראַט), מיט פאַרשידענע פּאַראַמעטערס.

צו דזשענערייט אַ אַפּאַראַט פּרובירן, איר דאַרפֿן צו לייגן אַ פאָן:

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
}

אין מיין פערזענלעכע דערפאַרונג מיט לאַראַוועל פּראַדזשעקס, די וואַסט מערהייַט פון טעסץ זענען שטריך טעסץ, נישט אַפּאַראַט טעסץ. ערשטער, איר דאַרפֿן צו פּרובירן צי דיין אַפּלאַקיישאַן אַרבעט, ווי פאַקטיש מענטשן וואָלט נוצן עס.

ווייַטער, אויב איר האָבן ספּעציעל חשבונות אָדער לאָגיק איר קענען defiווי אַ אַפּאַראַט, מיט פּאַראַמעטערס, איר קענען מאַכן אַפּאַראַט טעסץ ספּאַסיפיקלי פֿאַר דעם.

מאל, שרייבן טעסץ ריקווייערז מאָדיפיצירן די קאָד זיך און רעפאַקטאָרינג עס צו מאַכן עס מער "טעסטאַבאַל": סעפּערייטינג די וניץ אין ספּעציעל קלאסן אָדער מעטהאָדס.

ווען / ווי צו דורכפירן טעסץ?

וואָס איז די פאַקטיש נוצן פון דעם php artisan test, ווען זאָל איר לויפן עס?

עס זענען פאַרשידענע אַפּראָוטשיז, דיפּענדינג אויף דיין געשעפט וואָרקפלאָוו, אָבער בכלל איר דאַרפֿן צו ענשור אַז אַלע טעסץ זענען "גרין" (ד"ה טעות-פריי) איידער פּושינג די לעצטע קאָד ענדערונגען צו די ריפּאַזאַטאָרי.

דערנאָך איר אַרבעט לאָוקאַלי אויף דיין אַרבעט, און ווען איר טראַכטן איר האָט דורכגעקאָכט, לויפן עטלעכע טעסץ צו מאַכן זיכער אַז איר האָט נישט צעבראכן עפּעס. געדענקט, דיין קאָד קען פאַרשאַפן באַגז ניט בלויז אין דיין אייגענע לאָגיק, אָבער אויך אַנינטענשאַנאַלי ברעכן עטלעכע אנדערע נאַטור אין עמעצער אַנדערש ס קאָד געשריבן לאַנג צוריק.

אויב מיר נעמען עס אַ שריט ווייַטער, עס איז מעגלעך צו אָטאַמייט פילע זאכן. מיט פאַרשידן סי / קאָמפּאַקטדיסק מכשירים, איר קענען ספּעציפיצירן טעסץ צו לויפן ווען עמעצער פּושיז ענדערונגען צו אַ ספּעציפיש גיט צווייַג אָדער איידער צונויפגיסן קאָד אין די פּראָדוקציע צווייַג. די סימפּלאַסט וואָרקפלאָוו וואָלט זיין צו נוצן Github אַקטיאָנס, איך האָבן אַ באַזונדער ווידעא וואָס פּראָוועס עס.

וואָס זאָל איר פּרובירן?

עס זענען פאַרשידענע מיינונגען וועגן ווי גרויס די אַזוי גערופענע "פּרובירן קאַווערידזש" זאָל זיין: פּרובירן יעדער מעגלעך אָפּעראַציע און פאַל אויף יעדער בלאַט, אָדער באַגרענעצן די אַרבעט צו די מערסט וויכטיק טיילן.

אין פאַקט, דאָס איז ווו איך שטימען מיט מענטשן וואָס באַשולדיקן אָטאַמייטיד טעסטינג צו נעמען מער צייט ווי צו צושטעלן פאַקטיש נוץ. דאָס קען פּאַסירן אויב איר שרייַבן טעסץ פֿאַר יעדער דעטאַל. אַז איז, עס קען זיין פארלאנגט דורך דיין פּרויעקט: די הויפּט קשיא איז "וואָס איז די פּרייַז פון פּאָטענציעל טעות".

אין אנדערע ווערטער, איר דאַרפֿן צו פּרייאָראַטייז דיין טעסטינג השתדלות דורך פרעגן די קשיא "וואָס וואָלט פּאַסירן אויב דער קאָד ניט אַנדערש?" אויב דיין צאָלונג סיסטעם האט באַגז, דאָס וועט גלייך פּראַל אויף די געשעפט. אַזוי אויב די פאַנגקשאַנאַליטי פון דיין ראָלעס / פּערמישאַנז איז צעבראכן, דאָס איז אַ ריזיק זיכערהייט אַרויסגעבן.

איך האָב ליב ווי מאַט סטאַופער האָט דאָס געזאָגט אויף אַ זיצונג: "איר מוזן ערשטער פּרובירן די טינגז וואָס, אויב זיי דורכפאַל, וואָלט באַקומען איר פייערד פון דיין אַרבעט." דאָך, דאָס איז אַ גוזמע, אָבער איר באַקומען די געדאַנק: פּרובירן ערשטער די וויכטיק שטאָפּן. און דעמאָלט אנדערע פֿעיִקייטן, אויב איר האָט צייט.

PEST: אַ נייַע אנדער ברירה צו PHPUnit

אַלע די ביישפילן אויבן זענען באזירט אויף Laravel פאַר טעסטינג געצייַגdefiניט: PHPUnit . אָבער איבער די יאָרן אנדערע מכשירים האָבן ארויס אין די יקאָוסיסטאַם און איינער פון די לעצטע פאָלקס איז אָנשיקעניש . באשאפן דורך באַאַמטער לאַראַוועל אָנגעשטעלטער Nuno Maduro , יימז צו פאַרפּאָשעטערן די סינטאַקס, מאכן שרייבן קאָד פֿאַר טעסץ אפילו פאַסטער.

אונטער די קאַפּטער, עס לויפט su PHPUnit, ווי אַן נאָך שיכטע, נאָר טריינג צו מינאַמייז עטלעכע פאַר-ריפּיטיד פּאַרץdefiנייט פון די PHPUnit קאָד.

זאל ס קוק בייַ אַ בייַשפּיל. געדענקט די פּרע שטריך פּרובירן קלאַס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 פּראָבע אין Laravel, איר דאַרפֿן צו ספּעציפיצירן אַן נאָך פאָן:

php artisan make:test HomepageTest --pest

זינט דעם שרייבן, PEST איז גאַנץ פאָלקס צווישן לאַראַוועל דעוועלאָפּערס, אָבער עס איז דיין פערזענלעכע ייבערהאַנט צו נוצן דעם נאָך געצייַג און לערנען זיין סינטאַקס, ווי געזונט ווי אַ PHPUnit טאָן.

BlogInnovazione.it