Testcontainers - การทดสอบหน่วยด้วยการพึ่งพาจริง

 (testcontainers.com)
4 คะแนน โดย GN⁺ 2024-02-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เฟรมเวิร์กโอเพนซอร์สที่提供ฐานข้อมูล, message broker, เว็บเบราว์เซอร์ และอื่น ๆ ที่สามารถรันในคอนเทนเนอร์ Docker ได้
  • ไม่จำเป็นต้องตั้งค่าสภาพแวดล้อมที่ซับซ้อนหรือใช้ mock object โดยสามารถกำหนดการพึ่งพาสำหรับการทดสอบด้วยโค้ด และเมื่อรันการทดสอบ คอนเทนเนอร์จะถูกสร้างและลบออก
  • รองรับหลายภาษาและเฟรมเวิร์กสำหรับการทดสอบ และเริ่มต้นได้หากมี Docker
  • โมดูล: ทดสอบทุกอย่างที่ทำเป็นคอนเทนเนอร์ได้
    • สามารถทดสอบคอมโพเนนต์ได้หลากหลายผ่านโมดูลมากกว่า 50 รายการ เช่น ฐานข้อมูล, message broker เป็นต้น
  • ภาษาที่รองรับ: มีการพัฒนา Testcontainers สำหรับภาษายอดนิยมหลายภาษา เช่น Java, Go, .NET, Node.js, Python, Rust, Haskell, Ruby, Clojure, Elixir เป็นต้น

กรณีการใช้งาน: วิธีที่ Testcontainers ช่วยได้

  • การทดสอบแบบบูรณาการของชั้นการเข้าถึงข้อมูล: ทดสอบโค้ดในชั้นการเข้าถึงข้อมูลโดยใช้ฐานข้อมูลที่ทำงานอยู่ในคอนเทนเนอร์
  • การทดสอบ UI/การยอมรับ: รันการทดสอบ UI อัตโนมัติโดยใช้เว็บเบราว์เซอร์แบบคอนเทนเนอร์ที่เข้ากันได้กับ Selenium
  • การทดสอบแบบบูรณาการของแอปพลิเคชัน: รันแอปพลิเคชันในโหมดทดสอบระยะสั้นที่มีการพึ่งพา เช่น ฐานข้อมูล, message queue, เว็บเซิร์ฟเวอร์ เป็นต้น เพื่อมอบสภาพแวดล้อมสำหรับการโต้ตอบและการทดสอบเชิงสำรวจที่สมบูรณ์ยิ่งขึ้น

ความเห็นของ GN⁺

  • Testcontainers ช่วยให้นักพัฒนาสามารถทดสอบในเงื่อนไขที่ใกล้เคียงกับสภาพแวดล้อมจริง ซึ่งมีส่วนช่วยยกระดับคุณภาพซอฟต์แวร์
  • การทดสอบที่มีการพึ่งพาจริงอาจให้ผลลัพธ์ที่แม่นยำกว่าการใช้ mock object แต่ในระบบที่ซับซ้อน การตั้งค่าและการจัดการอาจทำได้ยาก
  • โครงการอื่นที่มีความสามารถคล้ายกับ Testcontainers ได้แก่ Docker Compose และ Kubernetes Minikube ซึ่งก็สามารถใช้เป็นเครื่องมือช่วยทดสอบในสภาพแวดล้อมการพัฒนาได้เช่นกัน
  • การนำ Testcontainers มาใช้จำเป็นต้องมีความเข้าใจเกี่ยวกับ Docker และอาจต้องอาศัยความรู้เชิงเทคนิคด้านการจัดการคอนเทนเนอร์และการตั้งค่าเครือข่าย
  • ข้อดีของการเลือกใช้เทคโนโลยีนี้คือความสม่ำเสมอของสภาพแวดล้อมการพัฒนาและการทดสอบ รวมถึงความน่าเชื่อถือของการทดสอบที่ดีขึ้น ขณะที่ข้อเสียคือการพึ่งพาสภาพแวดล้อม Docker และความซับซ้อนที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-28
