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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วันที่

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

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

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

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

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

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

บทรวมเมื่อย้อนกลับ

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

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

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

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

แหล่งข้อมูล

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

ตรวจสอบความเข้าใจ