คุณต้องทำการทดสอบ BDD / TDD จริงๆหรือไม่?

11

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

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

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

ความคิดใด ๆ

unit-testing tdd

— โทมัสแจนสัน
แหล่งที่มา

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

— Macneil

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

— Tomas Jansson

1

@Macneil: นี่เป็นความเข้าใจผิดที่พบบ่อย การทดสอบ TDD ไม่ใช่การทดสอบหน่วย คุณสมบัติการทดสอบ TDD ซึ่งไม่มีการกำหนดขนาด

— Steven A. Lowe

2

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

— Macneil

@ Macneil: "เร็ว" เป็นคำที่เกี่ยวข้อง ชุดทดสอบในโครงการสุดท้ายของฉันดำเนินการในเวลาประมาณ 30 นาที มันแทนที่การทดสอบด้วยตนเอง8 ชั่วโมง นั่นคือ "เร็ว" เพียงพอ!

— Steven A. Lowe

8

คุณกำลังพูดถึง BDD จากมุมมองระดับสูงของการทดสอบ UI ของคุณ การทดสอบในระดับนี้จะดูนุ่มนวลกว่าโค้ดด้านล่าง Javascript / เซิร์ฟเวอร์ของคุณเล็กน้อย

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

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

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

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

— เกร็กเค
แหล่งที่มา

ฉันคิดว่าคุณถูก. สิ่งนี้ทำให้ฉันเมื่อฉันลองทับทิมบนรางในฤดูร้อนนี้พวกเขามีการทดสอบ bdd ที่ผลักดัน UI ซึ่งต่อมาขับเคลื่อนการใช้งานคลาสพื้นฐาน

— Tomas Jansson

17

ใช่ มิฉะนั้นสิ่งที่คุณได้รับคือการทดสอบการพัฒนาขับเคลื่อน

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

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

3

บรรทัดแรกนั้นยอดเยี่ยม

— EpsilonVector

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

— Tomas Jansson

15

หากคุณไม่เขียนข้อสอบก่อนอื่นคุณไม่ได้ผลักดันการพัฒนาผ่านการทดสอบ เอาละคุณไม่ได้ทำการพัฒนาด้วยการทดสอบ!

— Frank Shearar
แหล่งที่มา

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

— bytedev

คุณสามารถแทนที่ "ทดสอบ" ด้วย "พฤติกรรม" ฉันไม่ได้เห็นอะไรเลยที่จะโน้มน้าวฉันว่าในใจมันมีความแตกต่างอย่างมากระหว่าง TDD และ BDD โฟกัสอาจจะ แต่ความคิดหลัก? ไม่ค่อยเท่าไหร่.

— Frank Shearar

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

— ทางเลือก

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

— Frank Shearar

@ FrankShearar ฉันยอมรับว่าไม่ใช่ TDD ตามที่ Kent Beck พูด แต่ฉันไม่สนใจว่าคนสุ่มพูดอะไร เป็นไปได้อย่างสมบูรณ์แบบในการออกแบบรหัสไดรฟ์ผ่านการทดสอบโดยไม่ต้องเขียนการทดสอบก่อน

— ทางเลือก

4

ถ้าคุณต้องการทำงานด้วยวิธีนี้ไปได้เลย แต่มันไม่ใช่การทดสอบพัฒนา

— ดอน Roby
แหล่งที่มา

3

สิ่งที่คุณอธิบายเสียงเหมือนด้านหน้าข้างหน้าการออกแบบวิธีการ แต่น่าเสียดายที่การออกแบบ Front-Ahead คือการแทงเหน็บแนมของ Alex Papadimoulis ด้วยวิธีการที่คล่องตัว

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

ฉันสงสัยว่าคุณรู้บทความใดบ้างที่ต่อสู้กับ FAD ทำให้ debunking stab เหน็บแนมหรือไม่

— CL22

3

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

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

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