👨🏿‍🤝‍👨🏽 🤚🏼 💆🏿 नोड.जेएस और एक्सप्रेस पर वेब विकास। अध्याय 2

छह महीने से भी कम समय में मुझे अंततः पाठ्यपुस्तक का दूसरा अध्याय लिखने को मिला। मैंने फेरीवालों की इच्छाओं को ध्यान में रखते हुए पहले अध्याय को थोड़ा सा फिर से तैयार किया, ताकि आप इसे फिर से देख सकें - नोड और एक्सप्रेस पर वेब विकास। अभ्यास में नोड सीखना

अध्याय 2. डेमो आवेदन और पहले परीक्षण

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

2.1 मॉडल-व्यू-कंट्रोलर (MVC)

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

२.२ डेमो आवेदन

यह हमारे डेमो एप्लिकेशन को विकसित करना शुरू करने का समय है। पहले अध्याय में, हमने पहले से ही एक परीक्षण एप्लिकेशन को तैनात किया है, लेकिन हमने एक्सप्रेस जनरेटर का उपयोग किया और कोड की एक भी पंक्ति नहीं लिखी। अब हम अपने आवेदन को स्वयं लिखेंगे और "हैलो, वर्ल्ड" से शुरू करेंगे।

$ cd ~/projects/node-tutorial $ mkdir node-demo-app $ cd node-demo-app

2.2.1 एनपीएम पैकेज

Npm क्या है? यह सरल है, यह एक नोड पैकेज मैनेजर है (हालांकि लेखक इस पर विवाद करते हैं)। सामान्य शब्दों में, npm पैकेज एक निर्देशिका है, जिसमें प्रोग्राम और package.json फाइल है, जो इस प्रोग्राम का वर्णन करता है, इस फाइल में आप यह निर्दिष्ट कर सकते हैं कि हमारा प्रोग्राम किस दूसरे पैकेज पर निर्भर करता है, package.json का विवरण पढ़ें।
Npm प्रदान कर सकने वाले सभी आकर्षण का लाभ उठाने के लिए, हम अपनी परियोजना की मूल निर्देशिका में एक फ़ाइल बनाएंगे:

 $ touch package.json

package.json:

 { "name": "node-demo-app" , "version": "0.0.1" , "scripts": { "start": "node server.js" } , "dependencies": { "express": "3.0.x" } }

अब निष्पादित कर सकते हैं

 $ npm install

नतीजतन, npm नोड_मॉड्यूल्स डायरेक्टरी बनाएगा जिसमें यह उन सभी मॉड्यूल्स को जगह देगा, जिन पर हमारा प्रोजेक्ट निर्भर करता है।

२.२.२ नमस्ते, विश्व!

मुख्य फ़ाइल को server.js कहा जाता है:

 $ touch server.js

server.js:

 var express = require('express') , app = express() , port = process.env.PORT || 3000 app.get('/', function (req, res) { res.send('Hello, World!') }) app.listen(port, function () { console.log('Listening on port ', port) })

हम तुरंत शब्दावली का निर्धारण करेंगे और इस कोड का विश्लेषण करेंगे। हमारा आवेदन app ऑब्जेक्ट होगा, app पर कॉल करें। app.get फ़ंक्शन एक्शन (कार्रवाई) को app.get , जिसकी भूमिका इस मामले में एक अनाम फ़ंक्शन द्वारा पथ (मार्ग) '/' के लिए की जाती है। वास्तव में, इसका मतलब है कि हर बार जब आप http GET / अनुरोध प्राप्त करते हैं, तो एप्लिकेशन निर्दिष्ट कार्रवाई को निष्पादित करेगा। इस उदाहरण में port वैरिएबल PORT वातावरण चर द्वारा इनिशियलाइज़ किया गया है यदि यह मौजूद है, और यदि ऐसा कोई वैरिएबल नहीं है, तो यह मान 3000 लेता है। app.listen निर्दिष्ट पोर्ट पर http सर्वर शुरू करता है और आने वाले अनुरोधों को सुनना शुरू करता है।

हमारे काम के परिणाम की प्रशंसा करने के लिए, दो तरीके हैं:

 $ node server.js

या

 $ npm start

दूसरी विधि उपलब्ध है क्योंकि हमने "स्क्रिप्ट" अनुभाग में पैकेज.जॉन कॉन्फ़िगरेशन फ़ाइल में संबंधित लाइन को जोड़ा है।

अब http: // localhost: 3000 / पर आप 'हैलो, वर्ल्ड!' लाइन प्राप्त कर सकते हैं।

