01204223/unit testing

หน้านี้เป็นส่วนหนึ่งของ 01204223

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

การทดสอบระบบมีได้หลายระดับ Unit testing เป็นการทดสอบซอฟต์แวร์ในหน่วยย่อย (unit) เช่น หนึ่งฟังก์ชัน หรือหนึ่ง component (ใน react) ส่วน Integration testing หรือ End-to-end testing เป็นการทดสอบการทำงานของส่วนย่อย ๆ ที่เชื่อมต่อกัน ในที่นี้เราจะเน้นแค่ unit testing ก่อน เพราะว่าเป็นจุดเริ่มต้นที่ดีรวมทั้งมักจะทำได้ง่ายกว่า

ในการพัฒนาเว็บแอพลิเคชัน แต่ละ unit ที่เราต้องการทดสอบมักทำงานร่วมกับส่วนอื่นๆ เช่น ถ้าพิจารณาส่วนหลังบ้าน โค้ดโดยมากก็จะทำงานกับฐานข้อมูล (database) ในขณะที่โค้ดหน้าบ้านก็จะต้องมีการเรียก API ดังนั้นการจะทดสอบแต่ละ unit จะต้องมีการสร้างหรือจำลองส่วนอื่น ๆ ของระบบเพื่อทำให้โค้ดที่เราต้องการทดสอบสามารถทำงานได้ และมีพฤติกรรมที่คงเส้นคงวาทำให้เราสามารถตรวจสอบความถูกต้องได้ เราจะได้ลองใช้เทคนิคที่เรียกว่า mock ในการจำลองการทำงานของส่วนอื่น ๆ ระหว่างที่โค้ดที่เราเทสทำงาน

ในส่วนที่ผ่านมา เวลาเราเขียน เราจะต้องเปิด flask server ไว้ และรัน npm run dev เพื่อทดสอบโค้ดที่เราทำ ในส่วนนี้ เราจะทำ unit test ที่จะทำให้เราสามารถทดสอบโค้ดได้โดยไม่ต้องเรียกผ่านทาง browser ดังนั้นก่อนจะทำ ถ้าเปิด flask server เอาไว้จากงานที่ผ่านมา สามารถปิดไปก่อนได้ อย่างไรก็ตาม ต่อให้ทดสอบมากแค่ไหน อย่างน้อยก่อนใช้จริง ก็อาจจะต้องนำมาเทสระบบภาพรวมทั้งหมดก่อนด้วย เพื่อความมั่นใจ

เนื้อหา

1 เริ่มต้นทดสอบ React component: TodoItem
2 ทดสอบ App โดยการ mock api request
3 Github action
- 3.1 Workflow
- 3.2 ทดลองเรียกใช้งาน
4 ทดสอบกันต่อ

เริ่มต้นทดสอบ React component: TodoItem

สำหรับส่วนหน้าบ้าน เราจะใช้ Vitest เป็นเครื่องมือในการรันเทสสำหรับ React component เราจะติดตั้ง vitest รวมทั้งไลบรารีอื่น ๆ โดยสั่ง

npm install -D vitest jsdom @testing-library/react @testing-library/jest-dom @testing-library/user-event

ในไดเร็กทอรี frontend

ไลบรารีที่เราติดตั้งมีหน้าที่ดังนี้

vitest เป็นระบบเทส
jsdom ใช้สำหรับจำลองหน้าจอ (dom) โดยไม่มี browser
@testing-library/xxx เป็นเครื่องมือต่าง ๆ สำหรับทดสอบ react

เมื่อเราสั่ง npm install แล้ว จะมีการเพิ่มรายการ package ต่าง ๆ รวมทั้งข้อมูลอื่น ในไฟล์ package.json และ package-lock.json ซึ่งทั้งสองไฟล์นี้จะเป็นไฟล์ที่จำเป็นในการนำโค้ดเราไปทำงานที่อื่น (นอกเหนือจากเครื่องเราเอง) เช่น รันใน container ตอนที่รัน github action

เมื่อติดตั้งเสร็จ ให้ไปแก้ไฟล์ package.json เพื่อระบุว่าเมื่อสั่ง test ให้เรียก vitest โดยดูในส่วน "scripts" และเพิ่มบรรทัดดังด้านล่างเข้าไป

