วิธีการ: การเขียนการทดสอบหน่วยสำหรับผู้พัฒนารายอื่น


28

ฉันคิดถึงการพัฒนาซอฟต์แวร์และการเขียนการทดสอบหน่วย ฉันมีความคิดดังต่อไปนี้:

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

ฉันคิดว่าความคิดนี้มี upside:

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

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

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

PS ฉันไม่ใช่ผู้จัดการโครงการมืออาชีพ แต่ฉันรู้บางอย่างเกี่ยวกับกระบวนการพัฒนาโครงการและรู้วิธีการที่ได้รับความนิยมน้อยที่สุด - แต่แนวคิดนี้ไม่คุ้นเคยกับฉัน


17
คุณกำลังอธิบาย QA ดาวน์สตรีมที่ระดับหน่วย หากคุณมีคนกำลังทำงานบางอย่างอยู่ลองเขียนโปรแกรมจับคู่กับ TDD จริงหรือไม่?
jonrsharpe

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

14
การวิจารณ์นั้นไม่สมเหตุสมผลและข้อเสนอแนะของคุณไม่สามารถแก้ปัญหานั้นได้
jonrsharpe

5
@ franiis ฉันเห็นเพื่อนร่วมงานเขียนassert trueเป็นแบบทดสอบและเรียกมันวันละครั้งเพราะการทดสอบทุกครั้งผ่านไป ขั้นตอนสำคัญหนึ่งที่ขาดหายไป: การทดสอบควรล้มเหลวก่อนและควรผ่านการเปลี่ยนรหัสไม่ใช่การทดสอบ
Eric Duminil

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

คำตอบ:


30

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

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

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

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


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

จากประสบการณ์ของฉันการทำใหม่มีค่ามากกว่าประโยชน์ของวิธีนี้ ฉันควรมีการแลกเปลี่ยนหน้าที่เหล่านี้โดยใช้ 'ping-pong' หรือวิธีอื่น
neontapir

3
การฝึกเขียนโปรแกรมคู่ไม่ได้เกี่ยวกับความเร็ว แต่คุณภาพ Pair TDD เป็นเรื่องเกี่ยวกับคุณภาพที่นำมาซึ่งความรวดเร็วซึ่งทำให้ต้นทุนการพัฒนาลดลง มันเป็นเพียงอุตสาหกรรมของเราเรียนรู้สิ่งที่ masons รู้จักสำหรับ millenials: ผนังของคุณจะถูกสร้างขึ้นได้ดีขึ้นในเวลาที่น้อยลงด้วยความพยายามน้อยลงและค่าใช้จ่ายน้อยลงถ้าคุณเสียเวลาตั้งค่าสายสตริงเป็นครั้งแรกและกฎของ mason คุณวางอิฐของคุณและพยายามปรับหลังจากนั้นด้วยระดับจิตวิญญาณและตะลุมพุก และรับความช่วยเหลือจากสิ่งต่าง ๆ
Laurent LA RIZZA

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

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

37

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

คือคุณต้องสามารถฉีด mocks แยกบิตที่คุณต้องการทดสอบสถานะการเข้าถึงที่เปลี่ยนแปลงและต้องการการยืนยันเป็นต้น

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


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

1
@ franiis แน่ใจว่าปัญหาหลักไม่ใช่ว่าคุณเขียนการทดสอบหลังจากนั้นมันเป็นการรวมกันของการทำเช่นนั้นและไม่ใช่บุคคลเดียวกันที่เขียนรหัส
Ewan

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

25
@franiis: "หากการทดสอบไม่ทดสอบบางแง่มุมของรหัสก็อาจถูกละเว้นในรหัส" - นั่นคือประเด็นทั้งหมด การทดสอบเป็นการเข้ารหัสความต้องการในรูปแบบของตัวอย่างที่ปฏิบัติการได้ หากมีการทดสอบสำหรับมันไม่มีแล้วมีความต้องการมันไม่มีและมีควรจะเป็นรหัสสำหรับมันไม่มี
Jörg W Mittag

3
อีกด้านหนึ่งของสิ่งที่ @ JörgWMittagพูดคือ: หากการทดสอบของคุณ "ไม่ทดสอบโค้ดที่สำคัญ" คุณต้องแก้ไขการทดสอบของคุณ สิ่งนี้จะเป็นจริงในระบบของคุณเหมือนกับใน TDD ดั้งเดิม
bta

