ตำแหน่งที่ทำการทดสอบ

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

สคริปต์ที่ต้องมีก่อน

โปรเจ็กต์บนเว็บมักจะมีไฟล์การกำหนดค่าซึ่งเป็นไฟล์ package.json ที่ตั้งค่าโดย npm, pnpm, Bun หรือคล้ายกัน ไฟล์การกำหนดค่านี้มีทรัพยากร Dependency ของโปรเจ็กต์และข้อมูลอื่นๆ รวมถึงสคริปต์ตัวช่วย สคริปต์ตัวช่วยเหล่านี้อาจประกอบด้วยวิธีสร้าง เรียกใช้ หรือทดสอบโปรเจ็กต์

ภายใน package.json คุณจะต้องเพิ่มสคริปต์ชื่อ test ซึ่งอธิบายวิธีเรียกใช้การทดสอบ สิ่งนี้มีความสำคัญเนื่องจากเมื่อใช้ npm หรือเครื่องมือที่คล้ายกัน สคริปต์"test" มีความหมายพิเศษ สคริปต์นี้สามารถชี้ไปที่ไฟล์เดียวที่มีข้อยกเว้น เช่น node tests.js แต่เราแนะนำให้ใช้สคริปต์ดังกล่าวชี้ไปยังตัวดำเนินการทดสอบที่สร้างขึ้น

หากคุณใช้ Vitest เป็นตัวดำเนินการทดสอบ ไฟล์ package.json จะมีลักษณะดังนี้

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

การเรียกใช้ npm test โดยใช้ไฟล์นี้จะเรียกใช้ชุดการทดสอบเริ่มต้นของ Vitest 1 ครั้ง ใน Vitest ค่าเริ่มต้นคือค้นหาไฟล์ทั้งหมดที่ลงท้ายด้วย ".test.js" หรือคล้ายกันและเรียกใช้ คำสั่งอาจแตกต่างกันไปเล็กน้อย ขึ้นอยู่กับตัวดำเนินการทดสอบที่คุณเลือก

สำหรับโปรเจ็กต์ขนาดเล็กถึงขนาดกลาง ให้สคริปต์นี้ทำการทดสอบทั้งหมดของคุณได้ อย่างไรก็ตาม เมื่อโปรเจ็กต์เติบโตขึ้น คุณอาจต้องทำการทดสอบที่ "เร็ว" ที่นี่เท่านั้น หากนักพัฒนาแอปใช้ npm test ในบรรทัดคำสั่ง คำสั่งนี้ไม่ควรใช้เวลาเกิน 2-3 วินาที และอาจไม่ควรโหลดเบราว์เซอร์หรือไปยังเครือข่าย

วิธีหนึ่งในการบังคับใช้ก็คือการเรียกใช้ไฟล์บางชุดหรือการทดสอบที่กรองตามชื่อเท่านั้น Vitest มีตัวกรองบรรทัดคำสั่งที่คุณระบุใน package.json

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

การเรียกใช้การทดสอบด้วยตนเอง

การทริกเกอร์การทดสอบอัตโนมัติด้วยตนเอง (เช่น การใช้ npm test ในตัวอย่างก่อนหน้านี้) อาจใช้งานได้จริงในขณะที่คุณทำงานบนฐานของโค้ดอยู่ การเขียนการทดสอบสำหรับฟีเจอร์ในขณะที่พัฒนาฟีเจอร์นั้นจะช่วยให้คุณทราบว่าฟีเจอร์ควรทำงานอย่างไร ซึ่งสื่อถึงแนวคิดของการพัฒนาที่ขับเคลื่อนโดยการทดสอบ (TDD)

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

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

สำหรับโปรเจ็กต์ขนาดเล็ก โดยเฉพาะโปรเจ็กต์ที่มีนักพัฒนาซอฟต์แวร์เพียงรายเดียว คุณอาจต้องการใช้งานชุดทดสอบทั้งหมดของโค้ดเบสเป็นประจำ วิธีนี้มีประโยชน์อย่างยิ่งในกรณีที่การทดสอบมีขนาดเล็กและเสร็จสิ้นอย่างรวดเร็ว (โดยใช้เวลาไม่เกิน 2-3 วินาทีสำหรับการทดสอบทั้งหมด) คุณจึงมั่นใจได้ว่าทุกอย่างจะทำงานได้ถูกต้องก่อนที่จะดำเนินการต่อ

