คุณจะเขียนการทดสอบสำหรับรหัสที่ขึ้นอยู่กับการใช้งานภายนอกที่เป็นรูปธรรมที่ไม่สามารถเยาะเย้ยได้อย่างไร

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

อย่างไรก็ตามปัญหาคือโมดูลนั้นขึ้นอยู่กับปัจจัยภายนอกที่ไม่สามารถยกเลิกได้เช่น PDF และ XSL โดยทั่วไปฉันอ่าน XML จากฐานข้อมูลและใช้การแปลง XSL กับมันจากนั้นแปลงเป็น PDF โดยใช้ไลบรารีที่เรียกว่า ABCPDF PDF นี้จะถูกรวมเข้ากับ PDF อื่นตามแม่แบบคงที่ ฉันรู้ว่าฉันสามารถทดสอบ XML และตรวจสอบให้แน่ใจว่าค่านั้นถูกต้อง แต่ข้อบกพร่องที่เป็นไปได้จำนวนมากและปัญหาที่เกี่ยวข้องกับการแสดงผลที่แท้จริงของเอกสารที่เสร็จแล้ว - เช่น minutiae เช่นสตริงข้อความยาวแค่ไหน ตั้งอยู่ในความสัมพันธ์กับเอกสาร ฯลฯ เป็นไปได้หรือไม่ที่จะทดสอบสิ่งเหล่านี้ (ฉันรู้ว่าสิ่งเหล่านี้อาจเป็นการทดสอบการรวมหรือการทดสอบประเภทที่สามที่ชื่อฉันลืม [ไม่ใช่แบบทดสอบการยอมรับประเภทอื่น] และไม่ใช่หน่วย การทดสอบ) เนื่องจากฉันไม่สามารถรู้ได้ว่าจะลอกแบบ PDF สั้น ๆ ง่ายๆจากการสร้างจากนั้นอ่านกลับหรือสร้างสตริง HTML (เช่นแปลง XML) และแยกวิเคราะห์ด้วยมือเพื่อตรวจสอบว่ามีเซลล์ตารางบางตัวใน ความสัมพันธ์กับเซลล์ตารางอื่น ๆ

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

ทดสอบคุณสมบัติไม่ใช่เครื่อง

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

การทดสอบในอนาคตโดยใช้อินพุต xml เดียวกันสามารถทำการเปรียบเทียบไฟล์ไบนารีกับการอ้างอิง

หากการเปรียบเทียบระดับไฟล์ไม่เป็นที่น่าพอใจให้แสดง PDF เมื่อสิ้นสุดการทดสอบและจับภาพหน้าจอจากนั้นให้ทำการทดสอบอัตโนมัติเปรียบเทียบกับภาพหน้าจออ้างอิง

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

public class PdfBuilder : IPdfBuilder
{
  public byte[] BuildPdf(...)
  {
    // actual untestable code here
  }
}

public interface IPdfBuilder
{
  byte[] BuildPdf(...);
}

จากนั้นคุณสามารถจำลอง IPdfBuilder ในการทดสอบเพื่อทำสิ่งที่คุณต้องการ บ่อยครั้งที่คุณต้องเริ่มใช้คอนเทนเนอร์ IoC ( /programming/871405/why-do-i-need-an-ioc-container-as-opposed-to-straightforward-di-code)และ/programming/21288/which-net-dependency-injection-frameworks-are-worth-looking-intoเป็นสถานที่เริ่มต้น) หากคุณไม่ได้ใช้งานตอนนี้

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

แจ้งให้เราทราบหากนี่ไม่ชัดเจนทั้งหมด

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

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