การทดสอบ JavaScript อัตโนมัติ: คู่มือฉบับสมบูรณ์สำหรับการตั้งค่า Continuous Integration

ลองจินตนาการถึงสถานการณ์นี้: เป็นช่วงเวลาเลิกงาน คุณเพิ่ง push โค้ดที่คุณเชื่อว่าเป็นการแก้บั๊กเล็กน้อยไปยัง main branch ไม่กี่อึดใจต่อมา การแจ้งเตือนก็เริ่มดังขึ้น ช่องทางสนับสนุนลูกค้าเต็มไปด้วยรายงานว่าฟีเจอร์สำคัญที่ไม่เกี่ยวข้องกลับพังโดยสิ้นเชิง เหตุการณ์นี้ก่อให้เกิดการเร่งรีบแก้ไข (hotfix) ที่เต็มไปด้วยความเครียดและแรงกดดัน สถานการณ์เช่นนี้ซึ่งเกิดขึ้นบ่อยครั้งกับทีมพัฒนาทั่วโลก คือสิ่งที่กลยุทธ์การทดสอบอัตโนมัติและ Continuous Integration (CI) ที่แข็งแกร่งถูกออกแบบมาเพื่อป้องกัน

ในภูมิทัศน์ของการพัฒนาซอฟต์แวร์ระดับโลกที่เปลี่ยนแปลงอย่างรวดเร็วในปัจจุบัน ความเร็วและคุณภาพไม่ใช่สิ่งที่แยกจากกัน แต่เป็นสิ่งที่ต้องพึ่งพาซึ่งกันและกัน ความสามารถในการส่งมอบฟีเจอร์ที่เชื่อถือได้อย่างรวดเร็วถือเป็นความได้เปรียบทางการแข่งขันที่สำคัญ นี่คือจุดที่การทำงานร่วมกันของการทดสอบ JavaScript อัตโนมัติและ Continuous Integration pipeline กลายเป็นรากฐานที่สำคัญของทีมวิศวกรรมสมัยใหม่ที่มีประสิทธิภาพสูง คู่มือนี้จะทำหน้าที่เป็นแผนที่นำทางที่ครอบคลุมของคุณเพื่อทำความเข้าใจ นำไปใช้ และปรับปรุงการตั้งค่า CI สำหรับโปรเจกต์ JavaScript ใดๆ เพื่อตอบสนองกลุ่มเป้าหมายทั่วโลกทั้งนักพัฒนา หัวหน้าทีม และวิศวกร DevOps

'ทำไม': ทำความเข้าใจหลักการสำคัญของ CI

ก่อนที่เราจะเจาะลึกไปที่ไฟล์การกำหนดค่าและเครื่องมือเฉพาะ สิ่งสำคัญคือต้องเข้าใจปรัชญาเบื้องหลัง Continuous Integration เพราะ CI ไม่ได้เป็นเพียงการรันสคริปต์บนเซิร์ฟเวอร์ระยะไกลเท่านั้น แต่ยังเป็นแนวปฏิบัติในการพัฒนาและการเปลี่ยนแปลงวัฒนธรรมองค์กรที่ส่งผลกระทบอย่างลึกซึ้งต่อวิธีการทำงานร่วมกันและส่งมอบซอฟต์แวร์ของทีม

Continuous Integration (CI) คืออะไร?

Continuous Integration คือแนวปฏิบัติในการรวมโค้ดที่นักพัฒนาแต่ละคนกำลังทำอยู่เข้ากับ mainline ส่วนกลางบ่อยๆ ซึ่งมักจะทำวันละหลายครั้ง การรวม (merge) หรือ 'integration' แต่ละครั้งจะถูกตรวจสอบโดยอัตโนมัติผ่านกระบวนการ build และการทดสอบอัตโนมัติหลายชุด เป้าหมายหลักคือการตรวจจับบั๊กที่เกิดจากการรวมโค้ดให้เร็วที่สุดเท่าที่จะเป็นไปได้

