การทดสอบการรวม (ฐานข้อมูล) ไม่ดีหรือไม่?


120

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

ฉันพบว่าในบางกรณีการทดสอบหน่วยก็ไม่ได้พิสูจน์อะไรเลย

ลองมาปรับใช้การใช้พื้นที่เก็บข้อมูล (เล็กน้อย, ไร้เดียงสา) ต่อไปนี้ (ใน PHP) เป็นตัวอย่าง:

class ProductRepository
{
    private $db;

    public function __construct(ConnectionInterface $db) {
        $this->db = $db;
    }

    public function findByKeyword($keyword) {
        // this might have a query builder, keyword processing, etc. - this is
        // a totally naive example just to illustrate the DB dependency, mkay?

        return $this->db->fetch("SELECT * FROM products p"
            . " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
    }
}

สมมติว่าฉันต้องการพิสูจน์ในการทดสอบว่าที่เก็บนี้สามารถค้นหาผลิตภัณฑ์ที่ตรงกับคำหลักที่ให้มาหลากหลาย

ขาดการทดสอบการรวมกับวัตถุการเชื่อมต่อจริงฉันจะรู้ได้อย่างไรว่านี่เป็นการสร้างคำค้นหาจริงและคำถามเหล่านั้นทำในสิ่งที่ฉันคิดว่าทำจริง ๆ

ถ้าฉันต้องจำลองวัตถุการเชื่อมต่อในการทดสอบหน่วยฉันสามารถพิสูจน์ได้ว่า "มันสร้างแบบสอบถามที่คาดหวัง" - แต่นั่นไม่ได้หมายความว่ามันจะใช้งานได้จริง... นั่นคือบางทีมันอาจสร้างแบบสอบถาม ฉันคาดหวัง แต่บางทีแบบสอบถามนั้นอาจไม่ได้ทำอย่างที่คิด

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

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

คุณรับมือกับสถานการณ์เช่นนี้ได้อย่างไร

การทดสอบการรวมกันนั้น "เลวร้าย" ในกรณีเช่นนี้หรือไม่?

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


5
อ่านagitar.com/downloads/TheWayOfTestivus.pdfโดยเฉพาะอย่างยิ่งหน้า 6 "การทดสอบสำคัญกว่าตัวเครื่อง"
Doc Brown

2
@ user61852 มีข้อความระบุว่า "ไร้เดียงสา" ในคำอธิบายใช่ไหม
mindplay.dk

4
เพื่อนร่วมงานของคุณจะแน่ใจได้อย่างไรว่าฐานข้อมูลที่ล้อเลียนของเขาประพฤติตนเหมือนของจริง?
Thorbjørn Ravn Andersen

12
คุณกำลังพยายามที่จะเป็นจริง เพื่อนร่วมงานของคุณพยายามปฏิบัติตามกฎ เขียนการทดสอบที่สร้างคุณค่าเสมอ อย่าเสียเวลาเขียนแบบทดสอบที่จะไม่ทำให้เกิดความเสียหายและอย่าเขียนแบบทดสอบที่ไม่ทำสิ่งใดสิ่งหนึ่งต่อไปนี้: เพิ่มความน่าจะเป็นที่รหัสของคุณถูกต้องหรือบังคับให้คุณเขียนรหัสที่บำรุงรักษาได้มากกว่า
jpmc26

3
@ mindplay.dk: ประโยคสำคัญในวรรคนี้คือ"แต่อย่าติดอยู่ในความเชื่อใด ๆ เขียนการทดสอบที่ต้องเขียน"เพื่อนร่วมงานของคุณดูเหมือนจะติดอยู่ในความเชื่อและคุณไม่ต้องการใครสักคน อธิบายให้คุณทราบว่าการทดสอบนั้นจำเป็นต้องเขียนอะไรในตัวอย่างของคุณ - คุณรู้อยู่แล้วมันค่อนข้างชัดเจนว่าสำหรับการทดสอบว่าฐานข้อมูลของคุณเข้าใจแบบสอบถามหรือไม่คุณต้องเรียกใช้แบบสอบถามกับฐานข้อมูลจริง - ไม่มีการจำลองใด ๆ สิ่งนี้
Doc Brown

คำตอบ:


129

เพื่อนร่วมงานของคุณถูกต้องทุกอย่างที่สามารถทดสอบหน่วยควรทดสอบหน่วยและคุณถูกต้องว่าการทดสอบหน่วยจะพาคุณไปไกลและไม่ไกลโดยเฉพาะเมื่อเขียนชุดคลุมรอบ ๆ บริการภายนอกที่ซับซ้อน

วิธีการทั่วไปของการคิดเกี่ยวกับการทดสอบคือเป็นปิรามิดการทดสอบ มันเป็นแนวคิดที่เชื่อมต่อบ่อยกับเปรียวและมีหลายคนที่เขียนเกี่ยวกับเรื่องนี้รวมถึงมาร์ตินฟาวเลอร์ (ที่แอตทริบิวต์ไมค์ Cohn ในที่ประสบความสำเร็จกับเปรียว ), อลิสแตสกอตต์และบล็อกของ Google ทดสอบ

