जब किसी भी प्रोग्रामिंग भाषा में स्वचालित परीक्षण या इकाई परीक्षण की बात आती है, तो दो विरोधी राय होती हैं:
इसलिए, इस लेख के साथ हम पूर्व को समझाने की कोशिश करेंगे, विशेष रूप से यह प्रदर्शित करके कि लारवेल में स्वचालित परीक्षण शुरू करना कितना आसान है।
पहले आइए "क्यों" के बारे में बात करें, और फिर कैसे के कुछ उदाहरण देखें।
स्वचालित परीक्षण कोड के कुछ हिस्सों को चलाते हैं और किसी भी त्रुटि की रिपोर्ट करते हैं। उनका वर्णन करने का यह सबसे सरल तरीका है। एक ऐप में एक नई सुविधा शुरू करने की कल्पना करें, और फिर एक व्यक्तिगत रोबोट सहायक जाएगा और मैन्युअल रूप से नई सुविधा का परीक्षण करेगा, साथ ही यह भी परीक्षण करेगा कि नया कोड किसी भी पुरानी सुविधा को तोड़ तो नहीं रहा है।
यह मुख्य लाभ है: सभी सुविधाओं का स्वचालित रूप से पुनः परीक्षण करना। यह अतिरिक्त काम की तरह लग सकता है, लेकिन यदि आप "रोबोट" को इसे करने के लिए नहीं कहते हैं, तो हमें वैकल्पिक रूप से इसे मैन्युअल रूप से करना चाहिए, है ना?
या नई सुविधाओं को यह परीक्षण किए बिना जारी किया जा सकता है कि वे काम करती हैं या नहीं, इस उम्मीद में कि उपयोगकर्ता बग की रिपोर्ट करेंगे।
स्वचालित परीक्षण हमें कई लाभ दे सकते हैं:
एक या दो साल में अपने एप्लिकेशन की कल्पना करने का प्रयास करें, टीम में नए डेवलपर्स होंगे जो पिछले वर्षों में लिखे गए कोड को नहीं जानते हैं, या यहां तक कि इसका परीक्षण कैसे करें।
पहला प्रदर्शन करना लारवेल में स्वचालित परीक्षण, आपको कोई कोड लिखने की आवश्यकता नहीं है। हां, आपने उसे सही पढ़ा है। प्री-इंस्टॉलेशन में सब कुछ पहले से ही कॉन्फ़िगर और तैयार किया गया है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() जब आप परीक्षण परिणाम देखते हैं तो केवल अंडरलाइन चिह्न को एक स्थान से प्रतिस्थापित करने से यह पढ़ने योग्य पाठ बन जाता है।
परीक्षण/यूनिट/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दो विफल परीक्षण हैं, जिन्हें विफल के रूप में चिह्नित किया गया है, नीचे स्पष्टीकरण और तीर विफल परीक्षणों की सटीक पंक्ति की ओर इशारा करते हैं। त्रुटियों को इस प्रकार दर्शाया गया है।
मान लीजिए कि हमारे पास एक फॉर्म है और हमें विभिन्न मामलों का परीक्षण करने की आवश्यकता है: हम जांचते हैं कि क्या यह अमान्य डेटा के साथ विफल होता है, हम जांचते हैं कि क्या यह सही इनपुट के साथ सफल होता है, आदि।
आधिकारिक स्टार्टर किट लारवेल ब्रीज़ द्वारा मैं शामिल हैं इसके भीतर कार्यक्षमता का परीक्षण करना. आइए वहां से कुछ उदाहरण देखें:
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',
]);
आइए अब लारवेल ब्रीज़ के साथ लॉगिन पेज का एक और उदाहरण देखें
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नीता के लिए गलत डेटा है 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 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 Actions का उपयोग करना होगा एक अलग वीडियो जो इसे साबित करता है.
तथाकथित "परीक्षण कवरेज" कितना बड़ा होना चाहिए, इस पर अलग-अलग राय हैं: प्रत्येक पृष्ठ पर हर संभव ऑपरेशन और मामले का प्रयास करें, या काम को सबसे महत्वपूर्ण भागों तक सीमित रखें।
वास्तव में, यहीं पर मैं उन लोगों से सहमत हूं जो स्वचालित परीक्षण पर वास्तविक लाभ प्रदान करने की तुलना में अधिक समय लेने का आरोप लगाते हैं। ऐसा तब हो सकता है जब आप प्रत्येक विवरण के लिए परीक्षण लिखें। जैसा कि कहा गया है, आपके प्रोजेक्ट के लिए इसकी आवश्यकता हो सकती है: मुख्य प्रश्न यह है कि "संभावित त्रुटि की कीमत क्या है"।
दूसरे शब्दों में, आपको यह प्रश्न पूछकर अपने परीक्षण प्रयासों को प्राथमिकता देने की आवश्यकता है कि "यदि यह कोड विफल हो गया तो क्या होगा?" अगर आपके पेमेंट सिस्टम में बग हैं तो इसका सीधा असर बिजनेस पर पड़ेगा। इसलिए यदि आपकी भूमिकाओं/अनुमतियों की कार्यक्षमता टूट गई है, तो यह एक बहुत बड़ा सुरक्षा मुद्दा है।
मुझे यह पसंद है कि मैट स्टॉफ़र ने एक सम्मेलन में इसे कैसे कहा: "आपको पहले उन चीजों का परीक्षण करना होगा, जो विफल होने पर आपको नौकरी से निकाल दिया जाएगा।" निःसंदेह यह अतिशयोक्ति है, लेकिन आपको यह विचार आता है: पहले महत्वपूर्ण चीज़ों को आज़माएँ। और फिर अन्य सुविधाएँ, यदि आपके पास समय हो।
उपरोक्त सभी उदाहरण लारवेल प्री टेस्टिंग टूल पर आधारित हैंdefiरात: PHPUnit . लेकिन पिछले कुछ वर्षों में पारिस्थितिकी तंत्र में अन्य उपकरण सामने आए हैं और नवीनतम लोकप्रिय उपकरणों में से एक है 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 परीक्षण उत्पन्न करने के लिए, आपको एक अतिरिक्त ध्वज निर्दिष्ट करना होगा:
php artisan make:test HomepageTest --pestइस लेखन के समय, PEST लारवेल डेवलपर्स के बीच काफी लोकप्रिय है, लेकिन यह आपकी व्यक्तिगत प्राथमिकता है कि आप इस अतिरिक्त टूल का उपयोग करें और इसका सिंटैक्स सीखें, साथ ही एक PHPUnit नोट भी सीखें।
BlogInnovazione.it
रंग भरने के माध्यम से बढ़िया मोटर कौशल विकसित करना बच्चों को लेखन जैसे अधिक जटिल कौशल के लिए तैयार करता है। रंग भरना…
नौसैनिक क्षेत्र एक सच्ची वैश्विक आर्थिक शक्ति है, जो 150 अरब के बाज़ार की ओर बढ़ चुका है...
पिछले सोमवार को, फाइनेंशियल टाइम्स ने OpenAI के साथ एक समझौते की घोषणा की। एफटी अपनी विश्व स्तरीय पत्रकारिता को लाइसेंस देता है...
लाखों लोग स्ट्रीमिंग सेवाओं के लिए मासिक सदस्यता शुल्क का भुगतान करते हैं। यह आम राय है कि आप...