15

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

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

ดังนั้นใช่มี dev สองเขียนเพิ่มเติมการทดสอบหน่วยทำให้รู้สึก แต่ไม่ได้สำหรับการเขียนการทดสอบหน่วยเฉพาะ


7

ดูเหมือนจะมีความเป็นไปได้สำหรับสถานการณ์ต่อไปนี้ที่จะเกิดขึ้น - ซึ่งทั้งหมดเป็นสิ่งที่ไม่พึงประสงค์:

ความสับสน

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

การต่อสู้

นักพัฒนาซอฟต์แวร์ Aอาจทำโค้ดให้เสร็จและต้องการทดสอบ นักพัฒนา Bอาจมีการพัฒนาและอื่น ๆ อาจเป็นไปได้ที่จะเก็บรหัสไว้เพื่อเข้าร่วมการทดสอบหน่วย

การสลับบริบท

แม้ว่าผู้พัฒนา Bยินดีที่จะระงับการพัฒนาเพื่อทดสอบโค้ดที่เขียนโดยนักพัฒนา Aการเปลี่ยนแปลงของกิจกรรมมีค่าใช้จ่าย


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


4

เมื่อใช้ร่วมกับการเขียนโปรแกรมคู่และTDDสิ่งนี้เรียกว่ารูปแบบ Ping Pong :

  • A เขียนการทดสอบใหม่และเห็นว่าการทดสอบล้มเหลว
  • B ใช้รหัสที่จำเป็นในการผ่านการทดสอบ
  • B เขียนการทดสอบถัดไปและเห็นว่ามันล้มเหลว
  • ใช้รหัสที่จำเป็นในการผ่านการทดสอบ

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

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

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


3

ฉันมางานปาร์ตี้สายนี้ แต่ฉันคิดว่าฉันมีอะไรที่จะเพิ่ม

มันได้อธิบายไว้แล้วว่าเป็นวิธีการที่ไม่รู้จักกับฉันและใช้ในการพัฒนาซอฟต์แวร์หรือไม่?

คุณจะอธิบายการทดสอบ Peer

สมมติว่าเรามีคู่นักพัฒนา

อ่าการจัดวางคู่ที่ดี

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

นั่นไม่ใช่การเขียนโปรแกรมคู่

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

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

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

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

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

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


ขอบคุณสำหรับการตอบสนองและชี้ให้ฉันไปที่การทดสอบ Peer (ฉันจะอ่านเกี่ยวกับเรื่องนี้)
franiis

1

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

มีการทดสอบเขียนโดยผู้ที่สามารถดูเพิ่มเติมเกี่ยวกับการนำไปใช้

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

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

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

ทั้งการทดสอบและรหัสมีผู้รับผิดชอบ

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

มีการทดสอบรหัสโดยอย่างน้อยสองคน

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

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

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

Red-green-refactor TDD ( จริง ๆ แล้วเขียนการทดสอบเดียวก่อนที่จะเขียนรหัสการผลิตเรียกใช้มันเห็นมันล้มเหลวแก้ไขรหัสการผลิตเท่านั้นใช้การทดสอบอีกครั้งเห็นมันประสบความสำเร็จและจากนั้น refactoring และไม่ข้ามหรือสลับใด ๆ ขั้นตอนเหล่านี้) และการตรวจสอบโค้ดใช้งานได้


มันจะเร็วกว่า (สมมุติ) เพราะคุณไม่มีคนสองคนที่ทำ "งานเดียวกัน" - พวกเขาแต่ละคนกำลังทำสิ่งของตัวเองและจากนั้นก็สับเปลี่ยนกันไป
Jacob Raihle

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

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

1

ฉันคิดว่าความคิดนี้มี upside:

Le'ts วิ่งผ่านพวกเขาทีละคน

การทดสอบถูกเขียนขึ้นโดยใครบางคนซึ่งสามารถดูเพิ่มเติมเกี่ยวกับการนำไปใช้

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

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

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

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

ทั้งการทดสอบและรหัสมีผู้รับผิดชอบ

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

มีการทดสอบรหัสโดยอย่างน้อยสองคน

พร้อมคู่ TDD ด้วย เมื่อจับคู่ทั้งสองคนต้องยอมรับว่ารหัสที่เขียนนั้นเพียงพอหรือไม่เขียน หากผลการต่อสู้บางคนในทีมมีปัญหาอัตตาผิด

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

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

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

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

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