        /\                           --------------
       /  \        UI / End-to-End    \          /
      /----\                           \--------/
     /      \     Integration/System    \      /
    /--------\                           \----/
   /          \          Unit             \  /
  --------------                           \/
  Pyramid (good)                   Ice cream cone (bad)

แนวคิดคือการทดสอบหน่วยที่รวดเร็วและยืดหยุ่นเป็นพื้นฐานของกระบวนการทดสอบ - ควรมีการทดสอบหน่วยที่เน้นการทดสอบระบบ / การรวมระบบมากกว่าและการทดสอบระบบ / การรวมมากกว่าการทดสอบแบบ end-to-end ในขณะที่คุณได้ใกล้ชิดกับด้านบนการทดสอบมีแนวโน้มที่จะใช้เวลามากขึ้น / ทรัพยากรในการทำงานมีแนวโน้มที่จะเป็นเรื่องที่เปราะบางมากขึ้นและ flakiness และน้อยกว่าที่เฉพาะเจาะจงในการระบุที่ระบบหรือแฟ้มเสีย ; โดยปกติแล้วมันจะดีกว่าถ้าจะหลีกเลี่ยงการ "หนักหน่วง"

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


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


13
+1 สำหรับ "การทดสอบที่เป็นกระจกที่สมบูรณ์แบบของการนำไปใช้ไม่ได้ทดสอบอะไรเลยจริง ๆ " ทั้งหมดก็เหมือนกัน ผมเรียกนี้Doppelganger Antipattern
dodgethesteamroller

6
โรงเรียนซอฟต์แวร์ที่ขัดแย้งกัน QA ซึ่งเป็นขบวนการทดสอบที่ขับเคลื่อนด้วยบริบทนั้นเป็นส่วนหนึ่งที่อุทิศให้กับการโต้แย้งว่ามีกฎทั่วไปที่เป็นประโยชน์อย่างหนึ่งของหัวแม่มือเช่นพีระมิดทดสอบ โดยเฉพาะอย่างยิ่งตำราน้ำเชื้อ ของการเคลื่อนไหวให้ตัวอย่างมากมายที่การทดสอบการรวมมีคุณค่ามากกว่าการทดสอบประเภทอื่น ๆ (เพราะพวกเขาทดสอบระบบในบริบทเป็นระบบ ) ....
dodgethesteamroller

7
... ดังนั้นฟาวเลอร์ et al., ในการพิสูจน์ว่าความพยายามน้อยควรจะใช้เวลาในการทดสอบการรวมและการทดสอบการยอมรับของผู้ใช้เพราะพวกเขาเป็นเรื่องยากเกินไปที่จะเขียนในทางที่มีประสิทธิภาพและการบำรุงรักษาที่มีจริงๆเพียงแค่ให้โพสต์อดีตอันที่จริงข้อแก้ตัวสำหรับเหตุผลที่พวกเขาไม่ได้คิดวิธีทดสอบที่ดีในระดับที่สูงขึ้น
dodgethesteamroller

1
@dodgethesteamroller การสนทนาในเชิงลึกของ "โรงเรียนที่แตก" อย่างนั้นอาจเหมาะสมที่สุดสำหรับคำตอบของพวกเขาเอง โดยส่วนตัวแล้วฉันพบว่าบล็อกทดสอบของ Google ทำหน้าที่ได้ดีมากในการอธิบายถึงข้อดีของการทดสอบอัตโนมัติที่รวดเร็วและมีขอบเขตอย่าง จำกัดควบคู่ไปกับการทดสอบระบบในบริบท ในกรณีที่คุณพบว่าไม่ชัดเจนฉันจะแสดงรายการปิรามิดทดสอบที่นี่เป็นแบบจำลองที่มีประโยชน์หรือเป็นจุดเริ่มต้นไม่ใช่ข้ออ้างที่จะหยุดคิดในฐานะวิศวกร
Jeff Bowman

1
แนะนำอย่างสูงเกี่ยวกับลำดับชั้นและอัตราส่วนของ unittests ต่อการทดสอบการรวม: vimeo.com/80533536อธิบายได้ดีมาก
szalski

88

หนึ่งในเพื่อนร่วมงานของฉันยืนยันว่าการทดสอบการรวมเป็นสิ่งเลวร้ายและผิดทุกอย่างต้องผ่านการทดสอบหน่วย

นั่นเหมือนกับการพูดว่ายาปฏิชีวนะนั้นไม่ดีทุกอย่างควรได้รับการรักษาด้วยวิตามิน

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

กระบวนการทดสอบที่ดีและครอบคลุมนั้นใช้การทดสอบทั้งสองประเภท - การทดสอบหน่วยเพื่อตรวจสอบกฎเกณฑ์ทางธุรกิจและสิ่งอื่น ๆ ที่สามารถทดสอบได้อย่างอิสระและการทดสอบการรวมเพื่อให้แน่ใจว่าทุกอย่างทำงานร่วมกันได้

ขาดการทดสอบการรวมกับวัตถุการเชื่อมต่อจริงฉันจะรู้ได้อย่างไรว่านี่เป็นการสร้างคำค้นหาจริงและคำถามเหล่านั้นทำในสิ่งที่ฉันคิดว่าทำจริง ๆ

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


คุณจะไม่ทดสอบว่าฐานข้อมูลมีข้อมูลบางอย่างอยู่หรือไม่?
Tulains Córdova

อาจเป็นไปได้ - แต่คุณสามารถทดสอบได้ว่าฟิลเตอร์, การรวมที่ซับซ้อนและอื่น ๆ ของคุณทำงานได้หรือไม่ ตัวอย่างแบบสอบถามอาจไม่ใช่ตัวเลือกที่ดีที่สุดสำหรับ "การทดสอบหน่วย" แต่อาจมีการรวมที่ซับซ้อนและ / หรือการรวมกัน
D Stanley เมื่อ

ใช่ - ตัวอย่างที่ฉันใช้ตามที่ได้ชี้ให้เห็นนั้นเป็นเรื่องเล็กน้อย พื้นที่เก็บข้อมูลจริงสามารถมีตัวเลือกการค้นหาและเรียงลำดับที่ซับซ้อนได้ทุกอย่างเช่นใช้ตัวสร้าง
คิวรี

2
คำตอบที่ดี แต่ฉันจะเพิ่มว่าฐานข้อมูลควรอยู่ในหน่วยความจำเพื่อให้แน่ใจว่าการทดสอบหน่วยรวดเร็ว
BЈовић

3
@BЈовић: น่าเสียดายที่อาจไม่สามารถทำได้เพราะน่าเสียดายที่ไม่มีฐานข้อมูลที่เข้ากันได้สองตัวที่นั่นและบางส่วนไม่ทำงานในหน่วยความจำ นอกจากนี้ยังมีปัญหาด้านลิขสิทธิ์สำหรับฐานข้อมูลเชิงพาณิชย์ (คุณอาจไม่มีใบอนุญาตให้เรียกใช้บนเครื่องใด ๆ ), ...
Matthieu M.

17

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

นี่คือตารางแสดงอัตราการตรวจจับข้อบกพร่องสำหรับการทดสอบประเภทต่างๆ

ป้อนคำอธิบายรูปภาพที่นี่

แหล่งที่มา: p.470 ใน Code Complete 2โดย McConnell


5
ข้อมูลที่ถูกรวบรวมใน1986 นั่นคือสามสิบปีที่ผ่านมา การทดสอบหน่วยในปี 1986 ไม่ใช่สิ่งที่พวกเขาเป็นในปัจจุบัน ฉันสงสัยข้อมูลนี้ ไม่ต้องพูดถึงการทดสอบหน่วยตรวจจับข้อผิดพลาดก่อนที่จะเกิดขึ้นดังนั้นจึงสงสัยว่าพวกเขาจะถูกรายงาน
RubberDuck

3
@RubberDuck แผนภูมินี้มาจากหนังสือปี 2549 และขึ้นอยู่กับข้อมูลจากปี 1986, 1996, 2002 (หากคุณดูอย่างระมัดระวัง) ฉันไม่ได้ดูข้อมูลการรวบรวมโปรโตคอลในแหล่งที่มาฉันไม่สามารถบอกได้ว่าเมื่อใดที่พวกเขาเริ่มติดตามข้อบกพร่องและวิธีการรายงาน แผนภูมินี้อาจล้าสมัยหรือไม่ มันสามารถ. เมื่อเดือนธันวาคมที่แล้วฉันอยู่ในการสัมมนาและผู้สอนกล่าวว่าการทดสอบการรวมพบข้อบกพร่องมากกว่าการทดสอบหน่วย (โดยปัจจัยที่ 2, iirc) แผนภูมินี้บอกว่าพวกเขาเหมือนกัน
Nick Alexeev

13

ไม่พวกเขาไม่เลว หวังว่าจะมีการทดสอบหน่วยและการรวมเข้าด้วยกัน พวกเขาจะใช้และทำงานในระยะต่าง ๆ ในวงจรการพัฒนา

ทดสอบหน่วย

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

ดังนั้นสำหรับฐานข้อมูลหนึ่งควรมีสิ่งที่ชอบ:

IRespository

List<Product> GetProducts<String Size, String Color);

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