GitHub पर कुछ अपलोड करने का समय है। हम नोड-डेमो-ऐप नाम के साथ GitHub पर एक नया भंडार बनाते हैं और परियोजना निर्देशिका में कमांड के निम्नलिखित सेट को निष्पादित करते हैं, पहले README.md फ़ाइल (अच्छा टोन नियम) बनाएं

 $ echo '# Node.js demo app' > README.md

चलो git में अतिरिक्त फ़ाइलों को न करने के लिए एक .gitignore फ़ाइल बनाएँ, जिसका नाम नोड_मॉड्यूल निर्देशिका है:

 $ echo 'node_modules' > .gitignore

हो सकता है कि किसी ने मिकाइल रोजर्स के लेख को पढ़ा हो और वह ._ignignore के लिए node_modules जोड़ने पर आपत्ति करना चाहे। उन लोगों के लिए जो पढ़ने में बहुत आलसी हैं, नोड पर परियोजनाओं में। इस दृष्टिकोण की सिफारिश की जाती है:

उन परियोजनाओं के लिए जिन्हें हम तैनात कर रहे हैं, जैसे कि वेब एप्लिकेशन, नोड_मॉड्यूल को रिपॉजिटरी में रखा गया है।
पुस्तकालयों और अन्य पुन: प्रयोज्य कोड के लिए, नोड_मॉड्यूल रिपॉजिटरी में नहीं जोड़े जाते हैं।
उत्पादन के लिए तैनाती के लिए npm का उपयोग नहीं किया जाता है।

लेकिन! हम एक होस्टिंग के रूप में हरोकू का उपयोग करते हैं और हम परिनियोजन विधि का चयन नहीं करते हैं, और वहाँ n.js प्रोजेक्ट npm का उपयोग करके तैनात किए जाते हैं, इसलिए हमने रिपॉजिटरी को लिट नहीं किया।

हम एक रिपॉजिटरी बनाते हैं, कमिट करते हैं और GitHub में सब कुछ अपलोड करते हैं:

 $ git init $ git add . $ git commit -m 'Hello, World' $ git remote add origin git@github.com:<username>/node-demo-app.git $ git push -u origin master

2.2.3 अनुप्रयोग संरचना

एक्सप्रेस अभी तक एप्लिकेशन फ़ाइलों के लिए एक सख्त संरचना तय नहीं करता है, इसलिए हम अपने स्वयं के साथ आएंगे। मैं इस विकल्प का सुझाव देता हूं:

 /node-demo-app |- /app | |- /controllers -  | |- /models -  | |- /views - html  | |- config.js -     | |- main.js -    |- /public -  - ,  ,   .. |- /tests -   |- app.js -   |- server.js - http

कोई भी हमें केवल फ़ाइलों के ऐसे लेआउट का पालन करने के लिए मजबूर नहीं करता है, लेकिन यह मेरे लिए सुविधाजनक लगता है, इसलिए बस इस तस्वीर को याद रखें और जैसा कि हम ट्यूटोरियल के माध्यम से आगे बढ़ते हैं, हम आवश्यक फ़ाइलों और निर्देशिकाओं का निर्माण करेंगे।

2.3 आवेदन का परीक्षण

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

2.3.1 स्वचालित परीक्षण

परीक्षण लिखने के लिए चौखटे के रूप में, हम मोचा लाइब्रेरीज़ (मोचा, कॉफ़ी-मोका :), जैसे , .जेएस , और सुपरटेस्ट का उपयोग करेंगे)। मोचा का उपयोग परीक्षण केस विवरण को व्यवस्थित करने के लिए किया जाता है, should.js विभिन्न चेक प्रदर्शन करने के लिए वाक्यविन्यास प्रदान करता है, और सुपरटेस्ट एक सरल http क्लाइंट के लिए एक ऐड-ऑन है जो आपको http अनुरोधों के परिणामों की जांच करने की अनुमति देता है। पुस्तकालयों को जोड़ने के लिए, पैकेज.जॉन में आवश्यक परिवर्तन करें

 { "name": "node-demo-app" , "version": "0.0.1" , "scripts": { "start": "node server.js" } , "dependencies": { "express": "3.0.x" } , "devDependencies": { "mocha": "1.7.0" , "should": "1.2.1" , "supertest": "0.4.0" } }

हमने निर्भरता को "devD dependencies" खंड में रखा, क्योंकि इन पुस्तकालयों को उत्पादन सर्वर पर खींचने की कोई आवश्यकता नहीं है। हमारे द्वारा निष्पादित पुस्तकालयों को स्थापित करने के लिए

 $ npm install

यह समझने के लिए कि यह कैसे काम करता है, आइए अपना पहला परीक्षण बनाने की कोशिश करें और इसे अपने ढांचे के माध्यम से चलाएं

 $ mkdir tests $ touch tests/test.js