ลองนึกภาพว่ามันเป็นเหมือนสมาชิกในทีมอัตโนมัติที่คอยเฝ้าระวังและตรวจสอบอยู่ตลอดเวลาว่าโค้ดใหม่ที่เพิ่มเข้ามาจะไม่ทำให้แอปพลิเคชันที่มีอยู่พัง การได้รับผลตอบรับที่รวดเร็วทันทีนี้คือหัวใจและคุณสมบัติที่ทรงพลังที่สุดของ CI

ประโยชน์หลักของการใช้ CI

• ตรวจพบบั๊กได้เร็วและได้รับผลตอบรับที่รวดเร็วยิ่งขึ้น: ด้วยการทดสอบทุกการเปลี่ยนแปลง คุณจะเจอบั๊กได้ในเวลาไม่กี่นาที ไม่ใช่เป็นวันหรือสัปดาห์ ซึ่งช่วยลดเวลาและค่าใช้จ่ายในการแก้ไขได้อย่างมาก นักพัฒนาจะได้รับผลตอบรับเกี่ยวกับการเปลี่ยนแปลงของตนเองทันที ทำให้สามารถทำงานซ้ำและปรับปรุงได้อย่างรวดเร็วและมั่นใจ
• ปรับปรุงคุณภาพของโค้ด: CI pipeline ทำหน้าที่เป็นประตูควบคุมคุณภาพ (quality gate) สามารถบังคับใช้มาตรฐานการเขียนโค้ดด้วย linter ตรวจสอบข้อผิดพลาดของ type และทำให้แน่ใจว่าโค้ดใหม่มีความครอบคลุมของการทดสอบ (test coverage) เมื่อเวลาผ่านไป สิ่งนี้จะช่วยยกระดับคุณภาพและความสามารถในการบำรุงรักษาของ codebase ทั้งหมดอย่างเป็นระบบ
• ลดปัญหา Merge Conflicts: การรวมโค้ดทีละเล็กทีละน้อยบ่อยๆ จะทำให้นักพัฒนามีโอกาสเจอปัญหา merge conflicts ที่ใหญ่และซับซ้อน ('merge hell') น้อยลง ซึ่งช่วยประหยัดเวลาได้อย่างมากและลดความเสี่ยงในการเกิดข้อผิดพลาดระหว่างการ merge ด้วยตนเอง
• เพิ่มประสิทธิภาพการทำงานและความมั่นใจของนักพัฒนา: ระบบอัตโนมัติช่วยให้นักพัฒนาไม่ต้องเสียเวลากับกระบวนการทดสอบและ deploy ด้วยตนเองที่น่าเบื่อ การรู้ว่ามีชุดการทดสอบที่ครอบคลุมคอยปกป้อง codebase อยู่ทำให้นักพัฒนามีความมั่นใจที่จะ refactor สร้างสรรค์สิ่งใหม่ๆ และส่งมอบฟีเจอร์ได้โดยไม่ต้องกลัวว่าจะเกิด regression
• เป็นแหล่งข้อมูลความจริงเพียงแหล่งเดียว (Single Source of Truth): เซิร์ฟเวอร์ CI จะกลายเป็นแหล่งข้อมูลที่ชี้ชัดว่า build 'ผ่าน' (สีเขียว) หรือ 'ไม่ผ่าน' (สีแดง) ทุกคนในทีม ไม่ว่าจะอยู่ที่ไหนหรือเขตเวลาใด จะสามารถมองเห็นสถานะของแอปพลิเคชันได้อย่างชัดเจนในทุกช่วงเวลา

'อะไรบ้าง': ภาพรวมของการทดสอบ JavaScript

CI pipeline ที่ประสบความสำเร็จจะดีได้เท่าที่การทดสอบที่มันรัน กลยุทธ์ทั่วไปและมีประสิทธิภาพในการจัดโครงสร้างการทดสอบของคุณคือ 'Testing Pyramid' ซึ่งแสดงให้เห็นถึงความสมดุลที่ดีของการทดสอบประเภทต่างๆ

ลองนึกภาพพีระมิด:

• ฐาน (พื้นที่ใหญ่ที่สุด): Unit Tests. การทดสอบเหล่านี้รวดเร็ว มีจำนวนมาก และตรวจสอบโค้ดส่วนที่เล็กที่สุดแยกจากกัน
• กลาง: Integration Tests. การทดสอบเหล่านี้ตรวจสอบว่าหลายๆ unit ทำงานร่วมกันได้ตามที่คาดไว้
• ยอด (พื้นที่เล็กที่สุด): End-to-End (E2E) Tests. การทดสอบเหล่านี้ช้ากว่าและซับซ้อนกว่า เป็นการจำลองการใช้งานจริงของผู้ใช้ตลอดทั้งแอปพลิเคชัน

Unit Tests: รากฐานสำคัญ

Unit test มุ่งเน้นไปที่ฟังก์ชัน เมธอด หรือคอมโพเนนต์เพียงอย่างเดียว โดยจะถูกแยกออกจากส่วนอื่นๆ ของแอปพลิเคชัน และมักใช้ 'mocks' หรือ 'stubs' เพื่อจำลอง dependencies เป้าหมายคือเพื่อตรวจสอบว่าตรรกะส่วนนั้นๆ ทำงานอย่างถูกต้องเมื่อได้รับ input ในรูปแบบต่างๆ

• วัตถุประสงค์: ตรวจสอบหน่วยตรรกะ (logic unit) แต่ละส่วน
• ความเร็ว: เร็วมาก (มิลลิวินาทีต่อการทดสอบ)
• เครื่องมือหลัก:
  • Jest: เฟรมเวิร์กการทดสอบที่ได้รับความนิยมแบบครบวงจร มี assertion library, ความสามารถในการทำ mocking และเครื่องมือวัด code coverage ในตัว ดูแลโดย Meta
  • Vitest: เฟรมเวิร์กการทดสอบที่ทันสมัยและเร็วมาก ออกแบบมาเพื่อทำงานร่วมกับ build tool อย่าง Vite ได้อย่างราบรื่น โดยมี API ที่เข้ากันได้กับ Jest
  • Mocha: เฟรมเวิร์กการทดสอบที่มีความยืดหยุ่นสูงและเป็นที่ยอมรับมานาน ซึ่งให้โครงสร้างพื้นฐานสำหรับการทดสอบ มักใช้คู่กับ assertion library อย่าง Chai

Integration Tests: เนื้อเยื่อที่เชื่อมต่อกัน

Integration test เป็นการยกระดับขึ้นมาจาก unit test โดยจะตรวจสอบว่าหลายๆ unit ทำงานร่วมกันได้อย่างไร ตัวอย่างเช่น ในแอปพลิเคชัน frontend, integration test อาจจะ render คอมโพเนนต์ที่มี child component หลายตัวอยู่ข้างใน และตรวจสอบว่าพวกมันทำงานโต้ตอบกันอย่างถูกต้องเมื่อผู้ใช้คลิกปุ่ม

• วัตถุประสงค์: ตรวจสอบการทำงานร่วมกันระหว่างโมดูลหรือคอมโพเนนต์
• ความเร็ว: ช้ากว่า unit test แต่เร็วกว่า E2E test
• เครื่องมือหลัก:
  • React Testing Library: ไม่ใช่ test runner แต่เป็นชุดเครื่องมือที่ส่งเสริมการทดสอบพฤติกรรมของแอปพลิเคชันมากกว่ารายละเอียดการ υλοποίηση สามารถทำงานร่วมกับ runner อย่าง Jest หรือ Vitest ได้
  • Supertest: ไลบรารีที่ได้รับความนิยมสำหรับการทดสอบเซิร์ฟเวอร์ HTTP ของ Node.js ทำให้เหมาะอย่างยิ่งสำหรับการทดสอบ API integration

End-to-End (E2E) Tests: มุมมองของผู้ใช้

E2E test ทำงานโดยอัตโนมัติบนเบราว์เซอร์จริงเพื่อจำลองขั้นตอนการทำงานของผู้ใช้ตั้งแต่ต้นจนจบ สำหรับเว็บไซต์ E-commerce, E2E test อาจประกอบด้วยการเข้าชมหน้าแรก ค้นหาสินค้า เพิ่มลงในตะกร้า และไปยังหน้าชำระเงิน การทดสอบเหล่านี้ให้ความมั่นใจในระดับสูงสุดว่าแอปพลิเคชันของคุณทำงานได้ทั้งหมด

