ฉันจะทดสอบระบบที่วัตถุนั้นยากที่จะเลียนแบบได้อย่างไร

ฉันกำลังทำงานกับระบบต่อไปนี้:

Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern

เมื่อเร็ว ๆ นี้เรามีปัญหาเมื่อฉันอัปเดตเวอร์ชันของห้องสมุดที่ฉันใช้ซึ่งทำให้เกิดการประทับเวลา (ซึ่งห้องสมุดของบุคคลที่สามกลับมาเป็นlong) ซึ่งจะเปลี่ยนจากมิลลิวินาทีหลังจากยุคเป็นนาโนวินาทีหลังจากยุค

ปัญหา:

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

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

คำถาม:

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

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

ดูเหมือนว่าคุณกำลังขยันเนื่องจาก แต่ ...

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

[TestMethod]
public void MyFormatter_FormatsTimesCorrectly() {

  // this test isn't necessarily about the stream or the external interpreter.
  // but ... we depend on them working how we think they work:
  var stream = new StreamThingy();
  var interpreter = new InterpreterThingy(stream);
  stream.Write("id-123, some description, 12345");

  // this is what you're actually testing. but, it'll also hiccup
  // if your 3rd party dependencies introduce a breaking change.
  var formatter = new MyFormatter(interpreter);
  var line = formatter.getLine();
  Assert.equal(
    "some description took 123.45 seconds to complete (id-123)", line
  );
}

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

สมมติว่าคุณต้องเข้าใจและขึ้นอยู่กับวิธีที่ตัวแยกวิเคราะห์ JSON ตีความ "ประเภท" แต่ละชนิดในสตริง JSON มันมีประโยชน์และไม่สำคัญที่จะรวมสิ่งนี้ไว้ในชุดของคุณ:

[TestMethod]
public void JSONParser_InterpretsTypesAsExpected() {
  String datastream = "{nbr:11,str:"22",nll:null,udf:undefined}";
  var o = (new JSONParser()).parse(datastream);

  Assert.equal(11, o.nbr);
  Assert.equal(Int32.getType(), o.nbr.getType());
  Assert.equal("22", o.str);
  Assert.equal(null, o.nll);
  Assert.equal(Object.getType(), o.nll.getType());
  Assert.isFalse(o.KeyExists(udf));
}

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

และในระดับที่สำคัญนั่นเป็นเรื่องปกติ

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

คำตอบสั้น ๆ : มันยาก คุณอาจรู้สึกว่าไม่มีคำตอบที่ดีและนั่นเป็นเพราะไม่มีคำตอบง่าย ๆ

คำตอบยาว: เช่น@ptyx พูดว่าคุณต้องทดสอบระบบและทดสอบรวมและทดสอบหน่วย:

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

คำแนะนำเฉพาะบางประการ:

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

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

ฉันอัปเดตเวอร์ชันของห้องสมุด…ซึ่ง…ทำให้เกิดการประทับเวลา (ซึ่งห้องสมุดของบุคคลที่สามกลับมาเป็นlong) จะเปลี่ยนจากมิลลิวินาทีหลังจากยุคเป็นนาโนวินาทีหลังจากยุค

...

นี่ไม่ใช่ข้อผิดพลาดในไลบรารี

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

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

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

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

คุณต้องมีการรวมและการทดสอบระบบ

การทดสอบหน่วยดีมากเกี่ยวกับการตรวจสอบว่ารหัสของคุณทำงานตามที่คุณคาดหวัง ในขณะที่คุณตระหนักถึงมันไม่มีอะไรที่จะท้าทายสมมติฐานของคุณหรือให้แน่ใจว่าความคาดหวังของคุณมีสติ

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

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

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

มิฉะนั้นจะไม่มีเหตุผลที่จะเขียนการทดสอบหน่วยโดยมีข้อกำหนดที่กำหนดไว้ครึ่งหนึ่งและความเข้าใจที่ไม่ดีของระบบ

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

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

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