13

ฉันกำลังทดลองกับการพัฒนาโดยใช้การทดสอบและฉันพบว่าฉันมักจะเกิดสถานการณ์ต่อไปนี้:

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

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

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

ฉันควรทำอย่างไรในกรณีเช่นนี้? TDD มีคำแนะนำใด ๆ หรือไม่?

language-agnostic tdd

— liori
แหล่งที่มา

9

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

— Michael Brown
แหล่งที่มา

การทดสอบของฉันมักไม่มีความรู้เกี่ยวกับวิธีการที่ควรทำภายใน (เช่นใช้ API ระดับต่ำกว่าที่เรียก) ฉันควรจะปรับการทดสอบเพื่อเยาะเย้ยสิ่งที่ฉันต้องการในรหัสทดสอบหรือไม่

— liori

2

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

— Mchl

1

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

— Michael Brown

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

— liori

1

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

— Michael Brown

4

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

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

การทดสอบอื่น ๆ ที่กำหนดเป้าหมายรหัสที่อาศัยฟังก์ชันใหม่สามารถปิดใช้งานชั่วคราวเนื่องจากไม่เกี่ยวข้องในจุดนี้เช่น ในกรณีของคุณปิดใช้งานการทดสอบ X จนกว่าคุณจะใช้ Y เป็นต้น

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

— ratkok
แหล่งที่มา

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

— liori

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

— ratkok

3

หยุด

Offhand ดูเหมือนว่าอาจมีสองประเด็นแยกกันที่นี่:

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

สำหรับ # 1 หยุดกลับไปและอัปเดตเรื่องราวและสถานการณ์การทดสอบแล้วเริ่มต้นใหม่ด้วยสถานการณ์อื่น

สำหรับ # 2 หยุดและจำไว้ว่าคุณกำลังทดสอบคุณสมบัติไม่ใช่หน่วยดังนั้นใช้ mocks เพื่อปัดเงาอินเทอร์เฟซอื่น ๆ และ / หรือใช้รหัสเพิ่มเติมเพื่อสร้างการทดสอบผ่านโดยไม่ต้องเพิ่มสถานการณ์การทดสอบใหม่ สิ่งนี้จะถือว่าคุณไม่ได้พลาดสถานการณ์การทดสอบ แต่กลับเป็น - และนี่เป็นเรื่องปกติ - การทดสอบหน่วยและ TDD ที่ทำให้สับสน

— สตีเว่นเอ. โลว์
แหล่งที่มา

ฉันชอบคำตอบของคุณมันจะเป็นการดีกว่าที่จะอธิบายว่าเกิดอะไรขึ้น

— maple_shaft

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

— maple_shaft

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

— Steven A. Lowe

0

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

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

แบบเดิม

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

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

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

— maple_shaft
แหล่งที่มา

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

— liori

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

— maple_shaft

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

— liori

TDD เป็นวิธีการสำหรับการทดสอบและพัฒนาหน่วย มันจะสมเหตุสมผลไหมที่จะทำ TDD สำหรับ Code Review? TDD เหมาะสมกับการออกแบบเขียนข้อกำหนดทางเทคนิคหรือไวท์บอร์ดหรือไม่? การสร้างต้นแบบเป็นหน้าที่ของตัวเองซึ่งเป็นประเภทของการพัฒนาเชิงสำรวจเพื่อการวิจัยการพิสูจน์แนวคิดและการศึกษา

— maple_shaft

1

TDD ทำให้สมบูรณ์แบบที่เหมาะสมสำหรับการสร้างต้นแบบ ช่วยให้คุณสามารถเปิดเผยสิ่งต่าง ๆ ของคุณได้อย่างรวดเร็ว (วัตถุ, ฟังก์ชั่น, API, โปรแกรมทั้งหมด) ในรูปแบบของชุดข้อกำหนดที่ทำซ้ำได้และปฏิบัติการได้ ทำตัวเองให้เป็นที่โปรดปรานและอ่านGrowing Object Oriented Software ที่แนะนำโดยการทดสอบ ; มันจะนำคุณไปทีละขั้นตอนผ่านการสร้างแอปพลิเคชันทั้งหมด (รวมถึงการรวม) ในลักษณะการทดสอบครั้งแรก

— Frank Shearar

0

มันขึ้นอยู่กับชนิดของการทดสอบการเขียนของคุณในขณะที่ทำ TDD

รุ่นคลาสสิกคือการเขียนการทดสอบหน่วยและใช้ประโยชน์จาก mocks หรือต้นขั้วเพื่อแยกการทดสอบจากรหัส "หน่วย" อื่น ๆ

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

— dietbuddha
แหล่งที่มา

TDD การทดสอบใหม่ในขณะที่ยังไม่มีการใช้งาน

หยุด