การทดสอบบูรณาการ

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

  • สภาพพร้อมความมั่นคงทางสุขภาพสิ่งแวดล้อม
  • ทดสอบของจริง

การทดสอบเหล่านี้บางครั้งยากที่จะเรียกใช้เนื่องจากเราอาจจำเป็นต้องตั้งค่าและ / หรือทำลายลงเช่นกัน พิจารณาเพิ่มผลิตภัณฑ์ เราอาจต้องการเพิ่มผลิตภัณฑ์สอบถามเพื่อดูว่ามีการเพิ่มหรือไม่หลังจากนั้นเราก็เอาออก เราไม่ต้องการเพิ่มผลิตภัณฑ์ "การรวม" 100s หรือ 1,000 รายการดังนั้นจำเป็นต้องมีการตั้งค่าเพิ่มเติม

การทดสอบการรวมสามารถพิสูจน์ให้เห็นว่ามีคุณค่ามากในการตรวจสอบสภาพแวดล้อมและทำให้แน่ใจว่าสิ่งที่ใช้งานได้จริง

หนึ่งควรมีทั้ง

  • รันการทดสอบหน่วยสำหรับทุกบิลด์
  • รันการทดสอบการรวมสำหรับการปรับใช้ทุกครั้ง

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

@ArtBristol - โดยทั่วไปแล้วบิลด์เซิร์ฟเวอร์ของเราจะไม่ได้กำหนดค่าการพึ่งพาสภาพแวดล้อมแบบเต็มดังนั้นเราจึงไม่สามารถทำการทดสอบการรวมระบบได้ แต่ถ้าใครสามารถรันการทดสอบการรวมที่นั่นไปได้เลย เรามีการติดตั้งแซนด์บ็อกซ์การปรับใช้หลังจากโครงสร้างที่เราใช้สำหรับการทดสอบการรวมเพื่อตรวจสอบการปรับใช้ แต่ในแต่ละสถานการณ์นั้นแตกต่างกัน
Jon Raynor

