คำถามติดแท็ก unit-testing

นี่เป็นสิ่งที่ทำให้ฉันหนักใจอยู่พักหนึ่งแล้ว จริง ๆ แล้วมันคุ้มค่ากับการทดสอบหน่วยลูกค้า API หรือไม่ สมมติว่าคุณกำลังสร้างชั้นเรียนขนาดเล็กเพื่อสรุปการโทรหาสัตว์เลี้ยง REST API Petshop เป็น API ที่ง่ายมากและมีชุดวิธีพื้นฐาน: listProducts() getProductDetails(ProductID) addProduct(...) removeProduct(ProductID) ในการทดสอบสิ่งนี้เราต้องสร้างบริการจำลองหรือตอบกลับ แต่นั่นดูเหมือน overkill; ฉันเข้าใจว่าเราต้องการตรวจสอบให้แน่ใจว่าวิธีการของเราไม่หยุดทำงานผ่านข้อผิดพลาดของ typo / syntax แต่เนื่องจากเรากำลังเขียนฟังก์ชั่นที่เรียกใช้วิธีการทางไกลแล้วเรากำลังสร้างการตอบกลับปลอมจากวิธีการทางไกลเหล่านั้น เป็นการเสียความพยายามและเรากำลังทดสอบบางสิ่งที่ไม่สามารถล้มเหลวได้จริงๆ ที่แย่กว่านั้นหากวิธีการระยะไกลเปลี่ยนการทดสอบหน่วยของเราจะผ่านในขณะที่การใช้การผลิตล้มเหลว ฉันค่อนข้างมั่นใจว่าฉันพลาดอะไรบางอย่างไปหรือฉันมีไม้ผิดหรือฉันไม่ได้เห็นต้นไม้สำหรับต้นไม้ มีคนตั้งฉันให้ถูกทางได้ไหม?

38 unit-testing  api 

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

37 unit-testing  tdd 