• วัตถุประสงค์: ตรวจสอบขั้นตอนการใช้งานของผู้ใช้ทั้งหมดตั้งแต่ต้นจนจบ
• ความเร็ว: เป็นประเภทการทดสอบที่ช้าที่สุดและเปราะบางที่สุด
• เครื่องมือหลัก:
  • Cypress: เฟรมเวิร์กการทดสอบ E2E ที่ทันสมัยแบบครบวงจร เป็นที่รู้จักในด้านประสบการณ์ที่ดีของนักพัฒนา, test runner แบบโต้ตอบได้ และความน่าเชื่อถือ
  • Playwright: เฟรมเวิร์กที่ทรงพลังจาก Microsoft ที่ช่วยให้สามารถทำงานอัตโนมัติข้ามเบราว์เซอร์ (Chromium, Firefox, WebKit) ได้ด้วย API เดียว เป็นที่รู้จักในด้านความเร็วและฟีเจอร์ขั้นสูง
  • Selenium WebDriver: มาตรฐานที่ใช้กันมาอย่างยาวนานสำหรับการทำงานอัตโนมัติบนเบราว์เซอร์ รองรับภาษาและเบราว์เซอร์ที่หลากหลาย ให้ความยืดหยุ่นสูงสุด แต่อาจมีความซับซ้อนในการตั้งค่ามากกว่า

Static Analysis: ด่านป้องกันแรก

ก่อนที่การทดสอบใดๆ จะเริ่มทำงาน เครื่องมือวิเคราะห์โค้ดแบบสถิต (static analysis) สามารถตรวจจับข้อผิดพลาดทั่วไปและบังคับใช้สไตล์ของโค้ดได้ สิ่งเหล่านี้ควรเป็นขั้นตอนแรกใน CI pipeline ของคุณเสมอ

• ESLint: linter ที่สามารถกำหนดค่าได้สูงเพื่อค้นหาและแก้ไขปัญหาในโค้ด JavaScript ของคุณ ตั้งแต่บั๊กที่อาจเกิดขึ้นไปจนถึงการละเมิดสไตล์
• Prettier: code formatter ที่มีรูปแบบชัดเจนซึ่งช่วยให้มั่นใจได้ว่าสไตล์ของโค้ดจะสอดคล้องกันทั้งทีม ขจัดข้อโต้เถียงเรื่องการจัดรูปแบบ
• TypeScript: ด้วยการเพิ่ม static type ให้กับ JavaScript, TypeScript สามารถตรวจจับข้อผิดพลาดประเภทต่างๆ ได้ตั้งแต่ตอน compile-time นานก่อนที่โค้ดจะถูกรัน

'ทำอย่างไร': สร้าง CI Pipeline ของคุณ - คู่มือปฏิบัติการ

ตอนนี้ มาลงมือปฏิบัติกัน เราจะมุ่งเน้นไปที่การสร้าง CI pipeline โดยใช้ GitHub Actions ซึ่งเป็นหนึ่งในแพลตฟอร์ม CI/CD ที่ได้รับความนิยมและเข้าถึงได้ง่ายที่สุดทั่วโลก อย่างไรก็ตาม แนวคิดต่างๆ สามารถนำไปปรับใช้กับระบบอื่น ๆ เช่น GitLab CI/CD หรือ Jenkins ได้โดยตรง

สิ่งที่ต้องมี (Prerequisites)

1. โปรเจกต์ JavaScript (Node.js, React, Vue, ฯลฯ)
2. ติดตั้ง testing framework (เราจะใช้ Jest สำหรับ unit test และ Cypress สำหรับ E2E test)
3. โค้ดของคุณอยู่บน GitHub
4. มีสคริปต์ที่กำหนดไว้ในไฟล์ `package.json` ของคุณ

โดยทั่วไป `package.json` อาจมีสคริปต์ลักษณะนี้:

ตัวอย่างสคริปต์ใน `package.json`:

"scripts": {

"start": "react-scripts start",

"build": "react-scripts build",

"lint": "eslint .",

"test": "jest",

"test:ci": "jest --ci --coverage",

"cypress:open": "cypress open",

"cypress:run": "cypress run"

}

ขั้นตอนที่ 1: การตั้งค่า GitHub Actions Workflow แรกของคุณ

GitHub Actions ถูกกำหนดค่าในไฟล์ YAML ที่อยู่ในไดเรกทอรี `.github/workflows/` ของ repository ของคุณ มาสร้างไฟล์ชื่อ `ci.yml` กัน

ไฟล์: `.github/workflows/ci.yml`

workflow นี้จะรัน linter และ unit test ของเราทุกครั้งที่มีการ push ไปยัง `main` branch และทุก pull request ที่มีเป้าหมายมาที่ `main`

# นี่คือชื่อสำหรับ workflow ของคุณ

name: JavaScript CI

# ส่วนนี้กำหนดว่า workflow จะทำงานเมื่อใด

on:

push:

branches: [ "main" ]

pull_request:

branches: [ "main" ]

# ส่วนนี้กำหนด job ที่จะดำเนินการ

jobs:

# เรากำหนด job เดียวชื่อ 'test'

test:

# ประเภทของ virtual machine ที่จะใช้รัน job

runs-on: ubuntu-latest

# Steps แทนลำดับของงานที่จะถูกดำเนินการ

steps:

# ขั้นตอนที่ 1: Check out โค้ดของ repository ของคุณ

- name: Checkout code

uses: actions/checkout@v4

# ขั้นตอนที่ 2: ตั้งค่า Node.js เวอร์ชันที่ถูกต้อง

- name: Use Node.js 20.x

uses: actions/setup-node@v4

with:

node-version: '20.x'

cache: 'npm' # เปิดใช้งานการแคช dependencies ของ npm

# ขั้นตอนที่ 3: ติดตั้ง dependencies ของโปรเจกต์

- name: Install dependencies

run: npm ci

# ขั้นตอนที่ 4: รัน linter เพื่อตรวจสอบสไตล์ของโค้ด

- name: Run linter

run: npm run lint

# ขั้นตอนที่ 5: รัน unit test และ integration test

- name: Run unit tests

run: npm run test:ci

เมื่อคุณ commit และ push ไฟล์นี้ไปยัง GitHub, CI pipeline ของคุณก็พร้อมใช้งานแล้ว! ไปที่แท็บ 'Actions' ใน repository GitHub ของคุณเพื่อดูการทำงานของมัน

ขั้นตอนที่ 2: การผนวก End-to-End Tests กับ Cypress

E2E test มีความซับซ้อนมากกว่า มันต้องการเซิร์ฟเวอร์แอปพลิเคชันที่ทำงานอยู่และเบราว์เซอร์ เราสามารถขยาย workflow ของเราเพื่อจัดการกับสิ่งนี้ได้ มาสร้าง job แยกสำหรับ E2E test เพื่อให้สามารถทำงานขนานไปกับ unit test ของเรา ซึ่งจะช่วยเร่งกระบวนการโดยรวมให้เร็วขึ้น

เราจะใช้ `cypress-io/github-action` อย่างเป็นทางการ ซึ่งช่วยลดความซับซ้อนของขั้นตอนการตั้งค่าหลายอย่าง

ไฟล์ที่อัปเดต: `.github/workflows/ci.yml`

name: JavaScript CI

on:

push:

branches: [ "main" ]

pull_request:

branches: [ "main" ]

jobs:

# job สำหรับ unit test ยังคงเหมือนเดิม

unit-tests:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: '20.x'

cache: 'npm'

- run: npm ci

- run: npm run lint

- run: npm run test:ci

# เราเพิ่ม job ใหม่ที่ทำงานแบบขนานสำหรับ E2E test

e2e-tests:

runs-on: ubuntu-latest

# job นี้ควรจะทำงานก็ต่อเมื่อ job unit-tests สำเร็จ

needs: unit-tests

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: '20.x'

cache: 'npm'

- name: Install dependencies

run: npm ci