Test.js में हमने ऐसी परीक्षा दी

 describe('Truth', function () { it('should be true', function () { true.should.be.true }) it('should not be false', function () { true.should.not.be.false }) })

और इसे चलाएं

 $ ./node_modules/.bin/mocha --require should --reporter spec tests/test.js

स्वाभाविक रूप से, इस तरह की परीक्षा पास होगी, इसलिए इसे कुछ टूटी हुई जगह दें

 describe('foo variable', function () { it('should equal bar', function () { foo.should.equal('bar') }) })

शुभारंभ

 $ ./node_modules/.bin/mocha --require should --reporter spec tests

और देखें कि परीक्षण पास नहीं हुए, आपको कोड को सुधारना होगा, एक चर घोषणा जोड़ना होगा

 var foo = 'bar' describe('foo variable', function () { it('should equal bar', function () { foo.should.equal('bar') }) })

शुभारंभ

 $ ./node_modules/.bin/mocha --require should --reporter spec tests/test.js

और हम देखते हैं कि कोड काम कर रहा है।

TDD का मूल सिद्धांत कोड लिखे जाने से पहले परीक्षण लिखना है, इसलिए हम यह सुनिश्चित कर सकते हैं कि परीक्षण वास्तव में कुछ परीक्षण कर रहे हैं, और केवल निष्पादन पर कोड नहीं चला रहे हैं और true.should.be की शैली में चेक कर रहे हैं। सच। अर्थात्, विकास प्रक्रिया इस प्रकार है:

टेस्ट लिखना
हम परीक्षण चलाते हैं और सुनिश्चित करते हैं कि यह गिरता है
एक कोड लिखना
हम परीक्षण चलाते हैं और सुनिश्चित करते हैं कि यह गुजरता है, यदि नहीं, तो चरण 3 पर लौटें

और ऐसा कई बार।

परीक्षणों के प्रक्षेपण को सरल बनाने के लिए, मेकफाइल में एक टास्क रन टेस्ट जोड़ें

 $ touch Makefile

मेकफाइल सामग्री:

 REPORTER=spec TESTS=$(shell find ./tests -type f -name "*.js") test: @NODE_ENV=test ./node_modules/.bin/mocha \ --require should \ --reporter $(REPORTER) \ $(TESTS) .PHONY: test

परंपरागत रूप से, मेक का उपयोग परियोजना के निर्माण के लिए किया गया था, लेकिन नियमित कार्यों को स्वचालित करने के लिए इसका उपयोग करना सुविधाजनक है। Makefile का उपयोग करने के बारे में यहाँ पढ़ें। मैं इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि कार्य के नाम के बाद संकेत टैब बनाए जाने चाहिए, न कि रिक्त स्थान।

अब टेस्ट-सूट को कमांड से चलाया जा सकता है:

 $ make test

आइए http अनुरोधों का परीक्षण करने का प्रयास करें। परीक्षण को और अधिक सुविधाजनक बनाने के लिए, हम एक छोटे से कोड को फिर से तैयार करेंगे और सर्वर से एक्सप्रेस एप्लिकेशन को एक अलग ऐप / main.js मॉड्यूल में स्थानांतरित करेंगे, और एक ऐप भी बनाएंगे। जेएस फाइल जो इस मॉड्यूल को निर्यात करेगी। अब यह अव्यावहारिक लग सकता है, लेकिन कोड व्यवस्थित करने का यह तरीका तब काम आएगा जब हम परीक्षणों के साथ कोड की कवरेज की जाँच करेंगे।

 $ mkdir app $ touch app/main.js

एप्लिकेशन / main.js:

 var express = require('express') , app = express() app.get('/', function (req, res) { res.send('Hello, World!') }) module.exports = app

 $ touch app.js

app.js:

 module.exports = require(__dirname + '/app/main')

server.js के साथ बदलें

 var app = require(__dirname + '/app') , port = process.env.PORT || 3000 app.listen(port, function () { console.log('Listening on port ', port) })

यह समझने के लिए कि नोड.जेएस मॉड्यूल कैसे काम करते हैं, साथ ही साथ क्या require और module.exports हम प्रलेखन पढ़ते हैं

Http अनुरोध की शुद्धता को सत्यापित करने के लिए, test.js में निम्न कोड लिखें

 var request = require('supertest') , app = require(__dirname + '/../app') describe('GET /', function () { it('should contain text "Hello, Express!"', function (done) { request(app) .get('/') .expect(/Hello, Express!/, done) }) })

