การทดสอบหน่วยช่วยการออกแบบได้อย่างไร


43

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

นั่นไม่เหมือนกับคำถามที่คุณทำเครื่องหมายว่าซ้ำกันฉันจะสนใจตัวอย่างจริง ๆ ว่ามันช่วยได้อย่างไรไม่ใช่แค่ทฤษฎีที่บอกว่า "ช่วยได้" ฉันชอบคำตอบด้านล่างและความคิดเห็น แต่ฉันต้องการเรียนรู้เพิ่มเติม



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

4
@ เพียงแค่ทำการทดสอบหน่วยไม่ได้บอกเป็นนัยว่า TDD เป็นคำถามที่แตกต่างโดยอัตโนมัติ
Joppe

11
"การทดสอบหน่วย (การตรวจสอบความถูกต้องของค่าในฟิลด์)" - คุณดูเหมือนว่ากำลังทำการทดสอบหน่วยกับการตรวจสอบอินพุต
jonrsharpe

1
@ jonrsharpe เนื่องจากว่ามันเป็นรหัสในการแยกวิเคราะห์ไฟล์ CSV เขาอาจจะพูดถึงการทดสอบหน่วยจริงที่ตรวจสอบว่าสตริง CSV บางอย่างให้ผลลัพธ์ที่คาดหวัง
JollyJoker

คำตอบ:


3

ไม่เพียง แต่การทดสอบหน่วยอำนวยความสะดวกในการออกแบบ แต่ยังเป็นหนึ่งในผลประโยชน์ที่สำคัญของพวกเขา

การเขียนไดรฟ์ทดสอบตัวแรกนั้นมีความเป็นโมดูลและโครงสร้างโค้ดที่สะอาด

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

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

จากนั้นเมื่อหน่วยนี้ทำงานตามที่ระบุไว้คุณจะไปยังการเขียนการพึ่งพา (สำหรับxและy) ที่คุณค้นพบ

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

การทดสอบการเขียนในภายหลังจะบอกคุณเมื่อรหัสของคุณมีโครงสร้างไม่ดี

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

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

เมื่อสถานการณ์ของคุณกลายเป็นความซับซ้อนมากเกินไป ( "ถ้าxและyและzแล้ว ...") เพราะคุณจะต้องมากขึ้นนามธรรมคุณรู้ว่าคุณมีการปรับปรุงเพื่อให้ในรหัสของคุณ

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

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


@SSECommunity: เพียง 2 upvotes ณ วันนี้คำตอบนี้ง่ายมากที่จะมองข้าม ฉันขอแนะนำ Talk by Michael Feathers ที่มีการเชื่อมโยงในคำตอบนี้
displayName

103

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

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


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

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

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

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

2
@ user949300 - ตัวอย่างคลาสสิกที่ฉันมีอยู่ในใจที่นี่คือพื้นที่เก็บข้อมูลที่ต้องการ connString สมมติว่าคุณเปิดเผยว่าเป็นคุณสมบัติเขียนได้สาธารณะและต้องตั้งค่าหลังจากที่คุณใหม่ () Repository แนวคิดก็คือหลังจากครั้งที่ 5 หรือ 6 คุณได้ทำการทดสอบที่ลืมที่จะทำตามขั้นตอนนั้น - และทำให้เกิดปัญหา - คุณจะต้อง "เป็นธรรมชาติ" ต่อการบังคับให้ connString เป็นคลาสที่ไม่เปลี่ยนแปลง - ส่งผ่านคอนสตรัคเตอร์ API ดีขึ้นและทำให้มีโอกาสมากขึ้นที่รหัสการผลิตสามารถเขียนได้เพื่อหลีกเลี่ยงกับดักนี้ มันไม่ได้รับประกัน แต่มันจะช่วยได้ imo
Stephen Byrne

31

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

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

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

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


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

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

@AntP ใช่นี่เป็นส่วนหนึ่งของการออกแบบ API
Thorbjørn Ravn Andersen

@JuanMendes นี่ไม่ใช่เรื่องแปลกและการทดสอบเหล่านั้นจะต้องมีการเปลี่ยนแปลงเช่นเดียวกับรหัสอื่น ๆ เมื่อคุณเปลี่ยนข้อกำหนด IDE ที่ดีจะช่วยให้คุณปรับโครงสร้างชั้นเรียนโดยเป็นส่วนหนึ่งของงานที่ทำโดยอัตโนมัติเมื่อคุณเปลี่ยนลายเซ็นของวิธีการเป็นต้น
Thorbjørn Ravn Andersen

@JuanMendes ถ้าคุณเขียนแบบทดสอบที่ดีและหน่วยเล็ก ๆ ผลกระทบของเอฟเฟกต์ที่คุณอธิบายมีน้อยมากในทางปฏิบัติ
Ant P

6

ฉันเห็นด้วย 100% ว่าการทดสอบหน่วยช่วย "ช่วยให้เราปรับแต่งการออกแบบและการรีแฟคเตอร์ของสิ่งต่าง ๆ "

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

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

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


พารามิเตอร์วิธีการที่ยาวจำนวนมากคือกลิ่นรหัสและข้อบกพร่องในการออกแบบ
Sufian

