คำถามติดแท็ก tdd

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

47 development-process  tdd 

เป็นไปได้ที่จะเรียกตัวเองอย่างถูกต้อง (หรือทีมของคุณ) "ว่องไว" ถ้าคุณไม่ทำ TDD (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ)?

45 agile  tdd 

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

44 project-management  management  unit-testing  tdd 

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

41 testing  tdd 

เมื่อทำการ Red, Green & Refactor cycle เราควรเขียนโค้ดขั้นต่ำเพื่อผ่านการทดสอบ นี่คือวิธีที่ฉันได้รับการสอนเกี่ยวกับ TDD และวิธีที่หนังสือเกือบทั้งหมดบรรยายกระบวนการ แต่สิ่งที่เกี่ยวกับการเข้าสู่ระบบ? จริงๆแล้วฉันไม่ค่อยได้ใช้การบันทึกในแอพพลิเคชั่นเว้นแต่มีบางสิ่งที่ซับซ้อนจริงๆที่เกิดขึ้นอย่างไรก็ตามฉันได้เห็นโพสต์มากมายที่พูดถึงความสำคัญของการบันทึกที่เหมาะสม ดังนั้นนอกเหนือจากการบันทึกข้อยกเว้นฉันไม่สามารถพิสูจน์ความสำคัญที่แท้จริงของการบันทึกในแอปพลิเคชันที่ผ่านการทดสอบที่เหมาะสม (การทดสอบหน่วย / การรวม / การยอมรับ) ดังนั้นคำถามของฉันคือ: เราจำเป็นต้องเข้าสู่ระบบหากเรากำลังทำ TDD อยู่หรือไม่? การทดสอบที่ล้มเหลวจะไม่เปิดเผยว่ามีอะไรผิดปกติกับแอปพลิเคชันหรือไม่ เราควรเพิ่มการทดสอบสำหรับกระบวนการบันทึกในแต่ละวิธีในแต่ละคลาสหรือไม่ หากระดับการบันทึกบางส่วนถูกปิดใช้งานในสภาพแวดล้อมการผลิตเช่นนั้นจะไม่แนะนำการพึ่งพาระหว่างการทดสอบและสภาพแวดล้อมหรือไม่? ผู้คนพูดถึงวิธีที่ง่ายในการดีบัก แต่หนึ่งในข้อดีหลักเกี่ยวกับ TDD คือฉันมักจะรู้ว่ามีอะไรผิดปกติเนื่องจากการทดสอบที่ล้มเหลว มีบางอย่างที่ฉันพลาดไปไหม

40 design  object-oriented  unit-testing  tdd  logging 

เรามาถึงจุดที่โครงการของเราซึ่งเรามีการทดสอบเกือบหนึ่งพันครั้งและผู้คนหยุดทำงานก่อนที่จะทำการเช็คอินเพราะมันใช้เวลานานมาก อย่างดีที่สุดพวกเขาเรียกใช้การทดสอบที่เกี่ยวข้องกับชิ้นส่วนของรหัสที่พวกเขาเปลี่ยนแปลงและที่เลวร้ายที่สุดพวกเขาเพียงตรวจสอบโดยไม่ต้องทดสอบ ฉันเชื่อว่าปัญหานี้เกิดจากความจริงที่ว่าโซลูชันเพิ่มขึ้นถึง 120 โครงการ (เรามักจะทำโครงการขนาดเล็กมากและนี่เป็นเพียงครั้งที่สองที่เราทำ TDD อย่างถูกต้อง) และเวลาสร้าง + ทดสอบเพิ่มขึ้นประมาณสองถึงสามนาที บนเครื่องที่น้อยกว่า เราจะลดระยะเวลาในการทดสอบได้อย่างไร มีเทคนิคไหม? แกล้งทำมากขึ้น? แกล้งทำน้อยลงหรือไม่ บางทีการทดสอบการรวมที่ใหญ่กว่านั้นไม่ควรทำงานโดยอัตโนมัติเมื่อทำการทดสอบทั้งหมดใช่ไหม แก้ไข:เพื่อเป็นการตอบสนองต่อคำตอบหลาย ๆ คำเราใช้ CI และ build server อยู่แล้วนี่คือวิธีที่ฉันรู้ว่าการทดสอบล้มเหลว ปัญหา (จริง ๆ แล้วเป็นอาการ) คือเราได้รับข้อความเกี่ยวกับงานสร้างที่ล้มเหลว ใช้การทดสอบบางส่วนเป็นสิ่งที่คนส่วนใหญ่ทำ แต่ไม่ใช่ทั้งหมด และเกี่ยวกับการทดสอบพวกเขาทำได้ค่อนข้างดีพวกเขาใช้ของปลอมสำหรับทุกสิ่งและไม่มี IO เลย

40 c#  unit-testing  tdd  nunit 

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

38 tdd  integration-tests 

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

37 unit-testing  tdd 

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

37 tdd  refactoring 

