เป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะแก้ไขโค้ดอย่างเคร่งครัดเพื่อการทดสอบ

ฉันมีการถกเถียงกับเพื่อนร่วมงานโปรแกรมเมอร์เกี่ยวกับว่ามันเป็นการปฏิบัติที่ดีหรือไม่ดีในการปรับเปลี่ยนรหัสการทำงานเพียงเพื่อให้สามารถทดสอบได้ (ผ่านการทดสอบหน่วยตัวอย่าง)

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

ความคิดเห็นของเพื่อนร่วมงานของฉันคือการแก้ไขรหัส (ใช้งานได้) เพื่อการทดสอบเท่านั้นผิด

เป็นเพียงตัวอย่างง่ายๆลองนึกถึงโค้ดชิ้นนี้ที่ใช้โดยองค์ประกอบบางส่วน (เขียนใน C #):

public void DoSomethingOnAllTypes()
{
    var types = Assembly.GetExecutingAssembly().GetTypes();

    foreach (var currentType in types)
    {
        // do something with this type (e.g: read it's attributes, process, etc).
    }
}

ฉันได้แนะนำว่ารหัสนี้สามารถแก้ไขเพื่อเรียกวิธีอื่นที่จะทำงานจริง:

public void DoSomething(Assembly asm)
{
    // not relying on Assembly.GetExecutingAssembly() anymore...
}

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

การปฏิบัติที่ดีและเหมือนกันคืออะไร?

การแก้ไขโค้ดเพื่อให้สามารถทดสอบได้มากขึ้นนั้นมีประโยชน์มากกว่าความสามารถในการทดสอบ โดยทั่วไปรหัสที่สามารถทดสอบได้มากขึ้น

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

มีกองกำลังต่อต้าน (ดูเหมือน) อยู่ในการเล่น

• ในอีกด้านหนึ่งคุณต้องการบังคับใช้การห่อหุ้ม
• ในอีกทางหนึ่งคุณต้องการทดสอบซอฟต์แวร์

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

static void Main(string[] args)

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

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

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

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

เปิดขึ้น API สำหรับการตรวจสอบเป็นสิ่งที่ดีเพราะสิ่งที่คุณกำลังทำจริงๆคือการใช้การเปิด / ปิดหลักการ

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

ดังนั้นหากการทดสอบแนะนำให้คุณเปิด API ของคุณให้ทำเช่นนั้น แต่รักษา encapsulation ไม่ใช่โดยการซ่อนความซับซ้อน แต่ด้วยการเปิดเผยความซับซ้อนในลักษณะที่ไม่ปลอดภัย

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

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

มันเป็นปัญหาไก่และไข่นิดหน่อย

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

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

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

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

แน่นอนไม่ว่าจะเป็นแนวปฏิบัติทางธุรกิจที่ดีหรือไม่ก็ตาม

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

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

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

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

ฉันคิดว่าเพื่อนร่วมงานของคุณผิด

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

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

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

ฉันใช้เครื่องมือครอบคลุมรหัสเป็นส่วนหนึ่งของการทดสอบหน่วยในการตรวจสอบว่ามีการใช้เส้นทางทั้งหมดผ่านรหัสหรือไม่ ในฐานะที่เป็นผู้เขียนโปรแกรม / ผู้ทดสอบที่ดีด้วยตัวเองฉันมักจะครอบคลุม 80-90% ของรหัสเส้นทาง

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

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

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

แน่นอนปัญหาอยู่ในลักษณะของเครื่องมือทดสอบแล้ว

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

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

มาร์ตินฟาวเลอร์มีการอภิปรายรอบ ๆ บริเวณนี้ในบทความของเขาMocks ไม่ใช่ Stubs

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

มีความแตกต่างที่ร้ายแรงระหว่างตัวอย่างของคุณ ในกรณีของDoSomethingOnAllTypes()มีความหมายที่do somethingเกี่ยวข้องกับประเภทในการชุมนุมปัจจุบัน แต่DoSomething(Assembly asm)บ่งบอกอย่างชัดเจนว่าคุณสามารถผ่านการชุมนุมใด ๆกับมัน

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

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

"การปฏิบัติที่ไม่ดี" หรือไม่ขึ้นอยู่กับว่าจะทำการเปลี่ยนแปลงเมื่อใดและอย่างไร

ใน opition ของฉันตัวอย่างของคุณเพื่อแยกวิธีการDoSomething(types)ก็โอเค

แต่ฉันได้เห็นรหัสที่ไม่ตกลงเช่นนี้:

public void DoSomethingOnAllTypes()
{
  var types = (!testmode) 
      ? Assembly.GetExecutingAssembly().GetTypes() 
      : getTypesFromTestgenerator();

  foreach (var currentType in types)
  {
     if (!testmode)
     {
        // do something with this type that made the unittest fail and should be skipped.
     }
     // do something with this type (e.g: read it's attributes, process, etc).
  }
}

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

สิ่งที่ฉันหมายถึงอย่างไรและเมื่อ :

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

if (!testmode)เป็น difficulilt มากขึ้นมากขึ้นในการทำความเข้าใจและการทดสอบกว่าวิธีสกัด