กรอบการทดสอบใดที่สามารถใช้กับ Node ได้ บทความต่อไปนี้จะแชร์เฟรมเวิร์กการทดสอบ Node.js กับคุณ ฉันหวังว่ามันจะเป็นประโยชน์กับคุณ! 
หลักสูตรแนะนำ Node.js ฉบับย่อ: เข้าเรียนเพื่อเรียนรู้
หมายเหตุบรรณาธิการ: ผู้เขียนบทความนี้คือ Tianzhu วิศวกร Node.js ของ Ant Group อันดับแรกเขาจะแนะนำไลบรารีคลาสที่ใช้กันทั่วไปในแต่ละส่วน ในตอนท้ายของบทความ เขาจะหารือเกี่ยวกับว่าจำเป็นต้องมีการทดสอบหน่วยหรือไม่ เพื่อหารือร่วมกัน
มอคค่าและมุกตลกมักใช้กันทั่วไป การทดสอบโหนดใหม่อย่างเป็นทางการยังคงได้รับการขัดเกลา และอนาคตก็สดใส
$มอคค่า ทดสอบ/ไข่-view-ejs.test.js แสดงผล ✓ ควรส่งมอบร่วมกับคนในพื้นที่ ✓ ควรเรนเดอร์ด้วยแคช ✓ ควรเรนเดอร์ด้วยเลย์เอาต์ ✓ ควรแสดงข้อผิดพลาด renderString ✓ ควร renderString พร้อมข้อมูล ✓ ควรแสดงข้อผิดพลาด renderString 6 รอบ (398ms)
แม้ว่าจะมีนักวิ่งจำนวนมาก แต่มาตรฐานผลงานของพวกเขาทั้งหมดอยู่ในรูปแบบ TAP และผลลัพธ์จะถูกส่งผ่านผู้รายงานที่แตกต่างกัน
แค่การเขียนการทดสอบครั้งเดียวนั้นไม่เพียงพอ เราจำเป็นต้องรู้ว่าครอบคลุมกระบวนการสาขาทั้งหมดของโค้ดหรือไม่ ดังนั้นเราจึงจำเป็นต้องใช้เครื่องมือครอบคลุมโค้ด
เมื่อก่อนเคยเป็น istanbuljs แต่ต่อมาผู้เขียนได้เขียน NYC ขึ้นมาใหม่ โดยหลักๆ แล้วมีหน้าที่สองประการ ประการแรกคือการแปลโค้ดเพื่อแทรกโค้ดซ้อน และอีกประการหนึ่งคือการสนับสนุนผู้รายงานหลายคนเพื่อสร้างรายงานความครอบคลุม
ต่อมามีสถิติความครอบคลุมในตัว V8
นั่นคือไม่จำเป็นต้องแปลโค้ดอีกต่อไป และรองรับการรวบรวมข้อมูลที่ครอบคลุมโดยกำเนิด
จากนั้นผู้เขียนคนนี้ได้เขียน c8 ที่เน้นไปที่การสร้างรายงานความครอบคลุม
ในการตรวจสอบผลลัพธ์ของตัวแปร การยืนยันถือเป็นสิ่งสำคัญ
ในอดีต:expect.js, should.js, chai และ power-assert, jest ยังมีความคาดหวังในตัวของมันเอง
แต่ตอนนี้การยืนยัน/เข้มงวดอย่างเป็นทางการของ Node.js นั้นค่อนข้างดีจริงๆ
ในบรรดาสิ่งเหล่านั้น Power-assert คือสิ่งที่เราที่ EggJS ใช้ ฉันยังพูดถึงมันเมื่อหลายปีก่อน: "อาจเป็นห้องสมุด JS Assert ที่ดีที่สุด - The Emperor's New Clothes"
const assert = ต้องการ ('อำนาจยืนยัน');
อธิบาย('test/showcase.test.js', () => {
const arr = [1, 2, 3];
it('power-assert', () => {
ยืนยัน (arr[1] === 10);
-
-
//เอาท์พุท:
4) test/showcase.test.js ยืนยันกำลัง:
ข้อผิดพลาดในการยืนยัน: # test/showcase.test.js:6
ยืนยัน (arr [1] === 10)
-
|.2 เท็จ
[1,2,3]
[หมายเลข] 10
=> 10
[หมายเลข] arr[1]
=> 2PS: หากคุณต้องการตรวจสอบเนื้อหาไฟล์ ฉันได้เขียนไฟล์ assert ไว้ด้วย ยินดีที่จะลองใช้
เนื่องจากเป็นการทดสอบหน่วย จึงมักจำเป็นต้องจำลองสภาพแวดล้อมหรือการตอบสนองดาวน์สตรีม
sinonjs ก็ไม่ได้แย่และรองรับ mocks, stubs ฯลฯ jest ยังมีไลบรารีจำลองของตัวเองในตัวด้วย
หากเป็นการทดสอบ HTTP Nock จะมีประสิทธิภาพมากและสามารถช่วยคุณจำลองการตอบสนองของเซิร์ฟเวอร์ได้
nock('http://www.example.com')
.post('/login', 'username=pgte&password=123456')
.reply(200, { id: '123ABC' })อย่างไรก็ตาม ไลบรารีคำขอ undici อย่างเป็นทางการของ Node.js ก็มีความสามารถในการจำลองในตัวเช่นกัน
นอกจากนี้ยังมีคำที่เรียกว่า snapshot ซึ่งหมายถึงการทิ้งข้อมูลระหว่างการดำเนินการและใช้เป็นข้อมูลจำลองโดยตรงสำหรับการทดสอบครั้งต่อไปซึ่งสามารถปรับปรุงประสิทธิภาพของการเขียนการทดสอบได้ในระดับหนึ่ง
ในการทดสอบสถานการณ์เซิร์ฟเวอร์ HTTP ไลบรารี supertest จะขาดไม่ได้
อธิบาย ('GET / ผู้ใช้', ฟังก์ชั่น () {
it('ตอบสนองต่อ json', ฟังก์ชัน async() {
คำขอคืนสินค้า (แอป)
.get('/ผู้ใช้')
.set('ยอมรับ', 'application/json')
.expect('ประเภทเนื้อหา', /json/)
.คาดหวัง(200)
.then(ตอบกลับ => {
ยืนยัน(response.body.email, '[email protected]');
-
-
-สถานการณ์การใช้งานหลักประการหนึ่งของ Node.js คือ CLI บรรทัดคำสั่ง เช่น Webpack และ Babel ซึ่งจำเป็นต้องมีการทดสอบหน่วยด้วย
นี่คือสิ่งที่เราแนะนำ:
GitHub - โหนดโมดูล/clet: การทดสอบบรรทัดคำสั่ง E2E
GitHub - node-modules/coffee: ทดสอบบรรทัดคำสั่งบน Node.js
นำเข้า { รองชนะเลิศอันดับ KEYS } จาก 'clet';
it('should works with boilerplate', async () => { await runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // รอ stdout แล้วตอบกลับ .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // ตรวจสอบ stdout .notStderr(/ npm ERR/) .file('package.json', { name: 'example', version: '1.0.0' }) // ตรวจสอบไฟล์ });
สำหรับการรวบรวมข้อมูลเพจแบบเบา คุณสามารถใช้ HTTP เพื่อขอไลบรารีได้โดยตรง
เพื่อจำลองการทำงานจริงของเบราว์เซอร์ จึงมีการใช้ซีลีเนียมและ phantomjs ในช่วงแรกๆ
จากนั้น Google ก็เปิดตัวหุ่นกระบอกอย่างเป็นทางการ เนื่องจากการสะสมของ Chromium และตามโปรโตคอล devtools-protocol จึงได้รับความนิยมอย่างรวดเร็วและสังหารสองคนแรก ผลิตภัณฑ์คู่แข่งที่คล้ายกัน ได้แก่ นักเขียนบทละครและไซเปรส
อย่างไรก็ตาม ฉันจะดาวน์โหลด macacajs ซึ่งเป็นเครื่องมือทดสอบหลายเทอร์มินัล นอกจากเบราว์เซอร์แล้ว ยังรองรับการทดสอบแอปมือถือและแอปเดสก์ท็อปอีกด้วย โดยวิศวกรจากทีม Yuque
เมื่อเราเขียนโอเพ่นซอร์ส เรามักจะต้องการบริการบูรณาการอย่างต่อเนื่องแบบอัตโนมัติเพื่อช่วยเราทดสอบ
ผู้เล่นในสาขานี้ ได้แก่ Travis, Appveyor, GitHub Actions เป็นต้น
ตอนนี้ฉันใช้ GitHub Actions โดยพื้นฐานแล้ว และระดับของการบูรณาการก็ยอดเยี่ยมมาก
ไม่ต้องสงสัยเลยว่าการทดสอบหน่วยมีความสำคัญมาก มันเป็นความสามารถที่จำเป็นและคุณภาพระดับมืออาชีพของโปรแกรมเมอร์ที่มีคุณสมบัติเหมาะสม
แน่นอนว่าเราไม่ใช่ผู้คลั่งไคล้ความคุ้มครอง 100% ในหลายกรณี เราจำเป็นต้องติดตามจุดสมดุลของ ROI
ก่อนอื่น ให้ฉันแก้ไขมุมมองของผู้มาใหม่ทั่วไป: การทดสอบหน่วยการเขียนเป็นการเสียเวลาหรือไม่?
ในความเป็นจริง การเขียนการทดสอบหน่วยจะช่วยคุณประหยัดเวลา เราจำเป็นต้องพิจารณาต้นทุนของการถดถอยหลังจากแก้ไขโค้ดสองครั้งภายใต้ข้อกำหนดด้านคุณภาพเดียวกัน
เพื่อการเปรียบเทียบที่ยุติธรรม นอกเหนือจากการพิจารณา "เวลาในการเขียนการทดสอบเดี่ยว" แล้ว สิ่งที่มองข้ามได้ง่ายคือ "เวลาในการทดสอบการถดถอยหลังจากการแก้ไขโค้ดแต่ละครั้ง":
เมื่อเขียนการทดสอบเดี่ยว ให้สร้างการจำลองสาขาต่างๆ ในระยะเริ่มต้น และเวลาสำหรับการทดสอบการถดถอยก็แค่พิมพ์บนคีย์บอร์ด
โดยไม่ต้องเขียนการทดสอบแม้แต่รายการเดียว คุณจะต้องอัปเดตโค้ดลงในแอปพลิเคชัน จากนั้นจึงจำลองสถานการณ์ต่างๆ ที่จะทดสอบด้วยตนเอง เช่น การเปิดเบราว์เซอร์และการคลิกที่ตำแหน่งต่างๆ มากมาย
ทั้งสองใช้เวลานานแค่ไหนก็ชัดเจน
ไม่มีอะไรมากไปกว่าการลงทุนเริ่มแรก + ค่าบำรุงรักษา + การเน้นคุณภาพผลตอบแทน แต่ละบริษัทจะมีขนาดของตัวเองเมื่อทำการตัดสินใจหลังจากการชั่งน้ำหนัก
แน่นอนว่า สถานการณ์ต่างๆ มากมายที่ฉันกล่าวถึงคือไลบรารีเฟรมเวิร์ก (รวมถึงส่วนหน้าและ Node.js) แอปพลิเคชันฝั่งเซิร์ฟเวอร์ เครื่องมือบรรทัดคำสั่ง ฯลฯ เป็นเรื่องจริงที่แอปพลิเคชันส่วนหน้าบางตัวมีการเปลี่ยนแปลงอย่างมากใน การแสดง UI หรือการโหลดและการขนถ่ายอย่างรวดเร็วสำหรับหน้ากิจกรรม ค่าใช้จ่ายในการบำรุงรักษาการทดสอบเดี่ยวที่สอดคล้องกันนั้นสูงมาก ในขณะนี้ มีเหตุผลที่จะละทิ้งการทดสอบเดี่ยวของสาขาที่ไม่ใช่ธุรกิจหลักบางแห่งอย่างเหมาะสมโดยพิจารณาจาก ROI
แต่เราต้องเข้าใจว่านี่เป็นทางเลือกสุดท้าย เราสามารถลดต้นทุนการบำรุงรักษาของการทดสอบหน่วยได้ด้วยวิธีต่างๆ แต่เราไม่สามารถอ้างได้ว่าการทดสอบหน่วยนั้นไร้ประโยชน์
นอกจากนี้ยังมีการทดสอบการถดถอยแบบกึ่งอัตโนมัติในฟิลด์ส่วนหน้า ซึ่งอิงตามการเปรียบเทียบแบบต่างกับแบบอัตโนมัติ จากนั้นเตือนเจ้าของให้ใส่ใจกับผลกระทบของการเปลี่ยนแปลง นี่เป็นเหมือนกับไลบรารีเครื่องมือด้านบน ซึ่งทั้งหมดอยู่ที่นี่เพื่อช่วยลดต้นทุนในการเขียนการทดสอบเดี่ยวๆ
นี่เป็นมุมมองที่ผิดเช่น กัน โปรแกรมเมอร์ควรเขียน Unit Tests เอง เนื่องจากเป็นโค้ดของคุณเองและคุณต้องรับผิดชอบต่อมัน นี่คือความเป็นมืออาชีพ ทีมใดก็ตามที่มีมาตรฐานเพียงเล็กน้อยจำเป็นต้องมีการทดสอบ CI เมื่อส่งโค้ด ไม่เช่นนั้นจะไม่มีการทำงานร่วมกันในการตรวจสอบโค้ดที่มีคุณภาพ
นักเรียนทดสอบมีหน้าที่รับผิดชอบงานในระดับที่ใหญ่กว่า เช่น การทดสอบบูรณาการ การทดสอบการถดถอย และการทดสอบแบบ end-to-end
การแบ่งงานก็ต่างกัน ฉะนั้นอย่าโทษคนอื่นเลย
การทดสอบหน่วยเป็นสิ่งที่จำเป็นมาก การเขียน Unit Tests เป็นคุณสมบัติระดับมืออาชีพขั้นพื้นฐานของโปรแกรมเมอร์ ในแต่ละสถานการณ์ คุณสามารถเลือกได้ตาม ROI