เป็นวิธีที่ดีที่สุดในการจัดการทดสอบหน่วยของเราคืออะไร

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

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

เพิ่มไปยังสิ่งที่เราต้องทดสอบ ใช้ช่องว่างรอบเซลล์ตาราง (เราใช้ Word, Excel, & PowerPoint สำหรับการออกแบบรายงาน) เราต้องทดสอบการขยายทั่วตัวแบ่งหน้าสำหรับตารางภายในเซลล์เซลล์ที่ผสานในแนวตั้งเซลล์ที่ถูกผสานในแนวนอนเซลล์ที่ผสานในแนวตั้งและแนวนอนที่มีตารางที่มีเซลล์ที่รวมในแนวตั้งและแนวนอนในตารางด้านใน พักข้ามหน้า

ดังนั้นการทดสอบนั้นจะอยู่ในประเภทใด? การเสริมตาราง, ตัวแบ่งหน้า, เซลล์ที่ซ้อนกัน, เซลล์ที่ผสานในแนวตั้ง, เซลล์ที่รวมในแนวนอนหรืออย่างอื่น

และเราจะจัดทำเอกสารประเภทเหล่านี้ตั้งชื่อการทดสอบหน่วย ฯลฯ อย่างไร?

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

ตัวอย่างเช่นเรามีลูกค้าเมื่อวานนี้ที่เริ่มบุ๊กมาร์ก Word ที่ส่วนท้ายของลูป forEach แต่ละรายการในเทมเพลต (เอกสาร Word) และสิ้นสุดในส่วนเริ่มต้นของลูปถัดไปสำหรับแต่ละวง รหัสนี้ใช้แล้วทั้งหมดที่มีการทดสอบหน่วยกับมัน แต่เราไม่ได้คิดว่าการรวมกันของแม่แบบขยายเริ่มต้นที่คั่นหน้าจะเริ่มต้น 25 ครั้งจากนั้นก็สิ้นสุดลง 10 ครั้ง (ทั้งสองวงสำหรับแต่ละแถวมีจำนวนแถวแตกต่างกัน)

โดยทั่วไปแล้วฉันมักจะสะท้อนแผนภูมิต้นไม้สำหรับการทดสอบหน่วยของฉัน ดังนั้นถ้าฉันมี src / lib / fubar ฉันจะมีการทดสอบ / lib / fubar ซึ่งจะมีการทดสอบหน่วยสำหรับ fubar

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

โครงสร้างที่พบบ่อยที่สุดน่าจะเป็นsrcและtestมิเรอร์ไดเรกทอรี

src/module/class
test/module/class_test

อย่างไรก็ตามมีโครงสร้างทางเลือกที่ฉันได้เห็นซึ่งตอนนี้ฉันเชื่อว่าจะดีขึ้น

src/module/class
src/module/class_test

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

ใน. NET ฉันมักจะทำมิรเรอร์หรืออย่างน้อยประมาณโครงสร้างเนมสเปซสำหรับซอร์สโค้ดในโครงการทดสอบภายใต้เนมสเปซหลัก "Tests.Unit" หรือ "Tests.Integration" การทดสอบหน่วยทั้งหมดไปในโครงการเดียวโดยมีโครงสร้างพื้นฐานของซอร์สโค้ดที่จำลองแบบเป็นโฟลเดอร์ภายในโครงการ เหมือนกันสำหรับการทดสอบการรวม ดังนั้นวิธีแก้ไขปัญหาอย่างง่ายสำหรับโครงการอาจมีลักษณะเช่นนี้:

Solution
   MyProduct.Project1 (Project)
      Folder1 (Folder)
         ClassAA (Class def)
         ...
      Folder2
         ClassAB
         ...
      ClassAC
      ...
   MyProduct.Project2
      Folder1
         ClassBA
         ...
      ClassBB
      ...
   ...
   MyProduct.Tests.Unit
      Project1
         Folder1
            ClassAATests
            ClassAATests2 (possibly a different fixture setup)
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
      ...
   MyProduct.Tests.Integration
      Project1 (a folder named similarly to the project)
         Folder1 (replicate the folders/namespaces for that project beneath)
            ClassAATests
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests

สำหรับ AATs หรือ AEET ใด ๆ ที่เข้ารหัสด้วยกรอบการทดสอบหน่วยการเปลี่ยนแปลงนี้จะเปลี่ยนไปเล็กน้อย โดยปกติแล้วการทดสอบเหล่านั้นจะสะท้อนชุดของขั้นตอนต่างๆซึ่งจะทดสอบการทำงานของเคสหรือเรื่องราวการใช้งานใหม่ ฉันมักจะจัดโครงสร้างการทดสอบเหล่านี้ในMyProduct.Tests.Acceptanceโครงการด้วยการทดสอบสำหรับแต่ละเรื่องอาจจัดกลุ่มตามเหตุการณ์สำคัญหรือเรื่องราว "มหากาพย์" ที่เรื่องราวภายใต้การพัฒนาเป็นของ อย่างไรก็ตามการทดสอบเหล่านี้เป็นเพียงการทดสอบการรวมเข้าด้วยกันและดังนั้นหากคุณต้องการจัดโครงสร้างการทดสอบในเชิงวัตถุมากขึ้นแทนที่จะเป็นแฟชั่นแนวเรื่องคุณไม่จำเป็นต้องมีMyProduct.Tests.Acceptanceโครงการที่คล้ายคลึงกัน เพียงแค่โยนมันเข้าไปในMyProduct.Tests.Integrationขอบเขตของวัตถุระดับสูงสุดภายใต้การทดสอบ

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

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

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

สำหรับการตั้งชื่อไม่มีค่าพิเศษในการใช้ความพยายามกับชื่อของการทดสอบหน่วย สิ่งที่คุณต้องการฟังจากการทดสอบของคุณคือ "ผ่านการทดสอบ 5235 จาก 5235" เมื่อการทดสอบล้มเหลวสิ่งที่คุณอ่านไม่ใช่ชื่อของมัน แต่เป็นข้อความเช่นสตริงในการassert()ดำเนินการ critrion ที่ประสบความสำเร็จของคุณ ข้อความควรมีข้อมูลเพียงพอว่าคุณมีความคิดว่ามีอะไรผิดปกติโดยไม่ต้องอ่านเนื้อหาของการทดสอบ ชื่อนั้นไม่สำคัญเมื่อเทียบกับชื่อนั้น

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

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