5

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

เมื่อโปรแกรมได้รับการพัฒนา (พร้อมการทดสอบหน่วย) เนื่องจากข้อผิดพลาดถูกเปิดเผยคุณสามารถเพิ่มการทดสอบเพื่อยืนยันว่าข้อบกพร่องได้รับการแก้ไขแล้ว

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

ฉันมักจะเป็นคนขี้แพ้น้อยกว่าเพื่อนร่วมงานบางคนของฉันเพราะฉันไม่สนใจว่าจะเขียนรหัสก่อนหรือเขียนข้อสอบก่อน


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

5

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

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

ในอีกระดับหนึ่งคุณอาจไม่ต้องการใส่ไฟล์ CSV ทางกายภาพทุกประเภทในโครงการทดสอบของคุณ แต่ทำสิ่งที่อ่านง่ายขึ้นเพียงแค่ประกาศสตริง CSV ขนาดใหญ่ในการทดสอบของคุณเพื่อปรับปรุงการอ่านและความตั้งใจในการทดสอบ สิ่งนี้จะนำคุณไปสู่การแยกวิเคราะห์ parser ของคุณจาก I / O ใด ๆ ที่คุณทำที่อื่น

เป็นเพียงตัวอย่างพื้นฐานเริ่มฝึกมันคุณจะรู้สึกถึงเวทย์มนตร์ในบางจุด (ฉันมี)


4

กล่าวง่ายๆคือการเขียนการทดสอบหน่วยช่วยเปิดเผยข้อบกพร่องในรหัสของคุณ

คู่มือที่น่าตื่นเต้นนี้ในการเขียนรหัสที่ทดสอบได้เขียนโดย Jonathan Wolter, Russ Ruffer และMiško Hevery ประกอบด้วยตัวอย่างมากมายว่าข้อบกพร่องของรหัสที่เกิดขึ้นกับการยับยั้งการทดสอบยังป้องกันการใช้ซ้ำได้ง่ายและความยืดหยุ่นของรหัสเดียวกัน ดังนั้นหากรหัสของคุณสามารถทดสอบได้จะง่ายต่อการใช้งาน "คุณธรรม" ส่วนใหญ่เป็นเคล็ดลับง่ายๆที่น่าขันที่ปรับปรุงการออกแบบโค้ดอย่างมากมาย ( Dependency Injection FTW)

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

public OopsIHardcoded {

   Cache cacheOfExpensiveComputations;

   OopsIHardcoded() {
       this.cacheOfExpensiveComputation = buildBigCache();
   }

   ExpensiveValue computeStuff() {
      //DOES THIS WORK CORRECTLY WHEN CACHE EVICTS DATA?
   }
}

อย่างไรก็ตามเมื่อเราใช้การฉีดพึ่งพามันง่ายกว่าที่จะทดสอบว่าวิธีการ computeStuff ทำงานอย่างถูกต้องเมื่อแคชเริ่ม evicting สิ่ง สิ่งที่เราทำคือสร้างการทดสอบที่เราเรียกว่าnew HereIUseDI(buildSmallCache()); ประกาศเรามีการควบคุมวัตถุที่เหมาะสมยิ่งขึ้นและจ่ายเงินปันผลทันที

public HereIUseDI {

   Cache cacheOfExpensiveComputations;

   HereIUseDI(Cache cache) {
       this.cacheOfExpensiveComputation = cache;
   }

   ExpensiveValue computeStuff() {
      //DOES THIS WORK CORRECTLY WHEN CACHE EVICTS DATA?
   }
}

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


2
สุจริตฉันไม่แน่ใจว่าคุณหมายถึงตัวอย่าง วิธีการ computeStuff เกี่ยวข้องกับแคชอย่างไร
John V

1
@ user970696 - ใช่ฉันหมายความว่า "computeStuff ()" ใช้แคช คำถามคือ "ไม่ computeStuff () ทำงานอย่างถูกต้องตลอดเวลา (ซึ่งขึ้นอยู่กับสถานะของแคช)" ดังนั้นจึงเป็นการยากที่จะยืนยันว่า computeStuff () ทำสิ่งที่คุณต้องการสำหรับสถานะแคชที่เป็นไปได้ทั้งหมดหากคุณไม่สามารถตั้งค่า / สร้างแคชเนื่องจากคุณ hardcoded บรรทัด "cacheOfExpensiveComputation = buildBigCache ();" (ตรงข้ามกับการส่งผ่านแคชโดยตรงผ่านทางคอนสตรัคท์)
Ivan

0

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

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

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

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

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


-2

การทดสอบหน่วยสามารถช่วยในการปรับโครงสร้างใหม่เมื่อรหัสใหม่ผ่านการทดสอบเก่าทั้งหมด

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

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


1
เรื่องนี้เป็นเรื่องจริง แต่ก็มีประโยชน์ด้านการบำรุงรักษามากกว่าผลกระทบโดยตรงต่อคุณภาพการออกแบบรหัส
Ant P

@AntP, OP ถามเกี่ยวกับการเปลี่ยนโครงสร้างและการทดสอบหน่วย
om

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

-3

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


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