🕑 〽️ 🎂 लारवेल में यूनिट परीक्षण ✌🏼 👇 📤

समुदाय में चर्चाओं के बीच, मैं अक्सर यह राय सुनता हूं कि लारवेल में इकाई परीक्षण गलत, जटिल है, और परीक्षण स्वयं लंबे हैं और कोई लाभ नहीं देते हैं। इस वजह से, कुछ लोग इन परीक्षणों को लिखते हैं, केवल फीचर परीक्षण के लिए खुद को सीमित करते हैं, और यूनिट परीक्षणों का उपयोग 0 तक जाता है।
मैंने भी एक बार ऐसा सोचा था, लेकिन एक बार मैंने इसके बारे में सोचा और खुद से पूछा - शायद मैं नहीं जानता कि उन्हें कैसे खाना बनाना है?

कुछ समय के लिए मैं समझ गया और बाहर निकलने पर मुझे यूनिट परीक्षणों के बारे में एक नई समझ थी, और परीक्षण स्पष्ट, अनुकूल, तेज हो गए और मेरी मदद करने लगे।
मैं समुदाय के साथ अपनी समझ को साझा करना चाहता हूं, और यहां तक कि इस विषय को बेहतर ढंग से समझने के साथ अपने परीक्षणों को और बेहतर बना सकता हूं।

दर्शन और सीमाओं का एक सा

लारवेल कुछ जगहों पर एक तरह की रूपरेखा है। खासतौर पर facades और Eloquent के संदर्भ में। मैं इन बिंदुओं की चर्चा या निंदा पर नहीं छूऊंगा, लेकिन मैं यह दिखाऊंगा कि मैं उन्हें यूनिट परीक्षणों के साथ कैसे संयोजित करता हूं।
मैं मुख्य कोड लिखने के बाद (या उसी समय) परीक्षण लिखता हूं। शायद मेरा दृष्टिकोण टीडीडी दृष्टिकोण के अनुकूल नहीं होगा या आंशिक समायोजन की आवश्यकता होगी।

टेस्ट लिखने से पहले मैं खुद से जो सबसे महत्वपूर्ण सवाल पूछता हूं, वह है "मैं वास्तव में क्या परीक्षण करना चाहता हूं?" यह एक महत्वपूर्ण मुद्दा है। यह विचार था जिसने मुझे इकाई परीक्षण और परियोजना कोड लिखने पर अपने विचारों पर पुनर्विचार करने की अनुमति दी।

टेस्ट स्थिर और न्यूनतम रूप से पर्यावरण पर निर्भर होना चाहिए। यदि, जब आप उत्परिवर्तन करते हैं, तो आपके परीक्षण विफल हो जाते हैं, सबसे अधिक संभावना है कि वे अच्छे हैं। इसके विपरीत, यदि वे नहीं गिरते हैं, तो वे संभवतः बहुत अच्छे नहीं हैं।

बॉक्स से बाहर, लारवेल 3 प्रकार के परीक्षणों का समर्थन करता है:

ब्राउज़र
फ़ीचर
इकाई

मैं मुख्य रूप से यूनिट परीक्षणों के बारे में बात करूंगा।

मैं इकाई परीक्षणों के माध्यम से सभी कोड का परीक्षण नहीं करता हूं (शायद यह सही नहीं है)। मैं कुछ कोड का परीक्षण नहीं करता (अधिक इस पर नीचे)।

यदि परीक्षणों में मूस का उपयोग किया जाता है, तो आंसू पर Mockery :: close () करना न भूलें।

परीक्षणों के कुछ उदाहरण "इंटरनेट से लिए गए हैं।"

मैं परीक्षा कैसे दूं?

नीचे मैं समूह समूह द्वारा उदाहरणों का परीक्षण करूँगा और प्रत्येक वर्ग समूह के लिए परीक्षण उदाहरण देने का प्रयास करूँगा। अधिकांश वर्ग समूहों के लिए, मैं स्वयं कोड का उदाहरण नहीं दूंगा।

middleware

