หลักการของ Self-Healing Tests

Test pang เพราะ locator เปลี่ยน ไม่ใช่เพราะ feature พัง

ใน automation suite ที่ใช้งานจริง สาเหตุของ test fail ที่พบบ่อยที่สุดคือ:

• locator เปลี่ยน (id, class, structure) จากการ refactor UI
• text เปลี่ยน (รวม translation, A/B test variation)
• element ถูกย้ายตำแหน่งแต่ logic เดิม
• ใช้ time delay → flaky เมื่อ network ช้า

ปัญหา: feature ทำงานปกติ แต่ test fail เพราะ locator ไม่เจอ หรือเจอผิด → false alarm

ทีมที่มี test 1000+ ตัวอาจใช้เวลา 30-50% ของ engineer ไปกับการแก้ test ที่พังจาก locator ไม่ใช่จาก bug จริง

กลไกหลักมี 3 แบบ

1. Multiple locator strategies

แทนที่จะมี selector เดียว ระบบเก็บหลาย attribute ของ element ตอน "บันทึก" test:

{
  primary: "#submit-btn",
  fallback: [
    "[data-testid='submit']",
    "button[type='submit']",
    "text=Submit"
  ],
  attributes: {
    role: "button",
    text: "Submit",
    position: { x: 450, y: 380 }
  }
}

ตอน run ถ้า primary ไม่เจอ จะลอง fallback ทีละอัน

2. Visual matching (computer vision)

จับ screenshot ของ element ตอนที่ test ผ่านครั้งแรก ตอน run ใหม่ใช้ image matching หา element ที่หน้าตาคล้ายกัน — ใช้ได้แม้ DOM เปลี่ยน

3. AI-based reasoning

ใช้ LLM อ่าน DOM ปัจจุบัน + intent ของ step ("click submit button") → AI เลือก element ที่น่าจะตรงที่สุด

ระบบหลายตัวรวม 3 แบบ และจัดลำดับความเชื่อมั่น

เห็นภาพชัดขึ้น

ก่อน UI เปลี่ยน:

<button id="submit-btn" data-testid="submit">Submit</button>

Test pass ด้วย selector #submit-btn

หลัง dev เปลี่ยน HTML:

<button id="primary-action" data-testid="submit" class="btn-cta">
  Submit
</button>

• selector #submit-btn → ไม่เจอ
• self-healing ลอง [data-testid='submit'] → เจอ
• log: "Healed: id changed, used data-testid"
• test pass + แจ้งเตือนทีมว่ามีการ heal

กรณีที่ healing เลือกผิด:

<button data-testid="submit-form">Submit form</button>
<button data-testid="submit-comment">Submit comment</button>

• self-healing เห็นมี 2 element ที่ "submit"
• เลือก element ที่ใกล้ตำแหน่งเดิม (visual matching)
• ถ้าโครงเปลี่ยน อาจเลือกผิด → test ผ่านแต่ test ผิด feature

นี่คือเหตุผลที่ self-healing ไม่ใช่ silver bullet

ตัดสินใจจากบริบทไม่ใช่ hype

หลักง่าย ๆ:

• โครงการเล็ก / มี dev disciplined → ใช้ POM + stable selector ดีกว่า
• โครงการใหญ่ / UI dynamic / หลายทีม contribute → self-healing คุ้มจ่าย

หลายวิธีลด maintenance ที่ทำได้ฟรี

หลักการ:

• ใช้ semantic locator: getByRole, getByLabel, getByText ทนต่อการเปลี่ยน CSS / structure
• บังคับ data-testid: dev ใส่ใน element ที่ test อ้างถึง — change UI ไม่กระทบ
• Page Object Model: รวม selector ไว้ที่เดียว — เปลี่ยน 1 ที่ test ทั้ง suite ใช้ได้
• Avoid CSS chains: .container > .row > div:nth-child(2) พังง่ายมาก
• Avoid index-based selection: .first(), [2] พังเมื่อมี element เพิ่ม

ทีมที่มี discipline ใน 5 ข้อนี้ มักไม่ต้องการ self-healing เลย

checklist สำหรับวันที่ vendor มาขายของ

ใช้ตอบ:

• เรามี test มากกว่า 500 ตัวขึ้นไป?
• เราใช้เวลา > 20% ของ engineering time แก้ flaky test?
• UI ของเราเปลี่ยน structure บ่อย (เกินสัปดาห์ละครั้ง)?
• ทีม dev ไม่ใส่ data-testid อย่างเป็นระบบ?
• เรามี budget vendor และยอม lock-in ได้?

ถ้าตอบ yes 4/5 — self-healing tool คุ้ม

ถ้าตอบ yes < 3 — แก้ที่ discipline + locator strategy ก่อน