11

การทดสอบการรวมฐานข้อมูลไม่เลว ยิ่งกว่านั้นพวกเขามีความจำเป็น

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

ในทางทฤษฎีคุณสามารถทดสอบหน่วยฐานข้อมูลโดยการแยกวิเคราะห์และตีความ SQL ที่สร้างขึ้นมันเป็นวิธีที่ง่ายและเชื่อถือได้มากขึ้นในการสร้างฐานข้อมูลทดสอบทันทีและพูดคุยกับมัน

ข้อสรุป

เป็นความเชื่อมั่นที่ geined จากหน่วยทดสอบของคุณคืออะไรRepository บทคัดย่อ , เบาหวิววัตถุสัมพันธ์-Mapper , ทั่วไป Active Record , ทฤษฎีความคงทนชั้นเมื่อในที่สุด SQL สร้างของคุณมีไวยากรณ์ผิดพลาด?


ฉันคิดว่าจะเพิ่มการตอบกลับที่คล้ายกับของคุณ แต่คุณบอกว่าดีกว่า! จากประสบการณ์ของฉันที่มีการทดสอบในเลเยอร์ที่รับและจัดเก็บข้อมูลได้ช่วยให้ฉันเสียใจมาก
Daniel Hollinrake

การทดสอบการรวมฐานข้อมูลไม่ดี คุณมีฐานข้อมูลที่มีอยู่ในสาย ci / cd ของคุณหรือไม่ ดูเหมือนว่าซับซ้อนสำหรับฉัน มันง่ายกว่ามากในการจำลองเนื้อหาของฐานข้อมูลและสร้างเลเยอร์ของนามธรรมเพื่อใช้สิ่งนั้น ไม่เพียง แต่เป็นโซลูชั่นที่สง่างามกว่ามันเร็วเท่าที่จะเป็นไปได้ การทดสอบหน่วยจะต้องรวดเร็ว การทดสอบฐานข้อมูลของคุณจะทำให้ unittests ช้าลงอย่างมากจนไม่สามารถยอมรับได้ Unittests ไม่ควรใช้เวลา> 10 นาทีถึงจะเสร็จสิ้นแม้ว่าคุณจะมีพวกเขาหลายพันคนก็ตาม
เดวิด