इस परीक्षण में, हम जाँचते हैं कि सर्वर "हैलो, एक्सप्रेस!" लाइन के साथ प्रतिक्रिया करता है। चूंकि सर्वर "हैलो, वर्ल्ड!" का जवाब देता है, इसके बजाय, परीक्षण विफल हो जाएगा। इस पर ध्यान देने के लिए एक महत्वपूर्ण बिंदु यह है कि http सर्वर पर अनुरोध अतुल्यकालिक रूप से होते हैं, इसलिए हमें परीक्षण पूरा करने के लिए कॉलबैक असाइन करना होगा। मोचा ने किए गए फ़ंक्शन का उपयोग करके ऐसा अवसर प्रदान करता है, जिसे वैकल्पिक रूप से परीक्षण मामले के साथ फ़ंक्शन में पारित किया जा सकता है। पारित करने के लिए परीक्षण के लिए, आपको "हैलो, एक्सप्रेस!" लाइन के साथ "हैलो, एक्सप्रेस!" ऐप / main.js फ़ाइल में और make test चलाने की आवश्यकता है।

2.3.2 कोड का परीक्षण के साथ कवरेज

सिद्धांत रूप में, इस पैराग्राफ को छोड़ दिया जा सकता है, क्योंकि यह टेस्ट एप्लिकेशन लिखने की प्रक्रिया को प्रभावित नहीं करता है, लेकिन टेस्ट के साथ कोड कवरेज पर रिपोर्ट हमारे टेस्ट-सूट के लिए एक अच्छा अतिरिक्त होगा।

यह पता लगाने के लिए कि परीक्षण द्वारा हमारा कोड पूरी तरह से कैसे कवर किया गया है , हमें एक और उपकरण की आवश्यकता है, इसे jscoverage कहा जाता है। इसे संकलित करना होगा। इसलिए यदि आपने कंपाइलर अभी तक स्थापित नहीं किया है, तो आपको इसे स्थापित करना चाहिए:

 $ sudo apt-get install g++

फिर jscoverage स्थापित करें:

 $ cd /tmp $ git clone git://github.com/visionmedia/node-jscoverage.git $ cd node-jscoverage $ ./configure && make $ sudo make install

आइए परियोजना निर्देशिका पर वापस जाएं:

 $ cd ~/projects/node-tutorial/node-demo-app/

हमें Makefile और app.js में कुछ बदलाव करने होंगे ताकि कवरेज रिपोर्ट तैयार की जा सके।

makefile:

 REPORTER=spec TESTS=$(shell find ./tests -type f -name "*.js") test: @NODE_ENV=test ./node_modules/.bin/mocha \ --require should \ --reporter $(REPORTER) \ $(TESTS) test-cov: app-cov @APP_COV=1 $(MAKE) --quiet test REPORTER=html-cov > coverage.html app-cov: @jscoverage app app-cov .PHONY: test

app.js:

 module.exports = process.env.APP_COV ? require(__dirname + '/app-cov/main') : require(__dirname + '/app/main')

हमने टेस्ट-कोव कार्य को मेकफाइल में जोड़ दिया, इसलिए अब कवरेज make test-cov रिपोर्ट make test-cov चलाने के make test-cov पर्याप्त है। App.js में परिवर्तन इस तथ्य से संबंधित हैं कि एक रिपोर्ट में एप्लिकेशन की इंस्ट्रूमेंटेड कॉपी होती है जो jscoverage उत्पन्न करती है। यही है, हम पर्यावरण चर APP_COV जांच करते हैं और अगर यह स्थापित है, तो एप्लिकेशन को / app-cov निर्देशिका से लोड करें, और यदि नहीं, तो हम सामान्य संस्करण को / app से लेते हैं।

हम रिपोर्ट तैयार करते हैं:

 $ make test-cov

एक कवरेज। Html फ़ाइल दिखाई देनी चाहिए जिसे ब्राउज़र में खोला जा सकता है।

इसे .gitignore ऐप-कोव और कवरेज में जोड़ना बाकी है ।.html:

 $ echo 'app-cov' >> .gitignore $ echo 'coverage.html' >> .gitignore

हमने परीक्षणों का पता लगा लिया है, इसलिए हम परीक्षण परीक्षण को हटा देते हैं

 $ rm tests/test.js

और कमिट करें

 $ git add . $ git ci -m "Added testing framework" $ git push

डेमो आवेदन के लिए स्रोत कोड यहां प्राप्त किया जा सकता है: github.com/DavidKlassen/node-demo-app

दृष्टिकोण पर तीसरा अध्याय है, इसमें हम साइट के पृष्ठों के लिए एक पूर्ण-नियंत्रक लिखेंगे और हम समझेंगे कि एक्सप्रेस वर्क में टेम्पलेट कैसे काम करते हैं।

नोड.जेएस और एक्सप्रेस पर वेब विकास। अध्याय 2 - अनुप्रयोग परीक्षण