ฉันเริ่มเขียนการทดสอบหน่วยสำหรับโครงการปัจจุบันของฉัน ฉันไม่ได้มีประสบการณ์กับมันจริงๆ ฉันต้องการ "รับ" อย่างสมบูรณ์ดังนั้นฉันจึงไม่ใช้เฟรมเวิร์ก IoC หรือไลบรารีที่เยาะเย้ย ฉันสงสัยว่ามีอะไรผิดปกติหรือเปล่ากับการให้อาร์กิวเมนต์ที่เป็นโมฆะแก่ตัวสร้างวัตถุในการทดสอบหน่วย ให้ฉันให้รหัสตัวอย่าง: public class CarRadio {...} public class Motor { public void SetSpeed(float speed){...} } public class Car { public Car(CarRadio carRadio, Motor motor){...} } public class SpeedLimit { public bool IsViolatedBy(Car car){...} } แต่อีกตัวอย่างรหัสรถยนต์ (TM) ได้ลดเหลือเพียงบางส่วนที่สำคัญสำหรับคำถาม ตอนนี้ฉันเขียนการทดสอบแบบนี้: public class SpeedLimitTest { public …

37 unit-testing 

ฉันได้อ่านว่าการใช้ "ใหม่" ในคอนสตรัคเตอร์ (สำหรับวัตถุอื่นที่ไม่ใช่วัตถุที่มีค่าอย่างง่าย) นั้นเป็นวิธีที่ไม่ดีเนื่องจากทำให้การทดสอบหน่วยเป็นไปไม่ได้ เนื่องจากฉันไม่ได้มีประสบการณ์จริงในการทดสอบหน่วยฉันพยายามรวบรวมกฎที่ฉันจะเรียนรู้ก่อน นอกจากนี้นี่เป็นกฎที่ใช้ได้โดยทั่วไปไม่ว่าจะใช้ภาษาใด

37 unit-testing  constructors 

คุณสามารถค้นหารายการบล็อกบทความและเว็บไซต์ที่ไม่สิ้นสุดซึ่งส่งเสริมประโยชน์ของการทดสอบหน่วยซอร์สโค้ดของคุณ เกือบจะรับประกันได้ว่านักพัฒนาที่เขียนโปรแกรมคอมไพเลอร์สำหรับ Java, C ++, C # และภาษาที่พิมพ์อื่น ๆ ใช้การทดสอบหน่วยเพื่อตรวจสอบงานของพวกเขา ดังนั้นทำไมแม้จะมีความนิยมของมันคือการทดสอบขาดจากไวยากรณ์ของภาษาเหล่านี้หรือไม่ Microsoft แนะนำLINQให้กับC #ดังนั้นทำไมพวกเขาจึงไม่สามารถเพิ่มการทดสอบได้อีกด้วย ฉันไม่ต้องการคาดการณ์ว่าการเปลี่ยนแปลงภาษาเหล่านั้นจะเป็นเช่นไร แต่เพื่ออธิบายให้ชัดเจนว่าทำไมพวกเขาถึงไม่เริ่มต้นด้วย เป็นตัวอย่าง: เรารู้ว่าคุณสามารถเขียนforลูปโดยไม่มีไวยากรณ์ของforคำสั่ง คุณสามารถใช้whileหรือif/ gotoงบ มีคนตัดสินใจว่าforข้อความนั้นมีประสิทธิภาพมากกว่าและนำมาใช้เป็นภาษา ทำไมการทดสอบไม่ได้ทำตามวิวัฒนาการของภาษาโปรแกรมเดียวกัน?

37 programming-languages  unit-testing  syntax 

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

37 unit-testing  tdd 

เรากำลังเริ่มต้นผลักดันการครอบคลุมโค้ดในที่ทำงานของฉันและทำให้ฉันคิดว่า .... การครอบคลุมโค้ดมีมากพอเพียงใด เมื่อไหร่ที่คุณจะไปถึงจุดที่จะได้รับผลตอบแทนจากการครอบคลุมโค้ด? อะไรคือจุดหวานระหว่างความครอบคลุมที่ดีและไม่เพียงพอ มันแตกต่างกันไปตามประเภทของโครงการที่คุณทำ (เช่น WPF, WCF, มือถือ, ASP.NET) (นี่คือคลาส C # ที่เรากำลังเขียน)

37 code-quality  unit-testing 

มีคำตอบให้กับคำถามเกี่ยวกับวิธีการเรียนการทดสอบที่เชื่อมต่อกับฐานข้อมูลเช่นมี"เรียนให้บริการทดสอบควรเชื่อมต่อ ..."และ"การทดสอบหน่วย - ฐานข้อมูลแอปพลิเคคู่" ดังนั้นในระยะสั้นสมมติว่าคุณมีคลาส A ที่จำเป็นต้องเชื่อมต่อกับฐานข้อมูล แทนที่จะให้การเชื่อมต่อจริงคุณให้ A พร้อมกับอินเทอร์เฟซที่ A อาจใช้เพื่อเชื่อมต่อ สำหรับการทดสอบคุณใช้อินเทอร์เฟซนี้กับบางสิ่ง - โดยไม่ต้องเชื่อมต่อแน่นอน ถ้าคลาส B สร้างอินสแตนซ์ A ขึ้นมามันจะต้องผ่านการเชื่อมต่อฐานข้อมูล "ของจริง" ไปยัง A แต่นั่นหมายความว่า B เปิดการเชื่อมต่อฐานข้อมูล นั่นหมายถึงการทดสอบ B คุณฉีดการเชื่อมต่อเข้าสู่ B แต่ B นั้นถูกสร้างขึ้นในคลาส C เป็นต้น ดังนั้นที่จุดฉันต้องพูดว่า "ที่นี่ฉันดึงข้อมูลจากฐานข้อมูลและฉันจะไม่เขียนหน่วยทดสอบสำหรับรหัสชิ้นนี้"? ในคำอื่น ๆ : บางแห่งในรหัสในบางชั้นฉันต้องโทรsqlDB.connect()หรือสิ่งที่คล้ายกัน ฉันจะทดสอบคลาสนี้ได้อย่างไร และมันเป็นรหัสเดียวกันกับที่ต้องจัดการกับ GUI หรือระบบไฟล์หรือไม่? ฉันต้องการทดสอบหน่วย การทดสอบประเภทอื่นใดไม่เกี่ยวข้องกับคำถามของฉัน ฉันรู้ว่าฉันจะทดสอบเพียงชั้นเดียวเท่านั้น (ฉันเห็นด้วยกับคุณ Kilian) …

37 database  unit-testing 

ฉันมีคลาสที่ตั้งใจจะสร้างรหัสผ่านแบบสุ่มที่มีความยาวซึ่งก็สุ่ม แต่ จำกัด ให้อยู่ระหว่างระยะเวลาที่กำหนดและความยาวสูงสุด ฉันกำลังสร้างการทดสอบหน่วยและวิ่งเข้าไปในอุปสรรค์เล็ก ๆ น้อย ๆ ที่น่าสนใจกับชั้นเรียนนี้ แนวคิดทั้งหมดที่อยู่เบื้องหลังการทดสอบหน่วยคือควรทำซ้ำได้ หากคุณใช้การทดสอบร้อยครั้งก็ควรให้ผลลัพธ์เดียวกันร้อยครั้ง หากคุณขึ้นอยู่กับทรัพยากรบางอย่างที่อาจมีหรือไม่มีอยู่หรืออาจจะอยู่หรืออาจไม่อยู่ในสถานะเริ่มต้นที่คุณคาดหวังจากนั้นคุณตั้งใจจะจำลองทรัพยากรที่มีปัญหาเพื่อให้แน่ใจว่าการทดสอบของคุณทำซ้ำได้เสมอ แต่สิ่งที่เกี่ยวกับในกรณีที่ SUT ควรจะสร้างผลผลิตไม่แน่นอน? หากฉันแก้ไขความยาวขั้นต่ำและความยาวสูงสุดเป็นค่าเดียวกันฉันสามารถตรวจสอบได้อย่างง่ายดายว่ารหัสผ่านที่สร้างขึ้นนั้นมีความยาวตามที่คาดหวัง แต่ถ้าฉันระบุช่วงของความยาวที่ยอมรับได้ (พูด 15 - 20 ตัวอักษร) ตอนนี้คุณมีปัญหาที่คุณสามารถรันการทดสอบได้ร้อยครั้งและได้รับ 100 ครั้ง แต่ในการวิ่งครั้งที่ 101 คุณอาจได้รับสตริงอักขระ 9 คืน ในกรณีของคลาสรหัสผ่านซึ่งค่อนข้างง่ายที่แกนกลางของมันก็ไม่ควรพิสูจน์ปัญหาใหญ่ แต่มันทำให้ฉันคิดถึงกรณีทั่วไป กลยุทธ์ที่มักได้รับการยอมรับว่าเป็นกลยุทธ์ที่ดีที่สุดเมื่อจัดการกับ SUT ที่สร้างผลลัพธ์ไม่แน่นอนโดยการออกแบบคืออะไร

37 unit-testing  random 

พิจารณาสิ่งนี้: 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 

เมื่อทำการทดสอบ TDD และเขียนการทดสอบหน่วยหนึ่งจะต่อต้านการกระตุ้นให้ "โกง" เมื่อเขียนรหัสซ้ำ "ครั้งแรกของ" การใช้งาน "ที่คุณกำลังทดสอบอยู่ได้อย่างไร ตัวอย่างเช่น: ฉันจะต้องคำนวณแฟคทอเรียลของตัวเลข ฉันเริ่มต้นด้วยการทดสอบหน่วย (ใช้ MSTest) สิ่งที่ชอบ: [TestClass] public class CalculateFactorialTests { [TestMethod] public void CalculateFactorial_5_input_returns_120() { // Arrange var myMath = new MyMath(); // Act long output = myMath.CalculateFactorial(5); // Assert Assert.AreEqual(120, output); } } ฉันเรียกใช้รหัสนี้และมันล้มเหลวเนื่องจากCalculateFactorialวิธีการไม่ได้อยู่ ดังนั้นตอนนี้ฉันเขียนการวนซ้ำครั้งแรกของรหัสเพื่อใช้วิธีการภายใต้การทดสอบการเขียนรหัสขั้นต่ำที่ จำเป็นในการผ่านการทดสอบ สิ่งคือฉันอยากจะเขียนต่อไปนี้: public class MyMath …

36 unit-testing  tdd 

สมมติว่าฉันมีฟังก์ชั่น (เขียนใน Ruby แต่ทุกคนควรเข้าใจได้): def am_I_old_enough?(name = 'filip') person = Person::API.new(name) if person.male? return person.age > 21 else return person.age > 18 end end ในการทดสอบหน่วยฉันจะสร้างการทดสอบสี่แบบเพื่อให้ครอบคลุมทุกสถานการณ์ แต่ละคนจะใช้ล้อเลียนPerson::APIวัตถุที่มีวิธีการที่ค้างอยู่และmale?age ตอนนี้มันมาถึงการเขียนการทดสอบการรวม ฉันถือว่า Person :: API ไม่ควรถูกเยาะเย้ยอีกต่อไป ดังนั้นฉันจะสร้างกรณีทดสอบสี่ชุดให้เหมือนกัน แต่ไม่มีการจำลองวัตถุ Person :: API ถูกต้องไหม ถ้าใช่แล้วประเด็นของการเขียนการทดสอบหน่วยคืออะไรถ้าฉันสามารถเขียนการทดสอบการรวมซึ่งทำให้ฉันมีความมั่นใจมากขึ้น (ขณะที่ฉันทำงานกับวัตถุจริงไม่ใช่ stubs หรือ mocks)

36 unit-testing  testing  ruby  integration-tests 

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

35 unit-testing  integration-tests