ทำการทดสอบโดยเป็นส่วนหนึ่งของการส่งล่วงหน้าหรือตรวจสอบ

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

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

เช่น GitHub เรียกการดำเนินการนี้ว่า "การตรวจสอบสถานะ" ซึ่งคุณสามารถเพิ่มได้ผ่านการดำเนินการของ GitHub การดำเนินการของ GitHub เป็นการทดสอบประเภทพื้นฐาน กล่าวคือ แต่ละขั้นตอนต้องประสบความสำเร็จ (ไม่ใช่ล้มเหลว หรือทำ Error ขว้าง) เพื่อให้การดำเนินการผ่าน คุณใช้ Actions กับ PR ทั้งหมดสำหรับโปรเจ็กต์ได้ และโปรเจ็กต์อาจกำหนดให้ Actions ต้องผ่านก่อนลงโค้ดได้ การดำเนินการ Node.js เริ่มต้นของ GitHub จะเรียกใช้ npm test เป็นหนึ่งในขั้นตอน

ภาพหน้าจอของกระบวนการทดสอบการดำเนินการของ GitHub

วิธีการทดสอบนี้จะช่วยให้มั่นใจว่าฐานของโค้ดจะเป็น "สีเขียว" เสมอ โดยการไม่ยอมรับโค้ดที่ทำการทดสอบไม่สำเร็จ

เรียกใช้การทดสอบในฐานะส่วนหนึ่งของการผสานรวมอย่างต่อเนื่อง

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

หากคุณไม่ได้ทำ PR หรือการตรวจสอบโค้ด การเรียกใช้การทดสอบในฐานะ CI โดยอัตโนมัติจากสาขา main เป็นทางเลือกที่ดี ซึ่งเหมาะกับโปรเจ็กต์ส่วนตัวที่ PR ไม่สมเหตุสมผล

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

• มีการยอมรับการเปลี่ยนแปลงหลายรายการ "พร้อมกัน" บางครั้งเรียกว่าภาวะเชื้อชาติ และส่งผลกระทบซึ่งกันและกันอย่างแยบยลและไม่ผ่านการทดสอบ
• การทดสอบของคุณไม่สามารถทำซ้ำได้ หรือทดสอบโค้ดที่ "ไม่สม่ำเสมอ" การทดสอบอาจผ่านและล้มเหลวโดยไม่มีการเปลี่ยนแปลงโค้ดใดๆ
  • ปัญหานี้อาจเกิดขึ้นหากคุณใช้ระบบที่อยู่นอกฐานของโค้ด สำหรับพร็อกซี ให้ลองคิดว่าทดสอบว่า Math.random() > 0.05 หรือไม่ ซึ่งแสดงว่าล้มเหลวโดยบังเอิญ 5% ของทั้งหมด
• การทดสอบบางอย่างมีค่าใช้จ่ายสูงหรือแพงเกินกว่าที่จะทำในการประชาสัมพันธ์ทุกครั้ง เช่น การทดสอบแบบครบวงจร (ดูข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในการทดสอบอัตโนมัติประเภทต่างๆ) และสามารถหยุดพักได้เมื่อเวลาผ่านไปโดยไม่ต้องแจ้งเตือนเสมอไป

ปัญหาเหล่านี้ไม่สามารถแก้ได้สำเร็จ แต่คุณควรตระหนักว่าการทดสอบและการพัฒนาซอฟต์แวร์โดยทั่วไปนั้นไม่ใช่ศาสตร์ที่ตายตัว

แทรกเวลาย้อนกลับ

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

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

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

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

แหล่งข้อมูล

• ประโยชน์ของการมีงานสร้างตอนกลางคืน

ทดสอบความเข้าใจ

ชื่อสคริปต์พิเศษที่ npm และโปรแกรมที่คล้ายกันมองหาชื่ออะไรขณะทดสอบ

เลือก

ทดสอบ

ส่งล่วงหน้า

ยืนยัน