जब यो स्वचालित परीक्षण वा एकाइ परीक्षण को लागी आउँछ, कुनै पनि प्रोग्रामिङ भाषामा, त्यहाँ दुई विरोधी विचारहरू छन्:
त्यसोभए, यस लेखको साथ हामी पूर्वलाई विश्वस्त पार्ने प्रयास गर्नेछौं, विशेष गरी यो लारावेलमा स्वचालित परीक्षणको साथ सुरू गर्न कत्तिको सजिलो छ भनेर प्रदर्शन गरेर।
पहिले हामी "किन" को बारेमा कुरा गरौं, र त्यसपछि कसरी को केहि उदाहरणहरू हेरौं।
स्वचालित परीक्षणहरूले कोडका भागहरू चलाउँछन् र कुनै त्रुटिहरू रिपोर्ट गर्छन्। तिनीहरूलाई वर्णन गर्ने सबैभन्दा सरल तरिका हो। एउटा एपमा नयाँ सुविधा सुरु गर्ने कल्पना गर्नुहोस्, र त्यसपछि एक व्यक्तिगत रोबोट सहायकले जान्छ र म्यानुअल रूपमा नयाँ सुविधाको परीक्षण गर्नेछ, जबकि नयाँ कोडले पुरानो सुविधाहरू तोडेको छैन कि छैन भनेर पनि परीक्षण गर्नेछ।
यो मुख्य फाइदा हो: स्वचालित रूपमा सबै सुविधाहरू पुन: परीक्षण। यो अतिरिक्त काम जस्तो लाग्न सक्छ, तर यदि तपाईंले "रोबोट" लाई यो गर्न भन्नुहुन्न भने, हामीले वैकल्पिक रूपमा यसलाई म्यानुअल रूपमा गर्नुपर्छ, हैन?
वा नयाँ सुविधाहरू तिनीहरूले काम गर्छन् कि छैनन् परीक्षण बिना जारी गर्न सकिन्छ, आशा छ कि प्रयोगकर्ताहरूले बगहरू रिपोर्ट गर्नेछन्।
स्वचालित परीक्षणहरूले हामीलाई धेरै फाइदाहरू दिन सक्छ:
विगतका वर्षहरूमा लेखिएको कोड, वा कसरी परीक्षण गर्ने भनेर थाहा नभएका टोलीमा नयाँ विकासकर्ताहरूसँग एक वा दुई वर्षमा तपाईंको आवेदन कल्पना गर्ने प्रयास गर्नुहोस्।
पहिलो प्रदर्शन गर्न Laravel मा स्वचालित परीक्षण, तपाईंले कुनै पनि कोड लेख्न आवश्यक छैन। हो, तपाईंले त्यो सही पढ्नुभयो। सबै कुरा पहिले नै कन्फिगर गरिएको छ र पूर्व-स्थापनामा तयार छdefiLaravel को nite, धेरै पहिलो आधारभूत उदाहरण सहित।
तपाईं Laravel परियोजना स्थापना गर्न प्रयास गर्न सक्नुहुन्छ र तुरुन्तै पहिलो परीक्षणहरू चलाउन सक्नुहुन्छ:
laravel new project
cd project
php artisan test
यो तपाईंको कन्सोलमा परिणाम हुनुपर्छ:
यदि हामी पूर्व मा एक नजर राख्छौंdefiLaravel को रात /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 को विस्तार गर्दछ 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 को रूपमा चिन्ह लगाइएको छ, तल स्पष्टीकरणहरू र तीरहरू असफल भएका परीक्षणहरूको सही रेखालाई संकेत गर्दै। त्रुटिहरू यसरी संकेत गरिएका छन्।
मानौं हामीसँग एउटा फारम छ र हामीले विभिन्न केसहरू परीक्षण गर्न आवश्यक छ: हामी जाँच गर्छौं कि यो अमान्य डेटाको साथ असफल भयो भने, हामी जाँच गर्छौं कि यो सही इनपुटको साथ सफल हुन्छ, आदि।
आधिकारिक स्टार्टर किट Laravel Breeze द्वारा 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 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_CONNECTION
e 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),
];
}
}
तपाईंले हेर्नुभयो, लारावेल आफैंले कति चीजहरू तयार पारेका छन्, त्यसोभए हामीलाई परीक्षण सुरु गर्न सजिलो हुन्छ?
त्यसोभए यदि हामी कार्यान्वयन गर्छौं 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
उत्पन्न कोड पूर्व एकाइ परीक्षण जस्तै होdefiLaravel प्रणाली:
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
}
Laravel परियोजनाहरूसँग मेरो व्यक्तिगत अनुभवमा, परीक्षणहरूको विशाल बहुमत फीचर परीक्षणहरू हुन्, एकाइ परीक्षणहरू होइनन्। पहिले, तपाईंले परीक्षण गर्न आवश्यक छ कि तपाईंको अनुप्रयोगले काम गर्दछ, वास्तविक मानिसहरूले यसलाई कसरी प्रयोग गर्नेछन्।
अर्को, यदि तपाइँसँग विशेष गणना वा तर्क छ भने तपाइँ गर्न सक्नुहुन्छ definire लाई एक एकाइको रूपमा, प्यारामिटरहरूको साथ, तपाइँ यसको लागि विशेष रूपमा एकाइ परीक्षणहरू सिर्जना गर्न सक्नुहुन्छ।
कहिलेकाहीं, परीक्षण लेखनको लागि कोड आफैं परिमार्जन गर्न र यसलाई थप "परीक्षणयोग्य" बनाउनको लागि पुन: फ्याक्टर गर्न आवश्यक छ: एकाइहरूलाई विशेष कक्षा वा विधिहरूमा विभाजन गर्दै।
यसको वास्तविक उपयोग के हो php artisan test
, तपाईंले यसलाई कहिले चलाउनु पर्छ?
तपाईंको व्यापार कार्यप्रवाहमा निर्भर गर्दै, त्यहाँ विभिन्न दृष्टिकोणहरू छन्, तर सामान्यतया तपाईंले भण्डारमा नवीनतम कोड परिवर्तनहरू धकेल्न अघि सबै परीक्षणहरू "हरियो" (अर्थात त्रुटि-मुक्त) छन् भनेर सुनिश्चित गर्न आवश्यक छ।
त्यसपछि, तपाइँ आफ्नो कार्यमा स्थानीय रूपमा काम गर्नुहुन्छ, र जब तपाइँ सोच्नुहुन्छ कि तपाइँ सकियो, तपाइँले केहि तोडेको छैन भनेर निश्चित गर्न केहि परीक्षणहरू चलाउनुहोस्। याद गर्नुहोस्, तपाईंको कोडले तपाईंको आफ्नै तर्कमा मात्र नभई धेरै पहिले लेखिएको अरू कसैको कोडमा पनि अनजानमा केही अन्य व्यवहारहरू तोड्न सक्छ।
यदि हामी यसलाई एक कदम अगाडि बढाउँछौं भने, यो स्वचालित गर्न सम्भव छ धेरै चीजहरू। विभिन्न CI/CD उपकरणहरूसँग, तपाईले परीक्षणहरू निर्दिष्ट गर्न सक्नुहुन्छ जब कसैले कुनै विशिष्ट Git शाखामा परिवर्तनहरू वा उत्पादन शाखामा कोड मर्ज गर्नु अघि धक्का दिन्छ। सरल कार्यप्रवाह Github कार्यहरू प्रयोग गर्न हुनेछ, मसँग छ एक अलग भिडियो जसले प्रमाणित गर्छ ।
तथाकथित "परीक्षण कभरेज" कत्तिको ठुलो हुनु पर्छ भन्ने बारे विभिन्न विचारहरू छन्: प्रत्येक पृष्ठमा प्रत्येक सम्भावित अपरेशन र केस प्रयास गर्नुहोस्, वा कामलाई सबैभन्दा महत्त्वपूर्ण भागहरूमा सीमित गर्नुहोस्।
वास्तवमा, यो जहाँ म ती व्यक्तिहरूसँग सहमत छु जसले वास्तविक लाभ प्रदान गर्नु भन्दा बढी समय लिने स्वचालित परीक्षणलाई आरोप लगाउँछन्। यदि तपाइँ प्रत्येक एकल विवरणको लागि परीक्षण लेख्नुहुन्छ भने यो हुन सक्छ। उनले भने, यो तपाइँको परियोजना द्वारा आवश्यक हुन सक्छ: मुख्य प्रश्न "सम्भावित त्रुटि को मूल्य के हो" हो।
अन्य शब्दहरूमा, तपाईंले प्रश्न सोधेर आफ्नो परीक्षण प्रयासहरूलाई प्राथमिकता दिन आवश्यक छ "यदि यो कोड असफल भयो भने के हुनेछ?" यदि तपाईंको भुक्तानी प्रणालीमा बगहरू छन् भने, यसले सीधा व्यापारलाई असर गर्नेछ। त्यसोभए यदि तपाईंको भूमिका/अनुमतिहरूको कार्यक्षमता बिग्रिएको छ भने, यो ठूलो सुरक्षा समस्या हो।
मलाई मन पर्छ कि म्याट स्टाउफरले सम्मेलनमा यो कसरी राख्यो: "तपाईले पहिले ती चीजहरूको परीक्षण गर्नुपर्छ कि, यदि तिनीहरू असफल भएमा, तपाइँलाई तपाइँको जागिरबाट बर्खास्त गरिनेछ।" निस्सन्देह यो एक अतिशयोक्ति हो, तर तपाईंले विचार पाउनुभयो: महत्त्वपूर्ण सामान पहिले प्रयास गर्नुहोस्। र त्यसपछि अन्य सुविधाहरू, यदि तपाईंसँग समय छ भने।
माथिका सबै उदाहरणहरू Laravel पूर्व परीक्षण उपकरणमा आधारित छन्defiरात: PHPU युनिट । तर वर्षौंको दौडान अन्य उपकरणहरू इकोसिस्टममा देखा परेका छन् र नवीनतम लोकप्रिय मध्ये एक हो कीट । आधिकारिक Laravel कर्मचारी द्वारा बनाईएको नुनो मादुरो , सिन्ट्याक्सलाई सरल बनाउने लक्ष्य राख्छ, परीक्षणको लागि कोड लेखन अझ छिटो बनाउँछ।
हुड मुनि, यो चल्छ su PHPUnit, एक अतिरिक्त तहको रूपमा, केवल केहि पूर्व-दोहोरिने भागहरू कम गर्न प्रयास गर्दैdefiPHPUnit कोडको नाइट।
एउटा उदाहरण हेरौं। पूर्व सुविधा परीक्षण कक्षा सम्झनुहोस्defiLaravel मा nited? म तपाईंलाई सम्झाउनेछु:
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 को लक्ष्य निम्नको ओभरहेड हटाउनु हो:
Laravel मा PEST परीक्षण उत्पन्न गर्न, तपाईंले अतिरिक्त झण्डा निर्दिष्ट गर्न आवश्यक छ:
php artisan make:test HomepageTest --pest
यस लेखनको रूपमा, PEST Laravel विकासकर्ताहरू बीच धेरै लोकप्रिय छ, तर यो अतिरिक्त उपकरण प्रयोग गर्ने र यसको सिन्ट्याक्स, साथै PHPUnit नोट सिक्ने कि तपाइँको व्यक्तिगत प्राथमिकता हो।
BlogInnovazione.it
गत सोमबार, फाइनान्सियल टाइम्सले OpenAI सँग सम्झौताको घोषणा गर्यो। FT ले आफ्नो विश्व स्तरीय पत्रकारिता लाई लाइसेन्स...
लाखौं मानिसहरूले स्ट्रिमिङ सेवाहरूको लागि भुक्तानी गर्छन्, मासिक सदस्यता शुल्क तिर्छन्। यो आम धारणा छ कि तपाईं…
Veeam द्वारा Coveware ले साइबर जबरजस्ती घटना प्रतिक्रिया सेवाहरू प्रदान गर्न जारी राख्नेछ। Coveware ले फोरेन्सिक र उपचार क्षमताहरू प्रदान गर्दछ ...
अनुमानित मर्मतसम्भारले तेल र ग्यास क्षेत्रमा क्रान्तिकारी परिवर्तन गर्दैछ, बिरुवा व्यवस्थापनको लागि एक नवीन र सक्रिय दृष्टिकोणको साथ।…