मिडिलवेयर यूनिट टेस्ट के लिए, मैं अनुरोध वर्ग का एक ऑब्जेक्ट बनाता हूं, वांछित मिडलवेयर का एक ऑब्जेक्ट, फिर मैं हैंडल विधि को कॉल करता हूं और आवश्यक एस्कॉर्ट्स निष्पादित करता हूं। किए गए कार्यों के अनुसार मिडलवेयर को 3 समूहों में विभाजित किया जा सकता है:

बदलती अनुरोध वस्तु (शरीर का अनुरोध, या सत्र बदलना)
पुनर्निर्देशन (प्रतिक्रिया की स्थिति बदलना)
अनुरोध वस्तु के साथ कुछ नहीं करना
आइए प्रत्येक समूह के लिए एक परीक्षा का उदाहरण देने का प्रयास करें:

मान लें कि हमारे पास निम्न मिडिलवेयर हैं, जिनका कार्य शीर्षक क्षेत्र को संशोधित करना है:

class TitlecaseMiddleware { public function handle($request, Closure $next) { if ($request->title) { $request->merge([ 'title' => title_case($request->title) ]); } return $next($request); } }

एक समान मिडलवेयर के लिए एक परीक्षण इस तरह दिख सकता है:

 public function testChangeTitleToTitlecase() { $request = new Request; $request->merge([ 'title' => 'Title is in mixed CASE' ]); $middleware = new TitlecaseMiddleware; $middleware->handle($request, function ($req) { $this->assertEquals('Title Is In Mixed Case', $req->title); }); }

समूह 2 और 3 के लिए टेस्ट क्रमशः इस तरह की योजना के होंगे:

 $response = $middleware->handle($request, function () {}); $this->assertEquals($response->getStatusCode(), 302); //   $this->assertEquals($response, null); //      request

अनुरोध वर्ग

इस वर्ग समूह का मुख्य कार्य प्राधिकरण और अनुरोधों का सत्यापन है।

मैं यूनिट परीक्षणों के माध्यम से इन कक्षाओं का परीक्षण नहीं करता (मैं मानता हूं कि यह सच नहीं हो सकता है), केवल फीचर परीक्षणों के माध्यम से। मेरी राय में, इन कक्षाओं के लिए यूनिट परीक्षण निरर्थक हैं, लेकिन मुझे कुछ दिलचस्प उदाहरण मिले कि यह कैसे किया जा सकता है। यदि आप परीक्षण के साथ अपनी अनुरोध इकाई कक्षा का परीक्षण करने का निर्णय लेते हैं तो शायद वे आपकी मदद करेंगे:

नियंत्रक

मैं यूनिट परीक्षणों के माध्यम से नियंत्रकों का परीक्षण भी नहीं करता हूं। लेकिन उनका परीक्षण करते समय, मैं एक विशेषता का उपयोग करता हूं जिसके बारे में मैं बात करना चाहूंगा।

नियंत्रकों, मेरी राय में, हल्का होना चाहिए। उनका कार्य सही अनुरोध प्राप्त करना है, आवश्यक सेवाओं और रिपॉजिटरी को कॉल करना है (चूंकि ये दोनों पद लारवेल के लिए "विदेशी" हैं, मैं नीचे अपनी शब्दावली समझाऊंगा), उत्तर लौटाएं। कभी-कभी किसी घटना, नौकरी आदि को ट्रिगर करें।
तदनुसार, जब सुविधा परीक्षणों के माध्यम से परीक्षण किया जाता है, तो हमें न केवल आवश्यक मापदंडों के साथ नियंत्रक को कॉल करने और उत्तर की जांच करने की आवश्यकता है, बल्कि आवश्यक सेवाओं को भी लॉक करें और सत्यापित करें कि उन्हें वास्तव में बुलाया जा रहा है (या नहीं बुलाया जा रहा है)। कभी-कभी - डेटाबेस में एक रिकॉर्ड बनाते हैं।

सेवा वर्ग मॉक के साथ नियंत्रक परीक्षण का एक उदाहरण:

 public function testProductCategorySync() { $service = Mockery::mock(\App\Services\Product::class); app()->instance(\App\Services\Product::class, $service); $service->shouldReceive('sync')->once(); $response = $this->post('/api/v1/sync/eventsCallback', [ "eventType" => "PRODUCT_SYNC" ]); $response->assertStatus(200); }