@David คุณมีฐานข้อมูลที่มีอยู่ในสาย ci / cd ของคุณหรือไม่? แน่นอนว่าที่สวย มาตรฐาน คุณลักษณะ BTW ฉันไม่ได้เรียกร้องการทดสอบการรวมระบบแทนการทดสอบหน่วย - ฉันสนับสนุนการทดสอบการรวมระบบร่วมกับการทดสอบหน่วย การทดสอบหน่วยแบบรวดเร็วนั้นเป็นสิ่งจำเป็น แต่ฐานข้อมูลนั้นซับซ้อนเกินกว่าที่จะใช้การทดสอบแบบหน่วยกับการโต้ตอบที่จำลอง
el.pescado

@ el.pescado ฉันต้องไม่เห็นด้วย หากการสื่อสารฐานข้อมูลของคุณอยู่เบื้องหลังเลเยอร์ของสิ่งที่เป็นนามธรรมมันเป็นเรื่องง่ายที่จะเยาะเย้ย คุณสามารถตัดสินใจว่าจะส่งคืนวัตถุใด นอกจากนี้ความจริงที่ว่าสิ่งที่เป็นมาตรฐานไม่ได้ทำให้มันเป็นสิ่งที่ดี
เดวิด

@ David ฉันคิดว่ามันขึ้นอยู่กับว่าคุณเข้าใกล้ฐานข้อมูลอย่างไร มันเป็นรายละเอียดการใช้งานหรือส่วนสำคัญของระบบ ? (ฉันยันต่อหลัง) หากคุณถือว่าฐานข้อมูลเป็นที่เก็บข้อมูลที่เป็นใบ้คุณอาจทำโดยไม่มีการทดสอบการรวมระบบ อย่างไรก็ตามหากมีเหตุผลใด ๆ ในฐานข้อมูล - ข้อ จำกัด ทริกเกอร์คีย์ต่างประเทศธุรกรรมหรือชั้นข้อมูลของคุณใช้ SQL แบบกำหนดเองแทนวิธี ORM ธรรมดาฉันรู้สึกว่าการทดสอบหน่วยเพียงอย่างเดียวจะไม่เพียงพอ
el.pescado