# ใช้ action ของ Cypress อย่างเป็นทางการ

- name: Cypress run

uses: cypress-io/github-action@v6

with:

# เราต้อง build แอปก่อนที่จะรัน E2E test

build: npm run build

# คำสั่งเพื่อเริ่มเซิร์ฟเวอร์ local

start: npm start

# เบราว์เซอร์ที่จะใช้สำหรับการทดสอบ

browser: chrome

# รอจนกว่าเซิร์ฟเวอร์จะพร้อมใช้งานที่ URL นี้

wait-on: 'http://localhost:3000'

การตั้งค่านี้สร้างขึ้นมาสอง job โดย job `e2e-tests` จะ `needs` job `unit-tests` ซึ่งหมายความว่ามันจะเริ่มทำงานหลังจากที่ job แรกเสร็จสมบูรณ์เรียบร้อยแล้วเท่านั้น สิ่งนี้สร้าง pipeline แบบลำดับขั้น เพื่อให้แน่ใจว่าคุณภาพโค้ดพื้นฐานผ่านก่อนที่จะรัน E2E test ที่ช้ากว่าและใช้ทรัพยากรมากกว่า

แพลตฟอร์ม CI/CD ทางเลือก: มุมมองระดับโลก

แม้ว่า GitHub Actions จะเป็นตัวเลือกที่ยอดเยี่ยม แต่หลายองค์กรทั่วโลกก็ใช้แพลตฟอร์มที่มีประสิทธิภาพอื่นๆ ซึ่งแนวคิดหลักๆ นั้นเหมือนกัน

GitLab CI/CD

GitLab มีโซลูชัน CI/CD ที่ทรงพลังและถูกผนวกรวมไว้อย่างลึกซึ้ง การกำหนดค่าทำผ่านไฟล์ `.gitlab-ci.yml` ที่อยู่ใน root ของ repository ของคุณ

ตัวอย่าง `.gitlab-ci.yml` แบบง่าย:

image: node:20

cache:

paths:

- node_modules/

stages:

- setup

- test

install_dependencies:

stage: setup

script:

- npm ci

run_unit_tests:

stage: test

script:

- npm run test:ci

run_linter:

stage: test

script:

- npm run lint

Jenkins

Jenkins เป็นเซิร์ฟเวอร์อัตโนมัติแบบ self-hosted ที่ขยายความสามารถได้อย่างสูง เป็นตัวเลือกที่นิยมในสภาพแวดล้อมระดับองค์กรที่ต้องการการควบคุมและการปรับแต่งสูงสุด โดยทั่วไป pipeline ของ Jenkins จะถูกกำหนดไว้ในไฟล์ `Jenkinsfile`

ตัวอย่าง `Jenkinsfile` แบบ declarative อย่างง่าย:

pipeline {

agent any

stages {

stage('Build') {

steps {

sh 'npm ci'

}

}

stage('Test') {

steps {

sh 'npm run lint'

sh 'npm run test:ci'

}

}

}

}

กลยุทธ์ CI ขั้นสูงและแนวทางปฏิบัติที่ดีที่สุด

เมื่อคุณมี pipeline พื้นฐานที่ทำงานได้แล้ว คุณสามารถปรับปรุงให้มีประสิทธิภาพและความเร็วเพิ่มขึ้น ซึ่งมีความสำคัญอย่างยิ่งสำหรับทีมขนาดใหญ่ที่ทำงานแบบกระจาย

การทำงานแบบขนาน (Parallelization) และการแคช (Caching)

Parallelization: สำหรับชุดการทดสอบขนาดใหญ่ การรันการทดสอบทั้งหมดตามลำดับอาจใช้เวลานาน เครื่องมือทดสอบ E2E ส่วนใหญ่และ unit test runner บางตัวรองรับการทำงานแบบขนาน ซึ่งเกี่ยวข้องกับการแบ่งชุดการทดสอบของคุณไปยัง virtual machine หลายเครื่องที่ทำงานพร้อมกัน บริการต่างๆ เช่น Cypress Dashboard หรือฟีเจอร์ที่มีในแพลตฟอร์ม CI สามารถจัดการสิ่งนี้ได้ ซึ่งช่วยลดเวลาการทดสอบโดยรวมลงได้อย่างมาก