एक मुखौटा परीक्षण के साथ नियंत्रक परीक्षण का एक उदाहरण (हमारे मामले में, एक घटना है, लेकिन सादृश्य द्वारा अन्य लारवेल facades के लिए किया जाता है):

 public function testChangeCart() { Event::fake(); $user = factory(User::class)->create(); Passport::actingAs( $user ); $response = $this->post('/api/v1/cart/update', [ 'products' => [ [ // our changed data ] ], ]); $data = json_decode($response->getContent()); $response->assertStatus(200); $this->assertEquals($user->id, $data->data->userId); // and assert other data from response Event::assertDispatched(CartChanged::class); }

सेवा और रिपोजिटरी

इस प्रकार की कक्षाएं बॉक्स से बाहर हैं। मैं नियंत्रकों को पतला रखने की कोशिश करता हूं, इसलिए मैंने इनमें से एक कक्षा समूह में सभी अतिरिक्त काम किए।

मैंने उनके बीच का अंतर इस प्रकार निर्धारित किया:

अगर मुझे कुछ व्यावसायिक तर्क को लागू करने की आवश्यकता है, तो मैंने इसे उपयुक्त सेवा परत (वर्ग) में डाल दिया।
अन्य सभी मामलों में, मैंने इसे रिपॉजिटरी वर्ग समूह में रखा। एक नियम के रूप में, एलोकेंट के साथ कार्यात्मक वहां जाता है। मैं समझता हूं कि यह भंडार स्तर की सही परिभाषा नहीं है। मैंने यह भी सुना कि कुछ मॉडल में एलोकेंट से संबंधित सब कुछ सहन करते हैं। मेरा दृष्टिकोण एक प्रकार का समझौता है, मेरी राय में, हालांकि "अकादमिक" पूरी तरह से सच नहीं है।

रिपोजिटरी कक्षाओं के लिए, मैं लगभग परीक्षण नहीं लिखता हूं।

सेवा वर्ग परीक्षण उदाहरण नीचे:

 public function testUpdateCart() { Event::fake(); $cartService = resolve(CartService::class); $cartRepo = resolve(CartRepository::class); $user = factory(User::class)->make(); $cart = $cartRepo->getCart($user); // set data $data = [ ]; $newCart = $cartService->updateForUser($user, $data); $this->assertEquals($data, $newCart->toArray()); Event::assertDispatched(CartChanged::class, 1); }

घटना-श्रोता, नौकरियां

इन कक्षाओं का परीक्षण लगभग सामान्य सिद्धांत द्वारा किया जाता है - हम परीक्षण के लिए आवश्यक डेटा तैयार करते हैं; हम फ्रेमवर्क से वांछित वर्ग को कॉल करते हैं और परिणाम की जांच करते हैं।
श्रोता के लिए उदाहरण:

 public function testHandle() { $user = factory(User::class)->create(); $cart = Cart::create([ 'userId' => $user->id, // other needed data ]); $listener = new CreateTaskForSyncCart(); $listener->handle(new CartChanged($cart)); $job = // get our job $this->assertSame(json_encode($cart->products), $job->payload); $this->assertSame($user->id, $job->user_id); // some additional asserts. Work with this data simplest for example $this->assertTrue($updatedAt->equalTo($job->last_updated_at)); }

सांत्वना सांत्वना

मैं कंसोल कमांड्स को कुछ प्रकार के नियंत्रक के रूप में मानता हूं जो अतिरिक्त रूप से आउटपुट कर सकते हैं (और दस्तावेज़ीकरण डेटा में वर्णित कंसोल इनपुट-आउटपुट के साथ अधिक जटिल जोड़तोड़ करते हैं। तदनुसार, परीक्षण नियंत्रक के समान हैं: हम जांचते हैं कि आवश्यक सेवा विधियों को कहा जाता है, घटनाओं को ट्रिगर किया जाता है (या नहीं), और हम कंसोल (आउटपुट या डेटा अनुरोध) के साथ बातचीत की भी जांच करते हैं।

एक समान परीक्षण का एक उदाहरण:

 public function testSendCartSyncDataEmptyJobs() { $service = m::mock(CartJobsRepository::class); app()->instance(CartJobsRepository::class, $service); $service->shouldReceive('getAll') ->once()->andReturn(collect([])); $this->artisan('sync:cart') ->expectsOutput('Get all jobs for sending...') ->expectsOutput('All count for sending: 0') ->expectsOutput('Empty jobs') ->assertExitCode(0); }

बाहरी पुस्तकालयों को अलग करें

एक नियम के रूप में, यदि अलग-अलग पुस्तकालयों में इकाई परीक्षणों की विशेषताएं हैं, तो उन्हें प्रलेखन में वर्णित किया गया है। अन्य मामलों में, इस कोड के साथ सेवा परत के समान कार्य किया जाता है। इसका कोई मतलब नहीं है कि पुस्तकालयों को स्वयं परीक्षण के साथ कवर करना चाहिए (केवल अगर आप इस पुस्तकालय को पीआर भेजना चाहते हैं) और आपको उन्हें किसी तरह का ब्लैक बॉक्स मानना चाहिए।

कई परियोजनाओं पर, मुझे एपीआई के माध्यम से अन्य सेवाओं के साथ बातचीत करनी होगी। लारवेल अक्सर इन उद्देश्यों के लिए गज़ल लाइब्रेरी का उपयोग करता है। नेटवर्कसेवा सेवा के एक अलग वर्ग में अन्य सेवाओं के साथ सभी काम करना मुझे सुविधाजनक लगा। इससे मुझे मुख्य कोड लिखना और परीक्षण करना आसान हो गया, और उत्तर और त्रुटि हैंडलिंग को मानकीकृत करने में मदद मिली।

मैं अपने नेटवर्क सेवा वर्ग के लिए कई परीक्षणों का उदाहरण देता हूं:

 public function testSuccessfulSendNetworkService() { $mockHandler = new MockHandler([ new Response(200), ]); $handler = HandlerStack::create($mockHandler); $client = new Client(['handler' => $handler]); app()->instance(\GuzzleHttp\Client::class, $client); $networkService = resolve(NetworkService::class); $response = $networkService->sendRequestToSite('GET', '/'); $this->assertEquals('200', $response->getStatusCode()); } public function testUnsupportedMethodSendNetworkService() { $networkService = resolve(NetworkService::class); $this->expectException('\InvalidArgumentException'); $networkService->sendRequestToSite('PUT', '/'); } public function testUnsetConfigUrlNetworkService() { $networkService = resolve(NetworkService::class); Config::shouldReceive('get') ->once() ->with('app.api_url') ->andReturn(''); Config::shouldReceive('get') ->once() ->with('app.api_token') ->andReturn('token'); $this->expectException('\InvalidArgumentException'); $networkService->sendRequestToApi('GET', '/'); }

निष्कर्ष

यह दृष्टिकोण मुझे बेहतर और अधिक समझने योग्य कोड लिखने की अनुमति देता है, कोड लिखते समय SOLID और SRP दृष्टिकोणों का लाभ उठाने के लिए। मेरे परीक्षण तेज़ हो गए, और सबसे महत्वपूर्ण बात - वे मुझे लाभान्वित करने लगे।

सक्रियता के साथ जब कार्यक्षमता का विस्तार या परिवर्तन होता है, तो हम तुरंत देखते हैं कि वास्तव में क्या गिर रहा है और हम स्थानीय वातावरण से मुक्त किए बिना त्रुटियों को जल्दी और सही ढंग से ठीक कर सकते हैं। यह त्रुटि सुधार को यथासंभव सस्ता बनाता है।

मुझे उम्मीद है कि मेरे द्वारा वर्णित सिद्धांत और दृष्टिकोण आपको लारवेल में इकाई परीक्षण से निपटने में मदद करेंगे और इकाई विकास में अपने सहायकों के लिए इकाई परीक्षण करेंगे।

अपने अतिरिक्त और टिप्पणी लिखें।

लारवेल में यूनिट परीक्षण