6

คุณต้องการทั้งคู่

ในตัวอย่างของคุณถ้าคุณกำลังทดสอบว่าฐานข้อมูลในสภาพที่แน่นอนเมื่อfindByKeywordวิธีการทำงานคุณได้รับข้อมูลกลับมาคุณคาดว่าจะเป็นการทดสอบการรวมที่ดี

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


6

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

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

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

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

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

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

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

อีกประเด็นที่ควรพิจารณาคือระดับการพึ่งพาของแอปพลิเคชันของคุณกับฐานข้อมูล

  • หากแอปพลิเคชันของคุณตามโมเดล CRUD ซึ่งคุณมีเลเยอร์ของนามธรรมที่ให้คุณสลับระหว่าง RDBMS ใด ๆ ด้วยวิธีการตั้งค่าที่เรียบง่ายโอกาสที่คุณจะสามารถทำงานกับระบบจำลองได้อย่างง่ายดาย เส้นแบ่งระหว่างหน่วยและการทดสอบแบบรวมโดยใช้ RDBMS ในหน่วยความจำ
  • หากแอปพลิเคชันของคุณใช้ตรรกะที่ซับซ้อนมากขึ้นสิ่งที่จะเฉพาะเจาะจงกับหนึ่งใน SQL Server, MySQL, PostgreSQL (ตัวอย่าง) จากนั้นโดยทั่วไปแล้วจะมีเหตุผลมากขึ้นที่จะมีการทดสอบที่ใช้ระบบเฉพาะนั้น

"แอปพลิเคชั่นจำนวนมากในวันนี้จะไม่สามารถใช้งานได้เลยถ้าเซิร์ฟเวอร์ฐานข้อมูลของพวกเขาล่ม" - นั่นเป็นจุดสำคัญจริงๆ!
el.pescado

คำอธิบายที่ดีของข้อ จำกัด ของ mocks ที่ซับซ้อนเช่นการใช้ภาษาอื่นในการเยาะเย้ย SQL เมื่อรหัสทดสอบมีความซับซ้อนพอที่ดูเหมือนว่าจะต้องมีการทดสอบตัวเองนั่นคือกลิ่น QA
dodgethesteamroller

1

คุณมีสิทธิ์ที่จะคิดว่าการทดสอบหน่วยดังกล่าวไม่สมบูรณ์ ความไม่สมบูรณ์อยู่ในอินเทอร์เฟซฐานข้อมูลที่ถูกเยาะเย้ย ความคาดหวังหรือการยืนยันที่ไร้เดียงสาของคนไร้เดียงสาดังกล่าวไม่สมบูรณ์

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