// ในไฟล์ frontend/package.json

  "scripts": {
    // ละไว้
    // ** ระหว่างที่เพิ่ม อย่าลืมเติม , ท้ายบรรทัดก่อนหน้าด้วย
    "test": "vitest run"
  },

เมื่อแก้เสร็จ เราจะสามารถสั่งรันเทสได้โดยสั่ง

npm test

แต่เนื่องจากตอนนี้เราไม่มีเทสเคสเลย vitest จะบอกว่าไม่มี test files และจบการทำงาน (หมายเหตุ: เราสามารถสั่งให้ vitest ดูการแก้ไขไฟล์แล้วรันเทสใหม่ได้ แต่ในที่นี้เราเลือกจะให้รันเทสตอนที่เราสั่งก่อนเท่านั้น)

เราจะต้องไปเพิ่ม config ของ test ในไฟล์ vite.config.js ดังนี้

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
  // ** เพิ่มส่วนด้านล่างนี้ **
  test: {
    globals: true,                          // ทำให้เรียกฟังก์ชันเกี่ยวกับการเทสได้โดยไม่ต้องประกาศ
    environment: 'jsdom',                   // รันเทสแบบไม่มี browser
    setupFiles: './src/setupTests.js',      // ระบุโค้ดสำหรับเตรียมต่าง ๆ
  },
})

จากนั้นให้เพิ่มไฟล์ src/setupTests.js ดังนี้

import '@testing-library/jest-dom/vitest'
import { afterEach } from 'vitest'
import { cleanup } from '@testing-library/react'

afterEach(() => {
  cleanup()
})

โค้ดดังกล่าวจะทำให้มีการเรียกฟังก์ชัน cleanup เมื่อสิ้นสุดการรันในแต่ละเทสเคส

Test แรก

เพื่อความง่ายเราจะเริ่มจากการทดสอบ component TodoItem ก่อน เพราะว่าเป็น component ที่ไม่ได้มีการเรียก API

เราจะเก็บเทสทั้งหมดไว้ในไดเร็กทอรี frontent/src/__tests__/ ดังนั้นให้สร้างไฟล์ frontent/src/__tests__/TodoItem.test.jsx ดังนี้

import { render, screen } from '@testing-library/react'
import { expect } from 'vitest'
import TodoItem from '../TodoItem.jsx'

describe('TodoItem', () => {
  it('renders with no comments correctly', () => {
    // เดี๋ยวจะเพิ่มโค้ดตรงนี้
  });
});

โค้ดสำหรับเทสด้านบนยังไม่มีอะไร แต่ให้ลองเรียก

npm test

มาเพื่อดูผลลัพธ์ก่อน จะเห็นผลลัพธ์ดังนี้

> first-react-app@0.0.0 test
> vitest run


 RUN  v4.0.18 /home/jittat/prog/test/flask-react-todo-start/frontend

 ✓ src/__tests__/TodoItem.test.jsx (1 test) 4ms
   ✓ TodoItem (1)
     ✓ renders with no comments correctly 1ms

 Test Files  1 passed (1)
      Tests  1 passed (1)
   Start at  03:28:38
   Duration  1.15s (transform 63ms, setup 167ms, import 51ms, tests 4ms, environment 682ms)

สังเกตข้อความที่พิมพ์ออกมาในส่วน TodoItem จะมีลักษณะคล้ายกับ specification (TodoItem renders with no comments correctly) ในการเขียนเทส เราจะพยายามใส่คำอธิบายแต่ละเทสในลักษณะนี้ เพื่อให้เราสามารถอ่านผลลัพธ์ได้เข้าใจง่าย

ในการทดสอบ render TodoItem เราจะต้องมี object todo ไว้เพื่อทดสอบ เราจะแก้ไฟล์ TodoItem.test.jsx ให้เป็นดังนี้

// ** ละส่วน import
const baseTodo = {             // ** TodoItem พื้นฐานสำหรับทดสอบ
  id: 1,
  title: 'Sample Todo',
  done: false,
  comments: [],
};