วันนี้เรากำลังฝึกอบรม TDD และพบประเด็นต่อไปนี้ของความเข้าใจผิด งานสำหรับอินพุต "1,2" ผลรวมของตัวเลขซึ่งคือ 3 สิ่งที่ฉันเขียน (ใน C #) คือ: numbers = input.Split(','); return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct แต่คนอื่นชอบที่จะทำอย่างอื่น ก่อนอื่นสำหรับการป้อน "1,2" พวกเขาได้เพิ่มรหัสต่อไปนี้: if (input == "1,2") return 3; จากนั้นพวกเขาแนะนำการทดสอบอีกหนึ่งครั้งสำหรับอินพุต "4,5" และการใช้งานที่เปลี่ยนแปลง: if (input == "1,2") return 3; else if …

37 testing  tdd 

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

37 java  c#  open-source  c++  tdd 

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

37 unit-testing  tdd 

พิจารณาสิ่งนี้: public function polynominal($a, $b, $c, $d) { return $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d; } สมมติว่าคุณเขียนการทดสอบต่าง ๆ สำหรับฟังก์ชั่นด้านบนและพิสูจน์ตัวเองและคนอื่น ๆ ว่า "ใช้งานได้" ทำไมไม่ลองลบการทดสอบเหล่านั้นออกและใช้ชีวิตอย่างมีความสุขตลอดไป ประเด็นของฉันคือฟังก์ชั่นบางอย่างไม่จำเป็นต้องมีการทดสอบอย่างต่อเนื่องหลังจากที่พวกเขาได้รับการพิสูจน์แล้วว่าทำงานได้ ฉันกำลังมองหาตัวนับคะแนนที่บอกว่าใช่ฟังก์ชั่นเหล่านี้ยังต้องได้รับการทดสอบเพราะ: ... หรือว่าใช่สิ่งเหล่านี้ไม่จำเป็นต้องผ่านการทดสอบ ...

36 php  unit-testing  testing  tdd 

สมมติว่าคุณกำลังเขียนสไตล์เกม TDT ของ Yahtzee คุณต้องการทดสอบส่วนของรหัสที่กำหนดว่าชุดแม่พิมพ์ห้าม้วนเป็นบ้านเต็มหรือไม่ เท่าที่ฉันรู้เมื่อทำ TDD คุณทำตามหลักการเหล่านี้: เขียนแบบทดสอบก่อน เขียนสิ่งที่ง่ายที่สุดที่เป็นไปได้ ปรับแต่งและ refactor ดังนั้นการทดสอบครั้งแรกอาจมีลักษณะเช่นนี้: public void Returns_true_when_roll_is_full_house() { FullHouseTester sut = new FullHouseTester(); var actual = sut.IsFullHouse(1, 1, 1, 2, 2); Assert.IsTrue(actual); } เมื่อทำตาม "เขียนสิ่งที่ง่ายที่สุดที่เป็นไปได้" คุณควรเขียนIsFullHouseวิธีดังนี้: public bool IsFullHouse(int roll1, int roll2, int roll3, int roll4, int roll5) { if (roll1 …

36 unit-testing  tdd 

ฉันไม่ได้ใหม่ในการเขียนโปรแกรม ฉันได้รับการเข้ารหัส (อย่างจริงจัง) มานานกว่า 15 ปีแล้ว ฉันมักจะมีการทดสอบรหัสของฉัน อย่างไรก็ตามในช่วงไม่กี่เดือนที่ผ่านมาผมได้รับการเรียนรู้การออกแบบการทดสอบขับเคลื่อนการพัฒนา / (TDD) โดยใช้Ruby on Rails จนถึงตอนนี้ฉันไม่เห็นประโยชน์ ฉันเห็นประโยชน์บางอย่างในการเขียนข้อสอบสำหรับบางสิ่ง แต่มีน้อยมาก และในขณะที่ฉันชอบความคิดในการเขียนการทดสอบครั้งแรกฉันพบว่าฉันใช้เวลามากขึ้นในการพยายามดีบั๊กการทดสอบเพื่อให้พวกเขาพูดในสิ่งที่ฉันหมายถึงจริงๆมากกว่าการดีบักรหัสจริง อาจเป็นเพราะรหัสทดสอบมักจะซับซ้อนกว่ารหัสที่ใช้ทดสอบ ฉันหวังว่านี่เป็นเพียงประสบการณ์ที่ไม่มีเครื่องมือที่มีอยู่ ( RSpecในกรณีนี้) ฉันต้องบอกว่า ณ จุดนี้ระดับของความคับข้องใจกับการขาดประสิทธิภาพที่น่าผิดหวังนั้นเกินกว่าจะยอมรับไม่ได้ จนถึงตอนนี้สิ่งเดียวที่ฉันเห็นจาก TDD คือไลบรารีที่กำลังเติบโตของไฟล์ RSpec ที่ทำหน้าที่เป็นแม่แบบสำหรับโครงการ / ไฟล์อื่น ๆ ซึ่งไม่มีประโยชน์มากขึ้นอาจมีประโยชน์น้อยกว่าไฟล์รหัสโครงการจริง ในการอ่านวรรณกรรมที่มีอยู่ฉันสังเกตเห็นว่า TDD ดูเหมือนจะเป็นช่วงเวลาที่ยิ่งใหญ่ แต่ก็สิ้นผลไปในที่สุด ฉันแค่สงสัยว่ามีตัวอย่างของโลกแห่งความจริงหรือไม่? ความคับข้องใจครั้งใหญ่ครั้งนี้เกิดขึ้นในโลกแห่งความเป็นจริงหรือไม่? ฉันหวังว่าฉันจะไม่พลาดคำถามนี้ในที่อื่น ฉันค้นหา แต่คำถาม / คำตอบทั้งหมดมีอายุหลายปี ณ จุดนี้ มันเป็นโอกาสที่หายากเมื่อฉันพบนักพัฒนาที่จะพูดอะไรที่ไม่ดีเกี่ยวกับ TDD ซึ่งเป็นสาเหตุที่ฉันใช้เวลากับสิ่งนี้มากเท่าที่ฉันมี อย่างไรก็ตามฉันสังเกตเห็นว่าไม่มีใครที่ดูเหมือนจะชี้เฉพาะตัวอย่างในโลกแห่งความเป็นจริง …

36 ruby-on-rails  unit-testing  tdd