แต่มักจะลืมและค่อนข้างแพงทางเลือก / สหายกับเยาะเย้ยเป็น"การทำงานแบบเสมือน"

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

ตอนนี้อาจมีคนบอกว่าคุณเปลี่ยนการทดสอบหน่วยเป็นการทดสอบการรวม มีมุมมองที่แตกต่างกันเกี่ยวกับตำแหน่งที่จะลากเส้นเพื่อจำแนกระหว่างการทดสอบหน่วยและการทดสอบการรวม IMHO "หน่วย" เป็นคำนิยามโดยพลการและควรเหมาะสมกับความต้องการของคุณ


1
ดูเหมือนว่าจะทำซ้ำคะแนนและอธิบายในคำตอบก่อนหน้านี้ที่โพสต์เมื่อหลายชั่วโมงก่อน
gnat

0

Unit TestsและIntegration Testsมีมุมฉากซึ่งกันและกัน พวกเขาเสนอมุมมองที่แตกต่างกันในแอปพลิเคชันที่คุณกำลังสร้าง โดยปกติคุณต้องการทั้งสองอย่าง แต่จุดในเวลานั้นแตกต่างกันเมื่อคุณต้องการการทดสอบประเภทใด

Unit Testsส่วนใหญ่มักจะคุณต้องการ การทดสอบหน่วยจะมุ่งเน้นไปที่ส่วนเล็ก ๆ ของรหัสที่กำลังทดสอบ - สิ่งที่เรียกว่า a unitถูกปล่อยให้ผู้อ่าน แต่วัตถุประสงค์เต้เป็นเรื่องง่าย: ได้รับอย่างรวดเร็วข้อเสนอแนะของเมื่อและที่รหัสของคุณยากจน ที่กล่าวว่ามันควรมีความชัดเจนที่เรียกร้องไปยังที่เกิดขึ้นจริง DB เป็นnono

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


0

ใน. Net โลกฉันมีนิสัยในการสร้างโครงการทดสอบและสร้างการทดสอบเป็นวิธีการเข้ารหัส / การดีบัก / การทดสอบไปกลับลบด้วย UI นี่เป็นวิธีที่มีประสิทธิภาพสำหรับฉันในการพัฒนา ฉันไม่ได้สนใจที่จะทำการทดสอบทั้งหมดสำหรับทุกบิลด์ (เพราะมันทำให้กระบวนการทำงานของฉันช้าลง) แต่ฉันเข้าใจถึงประโยชน์ของสิ่งนี้สำหรับทีมที่ใหญ่กว่า อย่างไรก็ตามคุณสามารถสร้างกฎก่อนที่จะส่งมอบรหัสการทดสอบทั้งหมดควรจะถูกเรียกใช้และผ่าน (ถ้าการทดสอบใช้เวลานานกว่านั้นเพราะฐานข้อมูลกำลังถูกโจมตีจริง)

การเลียนแบบ data access layer (DAO) และไม่ได้กดปุ่มฐานข้อมูลไม่เพียง แต่ไม่อนุญาตให้ฉันใช้รหัสในแบบที่ฉันชอบและคุ้นเคย หากคุณไม่ได้ทดสอบเลเยอร์การเข้าถึงข้อมูลและฐานข้อมูลอย่างแท้จริงและเพียงแค่แกล้งทำเป็นและจากนั้นใช้เวลามากในการเยาะเย้ยฉันไม่เข้าใจถึงประโยชน์ของวิธีการนี้ในการทดสอบรหัสของฉัน ฉันกำลังทดสอบชิ้นเล็ก ๆ แทนที่จะเป็นชิ้นใหญ่กว่าด้วยการทดสอบหนึ่งครั้ง ฉันเข้าใจว่าวิธีการของฉันอาจมีมากขึ้นตามแนวของการทดสอบการรวม แต่ดูเหมือนว่าการทดสอบหน่วยด้วยการเยาะเย้ยนั้นเป็นการเสียเวลามากเกินไปหากคุณเพียงแค่เขียนการทดสอบการรวมเป็นครั้งแรก นอกจากนี้ยังเป็นวิธีที่ดีในการพัฒนาและแก้ไขข้อบกพร่อง

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