Caching: การติดตั้ง `node_modules` ใหม่ทุกครั้งที่ CI ทำงานนั้นเสียเวลา แพลตฟอร์ม CI หลักๆ ทุกแห่งมีกลไกในการแคช dependencies เหล่านี้ ดังที่แสดงในตัวอย่าง GitHub Actions ของเรา (`cache: 'npm'`) การรันครั้งแรกจะช้า แต่การรันครั้งต่อๆ ไปจะเร็วขึ้นอย่างมาก เนื่องจากสามารถเรียกคืนจากแคชแทนการดาวน์โหลดใหม่ทั้งหมด

การรายงาน Code Coverage

Code coverage วัดว่าโค้ดของคุณถูกทดสอบไปกี่เปอร์เซ็นต์ แม้ว่า coverage 100% จะไม่ใช่เป้าหมายที่ปฏิบัติได้จริงหรือมีประโยชน์เสมอไป แต่การติดตามตัวชี้วัดนี้สามารถช่วยระบุส่วนของแอปพลิเคชันที่ยังไม่ได้รับการทดสอบได้ เครื่องมืออย่าง Jest สามารถสร้างรายงาน coverage ได้ คุณสามารถผนวกรวมบริการอย่าง Codecov หรือ Coveralls เข้ากับ CI pipeline ของคุณเพื่อติดตาม coverage เมื่อเวลาผ่านไป และยังสามารถทำให้ build ล้มเหลวได้หาก coverage ลดลงต่ำกว่าเกณฑ์ที่กำหนด

ตัวอย่างขั้นตอนการอัปโหลด coverage ไปยัง Codecov:

- name: Upload coverage to Codecov

uses: codecov/codecov-action@v4

with:

token: ${{ secrets.CODECOV_TOKEN }}

การจัดการข้อมูลลับ (Secrets) และตัวแปรสภาพแวดล้อม (Environment Variables)

แอปพลิเคชันของคุณมักจะต้องใช้ API key, ข้อมูลการเชื่อมต่อฐานข้อมูล หรือข้อมูลที่ละเอียดอ่อนอื่นๆ โดยเฉพาะอย่างยิ่งสำหรับการทดสอบ E2E อย่า commit ข้อมูลเหล่านี้ลงในโค้ดของคุณโดยตรง ทุกแพลตฟอร์ม CI มีวิธีที่ปลอดภัยในการจัดเก็บข้อมูลลับเหล่านี้

• ใน GitHub Actions คุณสามารถเก็บไว้ใน `Settings > Secrets and variables > Actions` จากนั้นจะสามารถเข้าถึงได้ใน workflow ของคุณผ่าน `secrets` context เช่น `${{ secrets.MY_API_KEY }}`
• ใน GitLab CI/CD สิ่งเหล่านี้จะถูกจัดการภายใต้ `Settings > CI/CD > Variables`
• ใน Jenkins ข้อมูลลับสามารถจัดการได้ผ่าน Credentials Manager ที่มีในตัว

Workflow แบบมีเงื่อนไขและการปรับปรุงประสิทธิภาพ

คุณไม่จำเป็นต้องรันทุก job ในทุก commit เสมอไป คุณสามารถปรับปรุง pipeline ของคุณเพื่อประหยัดเวลาและทรัพยากรได้:

• รัน E2E test ที่ใช้ทรัพยากรสูงเฉพาะใน pull request หรือการ merge เข้า `main` branch เท่านั้น
• ข้ามการรัน CI สำหรับการเปลี่ยนแปลงที่เกี่ยวกับเอกสารเท่านั้นโดยใช้ `paths-ignore`
• ใช้ matrix strategy เพื่อทดสอบโค้ดของคุณกับ Node.js หลายเวอร์ชันหรือระบบปฏิบัติการหลายระบบพร้อมกัน

ก้าวไปอีกขั้น: สู่เส้นทาง Continuous Deployment (CD)

