ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಅಥವಾ ಘಟಕ ಪರೀಕ್ಷೆಗಳಿಗೆ ಬಂದಾಗ, ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ, ಎರಡು ವಿರುದ್ಧ ಅಭಿಪ್ರಾಯಗಳಿವೆ:
ಆದ್ದರಿಂದ, ಈ ಲೇಖನದೊಂದಿಗೆ ನಾವು ಮೊದಲಿನವರಿಗೆ ಮನವರಿಕೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ವಿಶೇಷವಾಗಿ Laravel ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವುದು ಎಷ್ಟು ಸುಲಭ ಎಂಬುದನ್ನು ಪ್ರದರ್ಶಿಸುವ ಮೂಲಕ.
ಮೊದಲು ನಾವು "ಏಕೆ" ಬಗ್ಗೆ ಮಾತನಾಡೋಣ, ಮತ್ತು ನಂತರ ಹೇಗೆ ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ನೋಡೋಣ.
ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ಕೋಡ್ನ ಭಾಗಗಳನ್ನು ರನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ದೋಷಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಅವುಗಳನ್ನು ವಿವರಿಸಲು ಇದು ಸರಳವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊರತರುವುದನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ, ಮತ್ತು ನಂತರ ವೈಯಕ್ತಿಕ ರೋಬೋಟ್ ಸಹಾಯಕರು ಹೋಗಿ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತಾರೆ, ಹೊಸ ಕೋಡ್ ಯಾವುದೇ ಹಳೆಯ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮುರಿಯಲಿಲ್ಲವೇ ಎಂದು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ.
ಇದು ಮುಖ್ಯ ಪ್ರಯೋಜನವಾಗಿದೆ: ಎಲ್ಲಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಪರೀಕ್ಷೆ ಮಾಡುವುದು. ಇದು ಹೆಚ್ಚುವರಿ ಕೆಲಸದಂತೆ ತೋರಬಹುದು, ಆದರೆ ನೀವು ಅದನ್ನು ಮಾಡಲು "ರೋಬೋಟ್" ಗೆ ಹೇಳದಿದ್ದರೆ, ನಾವು ಪರ್ಯಾಯವಾಗಿ ಅದನ್ನು ಕೈಯಾರೆ ಮಾಡಬೇಕು, ಸರಿ?
ಅಥವಾ ಬಳಕೆದಾರರು ದೋಷಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತಾರೆ ಎಂಬ ಆಶಯದೊಂದಿಗೆ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸದೆಯೇ ಬಿಡುಗಡೆ ಮಾಡಬಹುದು.
ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು ನಮಗೆ ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡಬಹುದು:
ಹಿಂದಿನ ವರ್ಷಗಳಲ್ಲಿ ಬರೆದ ಕೋಡ್ ಅಥವಾ ಅದನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬೇಕು ಎಂದು ತಿಳಿದಿಲ್ಲದ ತಂಡದಲ್ಲಿರುವ ಹೊಸ ಡೆವಲಪರ್ಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಂದು ಅಥವಾ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ ಕಲ್ಪಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸಿ.
ಮೊದಲನೆಯದನ್ನು ನಿರ್ವಹಿಸಲು ಲಾರಾವೆಲ್ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ, ನೀವು ಯಾವುದೇ ಕೋಡ್ ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲ. ಹೌದು, ನೀವು ಸರಿಯಾಗಿ ಓದಿದ್ದೀರಿ. ಎಲ್ಲವನ್ನೂ ಈಗಾಗಲೇ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಪೂರ್ವ-ಸ್ಥಾಪನೆಯಲ್ಲಿ ತಯಾರಿಸಲಾಗುತ್ತದೆdefiನೈಟ್ ಆಫ್ ಲಾರಾವೆಲ್, ಮೊದಲ ಮೂಲ ಉದಾಹರಣೆ ಸೇರಿದಂತೆ.
ನೀವು Laravel ಯೋಜನೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು ಮತ್ತು ತಕ್ಷಣವೇ ಮೊದಲ ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು:
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
ಇದು ಟೆಸ್ಟ್ಕೇಸ್ ಅನ್ನು ವಿಸ್ತರಿಸುವ ಪಿಎಚ್ಪಿ ವರ್ಗವಾಗಿದೆ PHP ಯುನಿಟ್ರಚನಾತ್ಮಕವಾಗಿ, ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದದ್ದು ಅಷ್ಟೆ, ಉಳಿದಂತೆ ನೀವು ಪರೀಕ್ಷಿಸಲು ಬಯಸುವ ನಿಖರವಾದ ವಿಷಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಖಾಲಿ ಪರೀಕ್ಷಾ ವರ್ಗವನ್ನು ರಚಿಸಲು, ಈ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ:
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()
. ಅಧಿಕೃತ ದಾಖಲೆಯಲ್ಲಿ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಸಮರ್ಥನೆಗಳನ್ನು ನೀವು ಪರಿಶೀಲಿಸಬಹುದು PHP ಯುನಿಟ್ 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_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();
}
}
ಇದು ಲಾಗಿನ್ ಫಾರ್ಮ್ ಬಗ್ಗೆ. ತರ್ಕವು ನೋಂದಣಿಗೆ ಹೋಲುತ್ತದೆ, ಸರಿ? ಆದರೆ ಎರಡು ವಿಧಾನಗಳ ಬದಲಿಗೆ ಮೂರು ವಿಧಾನಗಳು, ಆದ್ದರಿಂದ ಇದು ಒಳ್ಳೆಯ ಮತ್ತು ಕೆಟ್ಟ ಸನ್ನಿವೇಶಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ಉದಾಹರಣೆಯಾಗಿದೆ. ಆದ್ದರಿಂದ, ಸಾಮಾನ್ಯ ತರ್ಕವೆಂದರೆ ನೀವು ಎರಡೂ ಪ್ರಕರಣಗಳನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು: ವಿಷಯಗಳು ಉತ್ತಮವಾಗಿ ನಡೆದಾಗ ಮತ್ತು ಅವು ವಿಫಲವಾದಾಗ.
ಅಲ್ಲದೆ, ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ ನೀವು ನೋಡುತ್ತಿರುವುದು ಇದರ ಬಳಕೆಯಾಗಿದೆ ಡೇಟಾಬೇಸ್ ಕಾರ್ಖಾನೆಗಳು : ಲಾರಾವೆಲ್ ನಕಲಿ ಬಳಕೆದಾರರನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ( ಮತ್ತೊಮ್ಮೆ, ನಿಮ್ಮ ನವೀಕರಿಸಿದ ಪರೀಕ್ಷಾ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ) ತದನಂತರ ಸರಿಯಾದ ಅಥವಾ ತಪ್ಪಾದ ರುಜುವಾತುಗಳೊಂದಿಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ಮತ್ತೊಮ್ಮೆ, ಲಾರಾವೆಲ್ ಕಾರ್ಖಾನೆಯ ಪೂರ್ವವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ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),
];
}
}
ನೀವು ನೋಡಿ, 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 ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಹೊರಗೆ, ಹಲವಾರು ರೀತಿಯ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳಿವೆ. ನೀವು ಈ ರೀತಿಯ ಪದಗಳನ್ನು ಕಾಣಬಹುದು:
ಇದು ಜಟಿಲವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ಈ ರೀತಿಯ ಪರೀಕ್ಷೆಗಳ ನಡುವಿನ ನಿಜವಾದ ವ್ಯತ್ಯಾಸಗಳು ಕೆಲವೊಮ್ಮೆ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಅದಕ್ಕಾಗಿಯೇ ಲಾರಾವೆಲ್ ಈ ಎಲ್ಲಾ ಗೊಂದಲಮಯ ಪದಗಳನ್ನು ಸರಳೀಕರಿಸಿದ್ದಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಎರಡು ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಿದ್ದಾರೆ: ಘಟಕ/ವೈಶಿಷ್ಟ್ಯ.
ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ವೈಶಿಷ್ಟ್ಯ ಪರೀಕ್ಷೆಗಳು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗಳ ನೈಜ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ: 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
}
Laravel ಯೋಜನೆಗಳೊಂದಿಗಿನ ನನ್ನ ವೈಯಕ್ತಿಕ ಅನುಭವದಲ್ಲಿ, ಬಹುಪಾಲು ಪರೀಕ್ಷೆಗಳು ವೈಶಿಷ್ಟ್ಯ ಪರೀಕ್ಷೆಗಳು, ಘಟಕ ಪರೀಕ್ಷೆಗಳಲ್ಲ. ಮೊದಲಿಗೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂದು ನೀವು ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ, ನಿಜವಾದ ಜನರು ಅದನ್ನು ಬಳಸುವ ರೀತಿಯಲ್ಲಿ.
ಮುಂದೆ, ನೀವು ವಿಶೇಷ ಲೆಕ್ಕಾಚಾರಗಳು ಅಥವಾ ತರ್ಕವನ್ನು ಹೊಂದಿದ್ದರೆ ನೀವು ಮಾಡಬಹುದು definire ಒಂದು ಘಟಕವಾಗಿ, ನಿಯತಾಂಕಗಳೊಂದಿಗೆ, ನೀವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ರಚಿಸಬಹುದು.
ಕೆಲವೊಮ್ಮೆ, ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೆಚ್ಚು "ಪರೀಕ್ಷೆ" ಮಾಡಲು ಅದನ್ನು ಮರುಫಲಕ ಮಾಡುವುದು: ಘಟಕಗಳನ್ನು ವಿಶೇಷ ತರಗತಿಗಳು ಅಥವಾ ವಿಧಾನಗಳಾಗಿ ಪ್ರತ್ಯೇಕಿಸುವುದು.
ಇದರ ನಿಜವಾದ ಉಪಯೋಗವೇನು php artisan test
, ನೀವು ಅದನ್ನು ಯಾವಾಗ ಚಲಾಯಿಸಬೇಕು?
ನಿಮ್ಮ ವ್ಯಾಪಾರದ ಕೆಲಸದ ಹರಿವನ್ನು ಅವಲಂಬಿಸಿ ವಿಭಿನ್ನ ವಿಧಾನಗಳಿವೆ, ಆದರೆ ಅಂತಿಮ ಕೋಡ್ ಬದಲಾವಣೆಗಳನ್ನು ರೆಪೊಸಿಟರಿಗೆ ತಳ್ಳುವ ಮೊದಲು ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು "ಹಸಿರು" (ಅಂದರೆ ದೋಷ-ಮುಕ್ತ) ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.
ನಂತರ, ನಿಮ್ಮ ಕಾರ್ಯದಲ್ಲಿ ನೀವು ಸ್ಥಳೀಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ನೀವು ಮುಗಿಸಿದ್ದೀರಿ ಎಂದು ನೀವು ಭಾವಿಸಿದಾಗ, ನೀವು ಏನನ್ನೂ ಮುರಿದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕೆಲವು ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ. ನೆನಪಿಡಿ, ನಿಮ್ಮ ಕೋಡ್ ನಿಮ್ಮ ಸ್ವಂತ ತರ್ಕದಲ್ಲಿ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಆದರೆ ಬಹಳ ಹಿಂದೆಯೇ ಬರೆಯಲಾದ ಬೇರೊಬ್ಬರ ಕೋಡ್ನಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕೆಲವು ನಡವಳಿಕೆಯನ್ನು ಮುರಿಯಬಹುದು.
ನಾವು ಒಂದು ಹೆಜ್ಜೆ ಮುಂದೆ ಹೋದರೆ, ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಾಧ್ಯ ಅನೇಕ ವಿಷಯಗಳನ್ನು. ವಿವಿಧ CI/CD ಪರಿಕರಗಳೊಂದಿಗೆ, ಯಾರಾದರೂ ನಿರ್ದಿಷ್ಟ Git ಶಾಖೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ತಳ್ಳಿದಾಗ ಅಥವಾ ಉತ್ಪಾದನಾ ಶಾಖೆಗೆ ಕೋಡ್ ಅನ್ನು ವಿಲೀನಗೊಳಿಸುವ ಮೊದಲು ನೀವು ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಲು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. Github ಕ್ರಿಯೆಗಳನ್ನು ಬಳಸುವುದು ಸರಳವಾದ ಕೆಲಸದ ಹರಿವು, ನಾನು ಹೊಂದಿದ್ದೇನೆ ಪ್ರತ್ಯೇಕ ವೀಡಿಯೊ ಇದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
"ಪರೀಕ್ಷಾ ಕವರೇಜ್" ಎಂದು ಕರೆಯಲ್ಪಡುವಿಕೆಯು ಎಷ್ಟು ದೊಡ್ಡದಾಗಿರಬೇಕು ಎಂಬುದರ ಕುರಿತು ವಿಭಿನ್ನ ಅಭಿಪ್ರಾಯಗಳಿವೆ: ಪ್ರತಿ ಪುಟದಲ್ಲಿ ಸಾಧ್ಯವಿರುವ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಪ್ರಕರಣವನ್ನು ಪ್ರಯತ್ನಿಸಿ, ಅಥವಾ ಕೆಲಸವನ್ನು ಪ್ರಮುಖ ಭಾಗಗಳಿಗೆ ಮಿತಿಗೊಳಿಸಿ.
ವಾಸ್ತವವಾಗಿ, ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯು ನಿಜವಾದ ಪ್ರಯೋಜನವನ್ನು ಒದಗಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಆರೋಪಿಸುವ ಜನರೊಂದಿಗೆ ನಾನು ಒಪ್ಪುತ್ತೇನೆ. ನೀವು ಪ್ರತಿಯೊಂದು ವಿವರಗಳಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆದರೆ ಇದು ಸಂಭವಿಸಬಹುದು. ಅದು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ನಿಂದ ಅಗತ್ಯವಾಗಬಹುದು: "ಸಂಭಾವ್ಯ ದೋಷದ ಬೆಲೆ ಏನು" ಎಂಬುದು ಮುಖ್ಯ ಪ್ರಶ್ನೆಯಾಗಿದೆ.
ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, “ಈ ಕೋಡ್ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ?” ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವ ಮೂಲಕ ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಪ್ರಯತ್ನಗಳಿಗೆ ನೀವು ಆದ್ಯತೆ ನೀಡಬೇಕು. ನಿಮ್ಮ ಪಾವತಿ ವ್ಯವಸ್ಥೆಯು ದೋಷಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ನೇರವಾಗಿ ವ್ಯಾಪಾರದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಆದ್ದರಿಂದ ನಿಮ್ಮ ಪಾತ್ರಗಳು/ಅನುಮತಿಗಳ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಮುರಿದುಹೋದರೆ, ಇದು ದೊಡ್ಡ ಭದ್ರತಾ ಸಮಸ್ಯೆಯಾಗಿದೆ.
ಮ್ಯಾಟ್ ಸ್ಟಾಫರ್ ಇದನ್ನು ಸಮ್ಮೇಳನದಲ್ಲಿ ಹೇಗೆ ಹೇಳಬೇಕೆಂದು ನಾನು ಇಷ್ಟಪಡುತ್ತೇನೆ: "ನೀವು ಮೊದಲು ಆ ವಿಷಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು, ಅವುಗಳು ವಿಫಲವಾದರೆ, ನಿಮ್ಮ ಕೆಲಸದಿಂದ ನಿಮ್ಮನ್ನು ವಜಾಗೊಳಿಸಬಹುದು." ಸಹಜವಾಗಿ ಇದು ಉತ್ಪ್ರೇಕ್ಷೆಯಾಗಿದೆ, ಆದರೆ ನೀವು ಕಲ್ಪನೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ: ಮೊದಲು ಪ್ರಮುಖ ವಿಷಯವನ್ನು ಪ್ರಯತ್ನಿಸಿ. ತದನಂತರ ಇತರ ವೈಶಿಷ್ಟ್ಯಗಳು, ನಿಮಗೆ ಸಮಯವಿದ್ದರೆ.
ಮೇಲಿನ ಎಲ್ಲಾ ಉದಾಹರಣೆಗಳು Laravel ಪೂರ್ವ ಪರೀಕ್ಷಾ ಉಪಕರಣವನ್ನು ಆಧರಿಸಿವೆdefiರಾತ್ರಿ: PHP ಯುನಿಟ್ . ಆದರೆ ವರ್ಷಗಳಲ್ಲಿ ಇತರ ಉಪಕರಣಗಳು ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿವೆ ಮತ್ತು ಇತ್ತೀಚಿನ ಜನಪ್ರಿಯವಾದವುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ 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 ಯ ಗುರಿಯು ಓವರ್ಹೆಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು:
Laravel ನಲ್ಲಿ PEST ಪರೀಕ್ಷೆಯನ್ನು ರಚಿಸಲು, ನೀವು ಹೆಚ್ಚುವರಿ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿದೆ:
php artisan make:test HomepageTest --pest
ಈ ಬರವಣಿಗೆಯ ಪ್ರಕಾರ, PEST ಲಾರಾವೆಲ್ ಡೆವಲಪರ್ಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಜನಪ್ರಿಯವಾಗಿದೆ, ಆದರೆ ಈ ಹೆಚ್ಚುವರಿ ಉಪಕರಣವನ್ನು ಬಳಸಬೇಕೆ ಮತ್ತು ಅದರ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಕಲಿಯಬೇಕೆ ಅಥವಾ PHPUnit ಟಿಪ್ಪಣಿಯನ್ನು ಕಲಿಯಬೇಕೆ ಎಂಬುದು ನಿಮ್ಮ ವೈಯಕ್ತಿಕ ಆದ್ಯತೆಯಾಗಿದೆ.
BlogInnovazione.it
ಬಣ್ಣಗಳ ಮೂಲಕ ಉತ್ತಮವಾದ ಮೋಟಾರು ಕೌಶಲ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಬರವಣಿಗೆಯಂತಹ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಕೌಶಲ್ಯಗಳಿಗೆ ಮಕ್ಕಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಬಣ್ಣ ಹಾಕಲು...
ನೌಕಾ ವಲಯವು ನಿಜವಾದ ಜಾಗತಿಕ ಆರ್ಥಿಕ ಶಕ್ತಿಯಾಗಿದೆ, ಇದು 150 ಶತಕೋಟಿ ಮಾರುಕಟ್ಟೆಯತ್ತ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಿದೆ...
ಕಳೆದ ಸೋಮವಾರ, ಫೈನಾನ್ಶಿಯಲ್ ಟೈಮ್ಸ್ ಓಪನ್ ಎಐ ಜೊತೆ ಒಪ್ಪಂದವನ್ನು ಪ್ರಕಟಿಸಿತು. FT ತನ್ನ ವಿಶ್ವ ದರ್ಜೆಯ ಪತ್ರಿಕೋದ್ಯಮಕ್ಕೆ ಪರವಾನಗಿ ನೀಡುತ್ತದೆ…
ಲಕ್ಷಾಂತರ ಜನರು ಸ್ಟ್ರೀಮಿಂಗ್ ಸೇವೆಗಳಿಗೆ ಪಾವತಿಸುತ್ತಾರೆ, ಮಾಸಿಕ ಚಂದಾದಾರಿಕೆ ಶುಲ್ಕವನ್ನು ಪಾವತಿಸುತ್ತಾರೆ. ನೀವು ಎಂಬುದು ಸಾಮಾನ್ಯ ಅಭಿಪ್ರಾಯ…