ในความเป็นจริงฉันคิดว่าบางอย่างเช่น Behavior Driven Design (BDD) ที่พยายามทดสอบตั้งแต่ต้นจนจบด้วยภาษาเฉพาะโดเมน (DSL) ควรเป็นวิธีที่จะไป เรามี SpecFlow ใน. Net world แต่มันเริ่มต้นเป็นโอเพ่นซอร์สกับแตงกวา

https://cucumber.io/

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

อ้างอิงจาก Stack Overflow การเยาะเย้ยจะใช้เมื่อวัตถุจริงทำไม่ได้เพื่อรวมเข้ากับการทดสอบหน่วย

https://stackoverflow.com/questions/2665812/what-is-mocking

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

อาร์กิวเมนต์ของฉันคือถ้าฉันเขียนโค้ดแบบ end-to-end (web UI ไปยังเลเยอร์ธุรกิจไปยัง data access layer ไปยังฐานข้อมูล, ไปกลับ) ก่อนที่ฉันจะตรวจสอบสิ่งใดในฐานะนักพัฒนาฉันจะทดสอบ flow trip trip นี้ ถ้าฉันตัด UI ออกและตรวจแก้จุดบกพร่องและทดสอบโฟลว์นี้เริ่มต้นจากการทดสอบฉันกำลังทดสอบทุกสิ่งทุกอย่างของ UI และคืนสิ่งที่ UI ต้องการ ที่เหลือคือส่ง UI ตามที่ต้องการ

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

ผู้ร่วมก่อตั้ง Stack Exchange ไม่มั่นใจเกี่ยวกับประโยชน์ของการมีหน่วยทดสอบครอบคลุม 100% ฉันยังไม่ได้ ฉันจะใช้ "การทดสอบบูรณาการ" ที่สมบูรณ์ยิ่งขึ้นซึ่งจะกระทบฐานข้อมูลมากกว่าการบำรุงรักษาฐานข้อมูลจำนวนมากทุกวัน

https://www.joelonsoftware.com/2009/01/31/from-podcast-38/


เป็นที่ชัดเจนว่าคุณไม่เข้าใจความแตกต่างระหว่างการทดสอบหน่วยและการรวมเข้าด้วยกัน
BЈовић

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

-1

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

ด้วยการทดสอบหน่วยที่แท้จริงคุณกำลังทดสอบภายในขอบเขตของ sandbox และควรมีความชัดเจน หากนักพัฒนาเขียนแบบสอบถาม SQL ที่ล้มเหลวใน QA / PROD หมายความว่าพวกเขาไม่ได้ทดสอบก่อนเวลานั้น


+1 สำหรับ"คุณไม่สามารถควบคุมพวกเขา (พวกเขาอาจจะผ่านในระหว่างขั้นตอนการทดสอบการรวม แต่ล้มเหลวในการผลิต)"
Tulains Córdova

คุณสามารถควบคุมพวกเขาในระดับที่น่าพอใจ
el.pescado

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

5
ฉันไม่เห็นด้วยอย่างแน่นอน คุณควรเขียนการทดสอบการรวม (เพิ่มเติม) เนื่องจากการพึ่งพาภายนอกอาจล้มเหลว การพึ่งพาจากภายนอกอาจมีนิสัยใจคอของตนเองซึ่งคุณมักจะพลาดเมื่อคุณเยาะเย้ยทุกอย่าง
Paul Kertscher

1
@ พอลก์ยังคงไตร่ตรองว่าคำตอบใดที่ทำเครื่องหมายว่ายอมรับแล้ว แต่ฉันก็เอนตัวไปสู่ข้อสรุปเดียวกัน
mindplay.dk
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.