ความคิดเห็นบน Hacker News

  • สรุปคอมเมนต์แรก:

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

  • สรุปคอมเมนต์ที่สอง:

    • Testcontainers เป็นตัวเปลี่ยนเกมสำหรับการทดสอบแบบบูรณาการ
    • มี Docker API สำหรับแต่ละภาษา ทำให้สตาร์ตคอนเทนเนอร์และตรวจสอบความพร้อมในการเชื่อมต่อได้ง่าย
    • ใช้ Testcontainers สำหรับการทดสอบแบบบูรณาการในทุกโปรเจ็กต์ใหม่
    • การตั้งค่า CI รวมถึง Linting, การบิลด์, ยูนิตเทสต์ และการทดสอบแบบบูรณาการด้วย Testcontainers
    • language binding มีฟังก์ชัน helper ที่มีประโยชน์สำหรับงานฐานข้อมูล

  • สรุปคอมเมนต์ที่สาม:

    • ไม่เข้าใจว่าทำไมการใช้ docker-compose.yml ถึงไม่ดีกว่า
    • เมื่อมี dependency ที่ซับซ้อนระหว่างคอนเทนเนอร์ที่ต้องใช้ Testcontainers จะค่อนข้างอ่อน
    • เคยใช้เมื่อ 5 ปีก่อน แต่ตอนนี้สถานการณ์อาจดีขึ้นมากแล้วก็ได้

  • สรุปคอมเมนต์ที่สี่:

    • มองว่าการทดสอบแบบบูรณาการที่ใช้ฐานข้อมูลจริง/Elasticsearch/Redis/Varnish ฯลฯ มีคุณค่ามาก
    • Testcontainers ช่วยจัดการงานอย่างการสร้างดัชนี Elasticsearch ใหม่ระหว่างชุดทดสอบและปิดทิ้งเมื่อเสร็จ
    • ชอบกลยุทธ์ที่ครอบคลุมฟังก์ชันของแอปพลิเคชันให้มากที่สุดด้วยการทดสอบสไตล์บูรณาการแบบ end-to-end
    • ใช้ยูนิตเทสต์เฉพาะกับส่วนของโค้ดที่มีคู่ข้อมูลนำเข้า/ผลลัพธ์ที่ชัดเจน และใช้ mock object กับสิ่งอย่างการเรียก external API ที่ควบคุมไม่ได้

  • สรุปคอมเมนต์ที่ห้า:

    • เมื่อประมาณ 7 ปีก่อนเคยเขียน conex ซึ่งเป็น Testcontainers สำหรับภาษา Go
    • มีการผสานรวมระดับ first-class กับเฟรมเวิร์กทดสอบทางการของ Go

  • สรุปคอมเมนต์ที่หก:

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

  • สรุปคอมเมนต์ที่เจ็ด:

    • เคยลองดู Testcontainers แล้วสร้างเวอร์ชันของตัวเอง
    • Docker เป็น abstraction ที่รั่วไหลง่าย และต้องรันเทสต์ในหลายสภาพแวดล้อม
    • ระบบเครือข่ายแตกต่างกันโดยสิ้นเชิงระหว่าง Mac, Linux VM และภายใน Docker container บน Linux VM ที่เมานต์ Docker socket
    • ต้องการรันเทสต์แบบขนานและแสดงล็อกให้ตรงกับแต่ละเทสต์
    • ไม่แน่ใจว่า Testcontainers แก้ปัญหาเหล่านี้แล้วหรือยัง แต่ได้เรียนรู้ว่ารายละเอียดปลีกย่อยนี่แหละคือปัญหาใหญ่

  • สรุปคอมเมนต์ที่แปด:

    • สร้างสภาพแวดล้อมทดสอบโลคัลด้วย docker-compose
    • Testcontainers ดูเหมือนเป็น abstraction ในระดับภาษาโปรแกรมที่ช่วยนิยามสภาพแวดล้อม Docker ได้โดยไม่ต้องเรียนรู้ไวยากรณ์ของ Docker Compose
    • แต่ก็ยังต้องเข้าใจเรื่องเครือข่าย Docker, dependency และ health check เพื่อจะรู้ว่าสภาพแวดล้อมทดสอบพร้อมใช้งานเมื่อใด

  • สรุปคอมเมนต์ที่เก้า:

    • ไม่ต้องใช้ mock object หรือการตั้งค่าสภาพแวดล้อมที่ซับซ้อน
    • นิยาม dependency ของการทดสอบเป็นโค้ด แล้วเมื่อรันเทสต์ก็จะสร้างและลบคอนเทนเนอร์ให้
    • การที่สามารถรันการทดสอบแบบบูรณาการด้วยคอนเทนเนอร์ได้ ไม่ได้แปลว่าไม่จำเป็นต้องมียูนิตเทสต์
    • การตั้งค่า Docker container นั้นง่าย แต่การสตาร์ตคอนเทนเนอร์นั้นทั้งยุ่งยากและช้า

  • สรุปคอมเมนต์ที่สิบ:

    • เป็นคำถามเกี่ยวกับการใช้ Duke เป็นโลโก้ของ Java