describe('TodoItem', () => {
  it('renders with no comments correctly', () => {    
    // *** โค้ดสำหรับเทสที่เพิ่มเข้ามา
    render(
      <TodoItem todo={baseTodo} />
    );
    expect(screen.getByText('Sample Todo')).toBeInTheDocument();
  });
});

สังเกตโครงสร้างของการเขียนเทสด้านบน ดังนี้

เราจะเรียก render
เราใช้ฟังก์ชัน expect เพื่อตรวจสอบผลลัพธ์ สังเกตรูปแบบของชื่อฟังก์ชันต่าง ๆ ที่ออกแบบมาให้อ่านได้รู้เรื่อง เช่น toBeInTheDocument ส่วนที่เราเขียน expect นี้ จะเรียกว่า assertion ซึ่งเป็นการระบุผลลัพธ์ที่ต้องการ

โครงสร้างของการเขียนเทสแทบทั้งหมดจะมีลักษณะคล้ายกัน โดยแบ่งเป็นสามส่วนคือ (1) เตรียมการ (2) เรียกใช้สิ่งที่ต้องการเทส (3) ตรวจสอบผล

ให้ลองเรียก npm test และดูผลลัพธ์

เราจะลองแก้เทสให้ล้มเหลวเพื่อทดลองดูผลลัพธ์ ให้แก้ข้อความที่ตรวจว่ามีหรือไม่ในบรรทัด expect ให้เป็น 'Sample TodoX' แล้วทดลองรัน npm test อีกครั้ง ให้สังเกต error ที่รายงาน (จะยาวสักหน่อย)

เมื่อทดลองรันแล้ว ให้แก้เทสกลับให้เป็นแบบเดิม เพื่อให้เทสรันผ่านได้ (อย่าลืมสั่ง npm test อีกครั้ง)

🄶 ถ้าทุกอย่างใช้งานได้ อย่าลืม commit งานที่ทำด้วย

ในขั้นตอนนี้มีไฟล์ใหม่ ๆ เพิ่มมาหลายไฟล์ อย่าลืม git add ก่อนที่จะ commit

นอกจากนี้ในขั้นตอนถัด ๆ ไปเราจะใช้ github action ดังนั้นจำเป็นที่จะต้อง commit งานลงใน repository ด้วย

TodoItem แบบที่มี comments