Continuous Integration เป็นเพียงครึ่งแรกของสมการ ขั้นตอนต่อไปที่เป็นธรรมชาติคือ Continuous Delivery หรือ Continuous Deployment (CD)

• Continuous Delivery: หลังจากที่การทดสอบทั้งหมดผ่านใน main branch แอปพลิเคชันของคุณจะถูก build และเตรียมพร้อมสำหรับการ release โดยอัตโนมัติ โดยต้องมีการอนุมัติด้วยตนเองในขั้นตอนสุดท้ายเพื่อ deploy ไปยัง production
• Continuous Deployment: ก้าวไปอีกขั้นหนึ่ง หากการทดสอบทั้งหมดผ่าน เวอร์ชันใหม่จะถูก deploy ไปยัง production โดยอัตโนมัติโดยไม่มีการแทรกแซงของมนุษย์

คุณสามารถเพิ่ม `deploy` job เข้าไปใน CI workflow ของคุณ ซึ่งจะถูกเรียกใช้งานก็ต่อเมื่อมีการ merge สำเร็จไปยัง `main` branch เท่านั้น job นี้จะรันสคริปต์เพื่อ deploy แอปพลิเคชันของคุณไปยังแพลตฟอร์มต่างๆ เช่น Vercel, Netlify, AWS, Google Cloud หรือเซิร์ฟเวอร์ของคุณเอง

แนวคิดของ deploy job ใน GitHub Actions:

deploy:

needs: [unit-tests, e2e-tests]

runs-on: ubuntu-latest

# รัน job นี้เฉพาะเมื่อมีการ push ไปยัง main branch เท่านั้น

if: github.ref == 'refs/heads/main' && github.event_name == 'push'

steps:

# ... checkout, setup, build steps ...

- name: Deploy to Production

run: ./deploy-script.sh # คำสั่ง deploy ของคุณ

env:

DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

สรุป: ไม่ใช่แค่เครื่องมือ แต่คือการเปลี่ยนวัฒนธรรม

การนำ CI pipeline มาใช้กับโปรเจกต์ JavaScript ของคุณเป็นมากกว่างานด้านเทคนิค มันคือความมุ่งมั่นในคุณภาพ ความเร็ว และการทำงานร่วมกัน มันสร้างวัฒนธรรมที่สมาชิกทุกคนในทีม ไม่ว่าจะอยู่ที่ใดก็ตาม ได้รับการส่งเสริมให้มีส่วนร่วมได้อย่างมั่นใจ โดยรู้ว่ามีเครือข่ายความปลอดภัยอัตโนมัติที่ทรงพลังคอยรองรับอยู่

ด้วยการเริ่มต้นจากรากฐานที่มั่นคงของการทดสอบอัตโนมัติ ตั้งแต่ unit test ที่รวดเร็วไปจนถึงการเดินทางของผู้ใช้แบบ E2E ที่ครอบคลุม และผนวกรวมสิ่งเหล่านี้เข้ากับ CI workflow อัตโนมัติ คุณจะเปลี่ยนกระบวนการพัฒนาของคุณ คุณจะเปลี่ยนจากสถานะที่ต้องคอยตามแก้ไขบั๊ก ไปสู่สถานะของการป้องกันบั๊กตั้งแต่เนิ่นๆ ผลลัพธ์ที่ได้คือแอปพลิเคชันที่ยืดหยุ่นมากขึ้น ทีมพัฒนาที่มีประสิทธิภาพมากขึ้น และความสามารถในการส่งมอบคุณค่าให้กับผู้ใช้ของคุณได้รวดเร็วและน่าเชื่อถือกว่าที่เคยเป็นมา

หากคุณยังไม่ได้เริ่ม ขอให้เริ่มตั้งแต่วันนี้ เริ่มจากสิ่งเล็กๆ อาจจะเป็น linter และ unit test สองสามตัว แล้วค่อยๆ ขยายความครอบคลุมของการทดสอบและสร้าง pipeline ของคุณให้สมบูรณ์ขึ้น การลงทุนในตอนแรกจะให้ผลตอบแทนที่คุ้มค่าหลายเท่าตัวในด้านความเสถียร ความเร็ว และความสบายใจ