มันจะไม่เป็นประโยชน์ในการเขียนการทดสอบระหว่างการตรวจสอบรหัส?


24

เพื่อนร่วมงานของฉันเกิดขึ้นกับความคิดที่ฉันพบว่าน่าสนใจ

มันจะไม่เป็นประโยชน์ในการเขียนการทดสอบในระหว่างการตรวจสอบโค้ดโดยผู้ที่ทำการตรวจสอบโดยสมมติว่าเราไม่ได้ทำ TDD?

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

ข้อดีที่ฉันพบ:

  1. ส่งเสริมความเข้าใจที่ลึกซึ้งยิ่งขึ้นของรหัสระหว่างการทบทวนเพื่อเขียนการทดสอบที่มีความหมาย
  2. จากนั้นคุณสามารถเพิ่มการตรวจสอบโค้ดของการทดสอบเหล่านั้นโดยผู้เขียนโค้ดที่จะทดสอบ

ข้อเสียฉันพบ:

  1. ข้อเสนอแนะวนซ้ำระหว่างการเขียนโค้ดและการทดสอบเพิ่มขึ้น

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


3
คุณไม่ได้พูดถึงว่าการทดสอบแพนี้จะมากกว่าและมากกว่าการทดสอบที่ควรเกิดขึ้นในระหว่างการพัฒนาหรือในตำแหน่ง
Robbie Dee

3
มันจะเป็นประโยชน์ แต่ difficuilt ค่อนข้างเขียน unittest (การทดสอบใน isolotaion) ถ้า "เราไม่ได้ทำ TDD" เพราะไม่ใช่ tdd-code มักจะยากที่จะแยก การเขียนการทดสอบการยอมรับและ / หรือการทดสอบการรวมจะแตกต่างกันและ / หรือบอบบางหากคุณไม่ได้มีเลเยอร์ abstraction layer ฐานข้อมูล (repository api) ที่ช่วยให้คุณสามารถกำหนดเงื่อนไขล่วงหน้าที่ทำซ้ำได้และไม่เปราะบาง
k3b

4
@JoulinRouge: TDD ช่วยด้วย เนื่องจากไม่มีรหัสคุณจึงไม่สามารถปรับแต่งการทดสอบให้เข้ากับรหัสของคุณได้
Jörg W Mittag

6
ดูเหมือนว่าจะเป็นการทบทวนรหัสแบบยาวจริงๆ
เดวิดบอกว่า Reinstate Monica

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

คำตอบ:


7

มันจะไม่เป็นประโยชน์ในการเขียนการทดสอบในระหว่างการตรวจสอบรหัสโดยคนที่ทำการตรวจสอบ?

ฉันพบว่าช่วงเวลาที่ดีในการเขียนการทดสอบคือเมื่อคุณตระหนักว่าคุณต้องการการทดสอบสำหรับสถานการณ์

การสลับงานสำหรับคอมพิวเตอร์มีราคาแพง - ยิ่งกว่านั้นมากสำหรับมนุษย์

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

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

สมมติว่าเราไม่ทำ TDD?

แม้ว่าคุณจะฝึก TDD ถ้าคุณรู้ว่าคุณต้องทำการทดสอบในขณะที่ทำการตรวจสอบโค้ดสิ่งที่คุณไม่มีอยู่ทำไมไม่ลองเขียนการทดสอบแล้วล่ะก็

ข้อดี

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

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

คำเตือน

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


22

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

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

นี่คือชัยชนะทั้งหมดในหนังสือของฉัน


5
มันเกือบจะเหมือนคุณมีประสบการณ์ในการตรวจสอบรหัส ...
syb0rg

ไม่ทราบว่าคุณกำลังพูดถึง @ syb0rg ... คุณไม่สามารถพิสูจน์ได้ =;) -
RubberDuck


2
นอกจากนี้กรณีทดสอบเป็นเพียงเกี่ยวกับวิธีที่คลุมเครืออย่างน้อยในการอธิบายข้อบกพร่องที่พบในการตรวจสอบ :-)
สตีฟเจสซอพ

1
@ syb0rg Rubber Duck ช่วยให้โปรแกรมเมอร์หลายพันหรือหลายล้านคนแก้ไขรหัสได้ ใครมีคุณสมบัติในการตรวจสอบโค้ดได้ดีกว่าใครที่เคยเห็นมาก
jpmc26

18

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

การเขียนการทดสอบในระหว่างการตรวจสอบรหัสจะประสบปัญหาเดียวกันกับการทดสอบด้วยตนเองแบบดั้งเดิม - ความเข้าใจในกฎเกณฑ์ทางธุรกิจอาจแตกต่างกันไปจากนักพัฒนาถึงผู้พัฒนาเช่นเดียวกับความขยัน

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


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

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

ปัญหานี้เรียกว่า "การตั้งค่าแบบอคติ"
ArTs

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

1
@ RobbieDee หากผู้รับความผิดมีความสำคัญจริง ๆ คุณมีสภาพแวดล้อมการพัฒนาที่ไม่ดีต่อสุขภาพ นี่แย่กว่าการทดสอบสองสามครั้งที่จะมีประโยชน์
jpmc26

5

ฉันเห็นด้วยกับคำตอบของ @ RobbieDee แต่ฉันมีเพิ่มอีกเล็กน้อย

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

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

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

OP เพิ่มการแก้ไขโดยจัดวางรายละเอียดเพิ่มเติมว่านี่เป็นคุณลักษณะที่ยากหรืออัลกอริทึมหนัก

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

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

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


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

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

@Encaitar ฉันเห็นด้วยนี้ดูเหมือนว่าจะเป็นช่วงเวลาที่ยิ่งใหญ่ซึ่งอาจจะไม่ทำให้ทุกอย่างดีขึ้น ร้อยและสิ่งที่ ...
sara

3

เช่นเดียวกับที่คุณพูดถ้าคุณใช้ทีม TDD สิ่งนี้จะถูกพิจารณาเนื่องจากรหัสควรได้รับการทดสอบแล้ว

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

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

แต่ใช่แล้วโดยรวมฉันแนะนำให้คุณเขียนแบบทดสอบพร้อมรหัสของคุณแล้วตรวจสอบทั้งหมดในครั้งเดียว


2

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

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

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

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

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


2

ไม่ไม่ทำ คุณจะทำให้พวกเขาคิดว่า TDD น่ากลัว

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

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

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

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


1

การทดสอบหน่วยในระหว่างการตรวจสอบรหัสเป็นการทดแทนที่ไม่ดีสำหรับการทดสอบหน่วยในระหว่างการพัฒนา

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

นี่คือเหตุผล

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

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

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

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

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

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

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

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

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

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

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


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

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

รีวิวเป็นเวลาที่ดีที่จะจุดกรณีมุม และหากผู้ตรวจสอบสามารถกระโดดเข้ามาและเขียนบททดสอบสำหรับกรณีมุมที่เธอพบแล้วเฮ้ - ดีกว่า! แต่โดยทั่วไปแล้วสมมติว่าผู้ตรวจทานสามารถเขียนแบบทดสอบที่ผู้พัฒนาไม่ได้ฟังดูเหมือนเป็นความคิดที่แย่มาก

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