เราจะเพิ่ม test case ดังด้านล่าง (เติมโค้ดลงไปด้านในส่วนของฟังก์ชันที่ส่งให้ describe ให้เขียน assertion ว่ามีข้อความจาก comments เอง

  it('renders with comments correctly', () => {
    const todoWithComment = {
      ...baseTodo,
      comments: [
        {id: 1, message: 'First comment'},
        {id: 2, message: 'Another comment'},
      ]
    };
    render(
      <TodoItem todo={todoWithComment} />
    );
    expect(screen.getByText('Sample Todo')).toBeInTheDocument();
    //
    // *** TODO: ให้เพิ่ม assertion ว่ามีข้อความ First comment และ Another comment บนหน้าจอ
    //
  });

ทดลองรันด้วย npm test ให้ผ่านก่อนจะทำต่อไป

🄶 อย่าลืม commit งานที่ทำด้วย

ขับเคลื่อนด้วย test

แนวทางการพัฒนาซอฟต์แวร์แบบหนึ่งที่เป็นที่นิยมคือ Test-Driven Developmen หรือ TDD ภายใต้แนวคิดนี้ เราจะเขียนเทสก่อนเขียนโค้ด และให้เทสเป็นเครื่องมือในการขับเคลื่อนการพัฒนาซอฟต์แวร์ ในส่วนนี้เราจะทดลองกระบวนการดังกล่าวสักเล็กน้อย

ขั้นที่ 1

เราจะปรับให้ TodoItem แสดงจำนวน comment และแสดงข้อความว่า No comments ถ้าไม่มี comment เลย แต่ก่อนที่เราจะทำดังกล่าว เราจะแก้ test case ก่อน จากนั้นค่อยไปแก้โค้ดให้ทำงานได้ตามที่เทสระบุ

ให้เพิ่มบรรทัด expect ด้านล่าง ลงในเทสเคส 'renders with no comments correctly' (เคสแรก)

  it('renders with no comments correctly', () => {
    // ... ละตอนต้นไว้
    expect(screen.getByText('No comments')).toBeInTheDocument();
  });

จากนั้นให้แก้ component TodoItem ให้แสดงข้อความ No comments ถ้ารายการ todo.comments นั้นมีความยาวเป็น 0 (todo.comments.length == 0) เมื่อแก้แล้วให้ทดลองรัน npm test ถ้าไม่ผ่านให้แก้จนกว่าจะผ่าน

สังเกตว่าเราจะไม่ได้ไปทดลองรันใน browser เลย และเราสามารถทดสอบโดยยังไม่ได้เรียก flask run ด้วย

ขั้นที่ 2

ข้อความ No comments ไม่ควรถูกแสดง ถ้าเรามี comments ดังนั้นในเทสเคสที่สอง เราจะตรวจว่าไม่มีข้อความดังกล่าว ให้เพิ่ม test case ด้านล่างลงไป (ควรใส่ไว้หลังเทสเคสแรก เพราะว่าอ่านรายการ test จะอ่านได้เป็นกลุ่มมากกว่า)

  it('does not show no comments message when it has a comment', () => {
    const todoWithComment = {
      ...baseTodo,
      comments: [
        {id: 1, message: 'First comment'},
      ]
    };
    render(
      <TodoItem todo={todoWithComment} />
    );
    expect(screen.queryByText('No comments')).not.toBeInTheDocument();
  });

ให้สังเกตวิธี assert ว่าไม่มีข้อความ จะเห็นว่าเราเรียกฟังก์ชัน .not คั่นไว้ก่อนจะเรียก toBeInTheDocument

ถ้าโค้ดในส่วนที่แล้วเขียนถูกต้อง เมื่อสั่ง npm test น่าจะไม่พบ error ใดๆ

ขั้นที่ 3

ในกรณีที่มี comment เราอยากเห็นจำนวน comment แสดงด้วย ให้เพิ่ม assertion ด้านล่างลงใน test case 'renders with comments correctly'

   expect(screen.getByText(/2/)).toBeInTheDocument();

สังเกตว่าเราใส่ /2/ ซึ่งเป็น regular expression แทนที่จะใส่ string ลงไปตรง ๆ เพื่อให้การ match ทำกับ substring ด้วย (ถ้าใช้ string '2' การ match จะทำกับทั้งสตริง อาจจะหาไม่เจอ)

ให้ทดลองเรียก npm test เพื่อดูว่าเทสเคสจะ fail (ขั้นตอนนี้ใช้เพื่อทดสอบว่าเราเขียนเทสที่มีผล) จากนั้นให้แก้ component TodoItem จนกระทั่งเทสผ่าน

ประโยชน์ของการแยก component. สังเกตว่า ข้อดีอีกประการจากการแยก component TodoItem คือความสะดวกในการทำ unit testing ถ้าทุกอย่างยังรวมอยู่ใน App component เราจะไม่สามารถ render TodoItem แยกออกมาเพื่อทดสอบได้ และในขั้นตอนถัดไปเราจะเห็นได้ว่าการทดสอบ App นั้นซับซ้อนกว่ามาก เพราะว่ามีการเรียก api

🄶 ถ้าโค้ดทำงานได้ อย่าลืม commit งานที่ทำด้วย

ทดสอบ App โดยการ mock api request

เราจะทดสอบ component App อย่างไรก็ตามความซับซ้อนอยู่ที่ App มีการเรียก api ไปยัง backend ที่ผ่านมา เราจะทดสอบการทำงานหน้าบ้านได้ เราต้องคอยเรียก flask server ด้วยเสมอ นอกจากนี้ สถานะของฐานข้อมูลในส่วนหลังบ้าน ทำให้หน้าจอที่แสดงออกมานั้นเปลี่ยนไปมา ถ้าจะทดสอบให้ละเอียดเราต้องคิดว่าหน้าจอที่แสดงมานั้นถูกต้องหรือไม่เสมอ ๆ ซึ่งทำให้การทดสอบนั้นไม่สะดวก รวมทั้งอาจจะก่อให้เกิดความผิดพลาดในการทดสอบได้ง่าย

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

ด้านล่างเป็นโค้ด frontend/src/__tests__/App.test.jsx เราจะอธิบายแต่ละส่วนของโค้ดสำหรับทดสอบนี้ต่อไป

import { render, screen } from '@testing-library/react'
import { vi } from 'vitest'
import App from '../App.jsx'

const mockResponse = (body, ok = true) =>
  Promise.resolve({
    ok,
    json: () => Promise.resolve(body),
});

describe('App', () => {
  beforeEach(() => {
    vi.stubGlobal('fetch', vi.fn());
  });

  afterEach(() => {
    vi.resetAllMocks();
    vi.unstubAllGlobals();
  });

  it('renders correctly', async () => {
    global.fetch.mockImplementationOnce(() =>
      mockResponse([
        { id: 1, title: 'First todo', done: false, comments: [] },
        { id: 2, title: 'Second todo', done: false, comments: [
          { id: 1, message: 'First comment' },
          { id: 2, message: 'Second comment' },
        ] },
      ]),
    );

    render(<App />);

    expect(await screen.findByText('First todo')).toBeInTheDocument();
    expect(await screen.findByText('Second todo')).toBeInTheDocument();
    expect(await screen.findByText('First comment')).toBeInTheDocument();
    expect(await screen.findByText('Second comment')).toBeInTheDocument();
  });
});

ถ้าใจร้อน นำโค้ดดังกล่าวไปสร้างไฟล์ จากนั้นเรียก npm test ดูก่อนได้ว่าผลลัพธ์ผ่านหมด

ตอนนี้ เรามาดูรายละเอียดกัน

ฟังก์ชัน mockResponse เป็นฟังก์ชันช่วยเหลือสำหรับใช้จำลองผลลัพธ์จากการเรียก fetch โดยมีสองส่วนคือส่วน ok และผลลัพธ์ json

const mockResponse = (body, ok = true) =>
  Promise.resolve({
    ok,
    json: () => Promise.resolve(body),
});

สังเกตว่าในโค้ดของ App.jsx เวลาเราเรียก fetch แล้วเราจะตรวจสอบ response.ok แล้วจากนั้นจะอ่านค่าจาก response.json() ฟังก์ชันนี้ก็จะคืนค่าจำลองผลลัพธ์ในลักษณะดังกล่าว

สองส่วนด้านล่างจะเป็นการเตรียมการก่อนและหลังการเทส โดยเราระบุว่าก่อนจะเทส (beforeEach) จะแทนที่ fetch ด้วยฟังก์ชันที่เราจะไป mock และเมื่อเสร็จแต่ละเทส (afterEach) ให้ยกเลิกแทนที่ดังกล่าว รวมทั้งรีเซ็ต mock ทั้งหมดของเรา

  beforeEach(() => {
    vi.stubGlobal('fetch', vi.fn());
  });

  afterEach(() => {
    vi.resetAllMocks();
    vi.unstubAllGlobals();
  });

เรามาดูฟังก์ชันในการทดสอบของเรากัน

  it('renders correctly', async () => {
    global.fetch.mockImplementationOnce(() =>
      mockResponse([
        { id: 1, title: 'First todo', done: false, comments: [] },
        { id: 2, title: 'Second todo', done: false, comments: [
          { id: 1, message: 'First comment' },
          { id: 2, message: 'Second comment' },
        ] },
      ]),
    );

    render(<App />);

    expect(await screen.findByText('First todo')).toBeInTheDocument();
    expect(await screen.findByText('Second todo')).toBeInTheDocument();
    expect(await screen.findByText('First comment')).toBeInTheDocument();
    expect(await screen.findByText('Second comment')).toBeInTheDocument();
  });

ส่วนสำคัญคือบรรทัดตอนบนที่ระบุ global.fetch.mockImplementationOnce เป็นการบอกว่าถ้ามีการเรียก fetch ให้คืน mockResponse ที่มี json ตามที่เราระบุ

ส่วนที่เหลือคือส่วน render และส่วน assertions ก็จะทำงานไม่ต่างจากเทสที่เราทำใน TodoItem

สังเกตว่าฟังก์ชันนี้ของเราเป็น async และในการตรวจสอบ screen จะต้องเรียกด้วย await เนื่องจากในการทำงานมีการเรียก fetch ด้านใน เราจะได้เห็นตัวอย่างอื่น ๆ เพิ่มเติมต่อไป

🄶 ถ้าโค้ดทำงานได้ อย่าลืม commit งานที่ทำด้วย อย่าลืม add ไฟล์ App.test.jsx ด้วย

Github action

เมื่อเราทำ unit test เรียบร้อยแล้ว เราสามารถใช้งาน github action ให้มีการรัน unit test เหล่านั้นโดยอัตโนมัติบน server ของ github เมื่อมีเหตุการณ์บางอย่างเกิดขึ้น เช่นมีการ push หรือทำ pull request หรืออาจจะมีการไปกดปุ่มให้ทำงานก็ได้

Workflow

ในส่วนนี้เราจะทดลองใช้งาน github action เพื่อรันเทสเหล่านี้ ในการจะใช้ github action เราจะต้องสร้าง workflow ขึ้นมาก่อน workflow เหล่านี้จะอยู่ในไดเร็กทอรี .github/workflows

ให้สร้างไดเร็กทอรี .github/workflows (นับจากรากของ git repo เลย ไม่ใช่ใน frontend) จากนั้นสร้างไฟล์ frontend-tests.yml ดังด้านล่างในไดเร็กทอรีดังกล่าว

name: Frontend Tests

on:
  push:
    paths:
      - 'frontend/**'
  pull_request:
    paths:
      - 'frontend/**'
  workflow_dispatch:

jobs:
  test-frontend:
    runs-on: ubuntu-latest

    defaults:
      run:
        working-directory: frontend

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
          cache-dependency-path: 'frontend/package-lock.json'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

ไฟล์ frontend-tests.yml นี้เป็น GitHub Actions workflow สำหรับ “รันทดสอบฝั่ง Frontend” อัตโนมัติ (และรันแบบ manual ได้ด้วย) โดยมีความหมายของแต่ละส่วนดังนี้

ภาพรวม

Workflow นี้ใช้สำหรับรันชุดทดสอบของฝั่ง Frontend โดยจะทำงานอัตโนมัติเมื่อมีการเปลี่ยนแปลงภายใต้โฟลเดอร์ frontend/ และสามารถสั่งรันด้วยมือได้ด้วย

ชื่อ workflow: Frontend Tests
รันเมื่อ:
- มีการ push ที่กระทบไฟล์ใน frontend/**
- มีการ pull_request ที่กระทบไฟล์ใน frontend/**
- สั่งรันเองแบบ manual ผ่าน workflow_dispatch
ทำอะไร: Checkout โค้ด → ติดตั้ง Node.js → ติดตั้ง dependencies → รันเทสต์ (npm test)

การ Trigger (on)

on:
  push:
    paths:
      - 'frontend/**'
  pull_request:
    paths:
      - 'frontend/**'
  workflow_dispatch:

push: รันเมื่อมีการ push โค้ดขึ้น repo แต่จะรันเฉพาะกรณีที่มีไฟล์เปลี่ยนใน path frontend/**

pull_request: รันเมื่อมีการเปิด/อัปเดต Pull Request และมีไฟล์เปลี่ยนใน frontend/**

workflow_dispatch: เปิดให้รัน workflow ได้เองจากหน้า GitHub (Actions → เลือก workflow → Run workflow) โดยไม่ต้องมี push/PR ใหม่

Jobs มีงานเดียวคือ test-frontend

jobs:
  test-frontend:
    runs-on: ubuntu-latest

test-frontend คือชื่อ job หลักที่ใช้รันทดสอบ
runs-on: ubuntu-latest เลือกเครื่อง runner ของ GitHub ที่เป็น Ubuntu เวอร์ชันล่าสุด

ค่าเริ่มต้นของคำสั่ง (defaults)

defaults:
  run:
    working-directory: frontend

ตั้งค่าให้ทุก step ที่ใช้ run: ไปทำงานในโฟลเดอร์ frontend โดยอัตโนมัติ (ไม่ต้อง cd frontend ทุกครั้ง)

Steps (ลำดับการทำงาน)

Checkout repository

- name: Checkout repository
  uses: actions/checkout@v4

ดึงซอร์สโค้ดจาก repo มาไว้บน runner เพื่อให้ขั้นตอนถัดไปเข้าถึงไฟล์ในโปรเจกต์ได้

Setup Node.js

- name: Use Node.js
  uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'
    cache-dependency-path: 'frontend/package-lock.json'

- ติดตั้ง/ตั้งค่า Node.js เวอร์ชัน 20
- เปิดใช้ cache สำหรับ npm เพื่อให้การติดตั้งเร็วขึ้นในการรันครั้งถัดไป
- ใช้ frontend/package-lock.json เป็นตัวอ้างอิงในการจัดการ cache (ถ้า lockfile ไม่เปลี่ยน มักจะ reuse cache ได้)

Install dependencies

- name: Install dependencies
  run: npm ci

ติดตั้ง dependencies แบบ CI โดยยึดตาม package-lock.json อย่างเคร่งครัด (เหมาะกับงานบน CI เพราะ reproducible)

Run tests

- name: Run tests
  run: npm test

รันชุดทดสอบของ frontend ตามที่สคริปต์ test ถูกกำหนดไว้ใน frontend/package.json

หมายเหตุ

Workflow นี้จะไม่รัน หากมีการเปลี่ยนแปลงเฉพาะไฟล์นอก frontend/**
หากต้องการทดสอบทันทีโดยไม่ push/PR สามารถใช้ manual run ได้ด้วย workflow_dispatch

🄶 เมื่อเพิ่มไฟล์ frontend-test.yml แล้ว ให้ add ลงใน git รวมทั้ง commit

ทดลองเรียกใช้งาน

หลังจาก commit ไฟล์ workflow แล้ว ให้เรา push งานที่เราทำกลับไปที่ github จากนั้นให้กดไปดูส่วน Action จะเห็นดังรูปด้านล่าง (แต่ของนิสิตจะไม่มีรายการของการ run เพราะว่าเพิ่งเปิดเข้ามา)

สังเกตว่าจะยังไม่มีการทำงานใด ๆ เพราะว่าเราระบุใน workflow ว่าจะทำถ้ามีการ push เข้ามา หรือมีการกดสั่งจากหน้าจอ

เราจะไปสั่งให้ workflow ทำงานแบบ manual กันก่อน ในรายการด้านซ้าย จะเห็น workflow Frontend Tests อยู่ ถ้าเรากดที่งานนั้น จะเห็นปุ่ม Run workflow ด้านขวา ให้ลองกดรัน จากนั้น github action จะเริ่มทำงาน เราสามารถกดเข้าไปติดตามการทำงานได้

เมื่อทำงานเสร็จ ถ้าเรากดเข้าไปจะเห็น job test-frontend อยู่ (น่าจะเป็นสีเขียว) ถ้ากดเข้าไปอีกจะเห็นผลลัพธ์การทำงานดังรูปด้านล่าง

เราสามารถทดลองแก้ test ให้ fail ก่อน (ให้ลองหาวิธีทำเล่น ๆ ดู) จากนั้น commit และ push ขึ้นไป github อีกครั้งเพื่อดูผลการทำงาน เมื่อทำงานเสร็จน่าจะเห็นผลลัพธ์ว่าเทสล้มเหลวตามรูป ซึ่งจากจุดนี้เราสามารถกดเข้าไปดูรายละเอียดได้

แก้เทสให้กลับมาผ่านเหมือนเดิม commit และ push กลับไปอีกครั้ง ก่อนจะทำต่อไป

01204223/unit testing

เนื้อหา

เริ่มต้นทดสอบ React component: TodoItem

Test แรก

TodoItem แบบที่มี comments

ขับเคลื่อนด้วย test

ขั้นที่ 1

ขั้นที่ 2

ขั้นที่ 3

ทดสอบ App โดยการ mock api request

Github action

Workflow

ทดลองเรียกใช้งาน

ทดสอบกันต่อ

รายการเลือกการนำทาง

เครื่องมือส่วนตัว

เนมสเปซ

สิ่งที่แตกต่าง

ดู

เพิ่มเติม

ค้นหา

การนำทาง

เครื่องมือ