โครงสร้าง Arrange-Act-Assert

Arrange-Act-Assert (AAA)

ไม่ว่าจะเป็น unit test, integration test, หรือ E2E test ทุก automated test มีโครงสร้าง 3 ส่วนเหมือนกัน:

Arrange (จัดเตรียม)

• เตรียมข้อมูล, สร้าง object, setup environment
• "ก่อนทำอะไร ต้องเตรียมอะไรบ้าง?"

Act (ลงมือทำ)

• เรียกฟังก์ชัน, click ปุ่ม, ส่ง request
• "ทำสิ่งที่ต้องการทดสอบ"

Assert (ตรวจสอบ)

• ตรวจผลลัพธ์ว่าตรงที่คาดไว้ไหม
• "ผลลัพธ์ถูกต้องหรือไม่?"

ตัวอย่าง 1: ทดสอบฟังก์ชันคำนวณส่วนลด

TEST "คำนวณส่วนลด 10% จากราคา 1000 บาท ได้ 900 บาท"

  // Arrange
  price = 1000
  discount_percent = 10

  // Act
  result = calculate_discount(price, discount_percent)

  // Assert
  EXPECT result TO EQUAL 900

ตัวอย่าง 2: ทดสอบ login flow

TEST "login ด้วย username/password ที่ถูกต้อง เข้าสู่หน้า dashboard"

  // Arrange
  open_browser()
  navigate_to("/login")
  username = "[email protected]"
  password = "SecurePass123"

  // Act
  fill("username_field", username)
  fill("password_field", password)
  click("login_button")

  // Assert
  EXPECT current_url TO CONTAIN "/dashboard"
  EXPECT page TO SHOW "Welcome, testuser"

ตัวอย่าง 3: ทดสอบ API

TEST "GET /api/users/1 return ข้อมูล user ที่ถูกต้อง"

  // Arrange
  create_test_user(id=1, name="สมชาย", email="[email protected]")

  // Act
  response = GET("/api/users/1")

  // Assert
  EXPECT response.status TO EQUAL 200
  EXPECT response.body.name TO EQUAL "สมชาย"
  EXPECT response.body.email TO EQUAL "[email protected]"

AAA ในภาษา Business

AAA และ Given-When-Then เป็นสิ่งเดียวกัน แค่ใช้คนละภาษา:

ตัวอย่าง Given-When-Then:

Given ผู้ใช้มีสินค้าในตะกร้า 3 ชิ้น รวม 1,500 บาท
When ผู้ใช้ใส่โค้ดส่วนลด "SAVE20"
Then ราคารวมจะลดเหลือ 1,200 บาท

ข้อถกเถียงที่ยังไม่จบ

มีสองสำนักคิด:

สำนัก Strict: 1 assertion = 1 test

• ข้อดี: เมื่อ test fail รู้ทันทีว่าผิดตรงไหน
• ข้อเสีย: test เยอะมาก setup ซ้ำ ๆ

สำนัก Practical: หลาย assertion ได้ ถ้าทดสอบ "สิ่งเดียวกัน"

• ข้อดี: test กระชับ ไม่ซ้ำซ้อน
• ข้อเสีย: เมื่อ fail อาจต้องดูว่า assertion ไหนที่พัง

คำแนะนำ: ใช้สำนัก Practical — 1 test ทดสอบ 1 behavior แต่อาจมีหลาย assertion ที่ตรวจผลลัพธ์ของ behavior เดียวกัน เช่น ทดสอบ API response อาจตรวจทั้ง status code, body, และ headers ในtest เดียว

• ส่วน Arrange ไม่ควรยาวเกิน Act + Assert รวมกัน — ถ้า setup ซับซ้อนมาก ให้ย้ายไป helper function
• ส่วน Act ควรสั้น — ปกติ 1-3 บรรทัด ถ้ายาวกว่านี้ อาจทดสอบหลาย behavior ในtest เดียว
• ส่วน Assert ต้องชัดเจน — อ่านแล้วเข้าใจทันทีว่าคาดหวังอะไร
• ชื่อ test ต้องบอกว่าทดสอบอะไร — อ่านชื่อแล้วรู้เลยว่า test นี้ทำอะไร โดยไม่ต้องอ่าน code

• ทุก automated test มีโครงสร้าง 3 ส่วน: Arrange (เตรียม) → Act (ทำ) → Assert (ตรวจ)
• AAA = Given-When-Then ในภาษา BDD — เป็นสิ่งเดียวกันแค่ต่างภาษา
• 1 test ควรทดสอบ 1 behavior — แต่อาจมีหลาย assertion ที่เกี่ยวกับ behavior เดียวกัน
• ส่วน Act ควรสั้น (1-3 บรรทัด) ส่วน Arrange ไม่ควรยาวเกินไป
• ชื่อ test ต้องบอกว่าทดสอบอะไร — อ่านชื่อแล้วเข้าใจทันที