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

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

10 unit-testing  testing  game-development 

ฉันเริ่มเขียนรหัส C ++ เพื่อเรียกใช้หุ่นยนต์และฉันไม่ทราบวิธีรวมการทดสอบหน่วยหากฉันสามารถทำได้ ฉันได้รับห้องสมุดที่อนุญาตให้สร้าง "คำสั่ง" สำหรับหุ่นยนต์ซึ่งมีกำหนดและดำเนินการโดยอัตโนมัติ กลไกในการสร้างคำสั่งเหล่านี้เป็นประเภทรองชั้นฐานคำสั่งพวกเขาให้และดำเนินการเสมือนvoid Initialize(), void Execute()และvoid End()วิธีการ ฟังก์ชั่นเหล่านี้ทำงานอย่างหมดจดสำหรับผลข้างเคียงซึ่งทำสิ่งต่าง ๆ กับหุ่นยนต์ (วิ่งมอเตอร์ยืดลูกสูบ ฯลฯ ) ด้วยเหตุนี้ฉันไม่เห็นที่ใดก็ได้ในการแนบการทดสอบหน่วยกับโค้ดขาดการเยาะเย้ยห้องสมุดทั้งหมดเพื่อให้ฉันสามารถตรวจสอบเสมือนก่อนและหลังสถานะของหุ่นยนต์ มีวิธีทดสอบหน่วยที่ไม่เป็นภาระมากเกินไปหรือไม่ แก้ไข ฉันคิดว่าฉันเข้าใจผิดเกี่ยวกับการทำงานของห้องสมุด ห้องสมุดมีส่วนต่อประสานกับหุ่นยนต์เป็นส่วนใหญ่รวมถึงระบบคำสั่ง / การตั้งเวลาดังนั้นมันจึงไม่ง่ายเท่ากับการเยาะเย้ยคลาสฐานคำสั่ง ฉันโชคไม่ดีที่ไม่มีเวลาทำเช่นนั้น

10 c++  unit-testing  side-effect 

ฉันชื่อคำถามล้อเล่นเพราะฉันแน่ใจว่า "มันขึ้นอยู่กับ" แต่ฉันมีคำถามเฉพาะบางอย่าง การทำงานในซอฟต์แวร์ที่มีการพึ่งพาในระดับลึกมาก ๆ ทีมของฉันคุ้นเคยกับการใช้การเยาะเย้ยอย่างกว้างขวางเพื่อแยกโมดูลรหัสแต่ละรายการออกจากการพึ่งพาที่อยู่ด้านล่าง ดังนั้นฉันจึงประหลาดใจที่Roy Osheroveแนะนำในวิดีโอนี้ว่าคุณควรใช้การเยาะเย้ยเพียงบางอย่างเช่น 5% ของเวลา ฉันเดาว่าเรานั่งอยู่ระหว่าง 70-90% ฉันเคยเห็นคำแนะนำที่คล้ายกันเป็นครั้งคราวเช่นกัน ฉันควรกำหนดสิ่งที่ฉันพิจารณาว่าเป็นสองหมวดหมู่ของ "การทดสอบการรวม" ซึ่งแตกต่างกันอย่างมากว่าพวกเขาควรได้รับชื่อต่างกัน: 1) การทดสอบระหว่างกระบวนการซึ่งรวมโมดูลรหัสหลายโมดูลและ 2) การทดสอบนอกกระบวนการ ไปยังฐานข้อมูลระบบไฟล์บริการบนเว็บ ฯลฯ มันเป็นประเภทที่ 1 ที่ฉันกังวลการทดสอบที่รวมโมดูลรหัสหลายโมดูลทั้งหมดในกระบวนการ คำแนะนำของชุมชนส่วนใหญ่ที่ฉันได้อ่านแสดงให้เห็นว่าคุณควรเลือกการทดสอบแบบแยกหน่วยที่ละเอียดและละเอียดจำนวนมากและการทดสอบแบบรวมตั้งแต่ต้นจนจบแบบหยาบจำนวนเล็กน้อยเนื่องจากการทดสอบหน่วยจะให้ข้อเสนอแนะที่แม่นยำกับคุณ อาจมีการสร้างการถดถอย แต่การทดสอบแบบหยาบซึ่งยุ่งยากในการตั้งค่าจริงตรวจสอบการทำงานแบบ end-to-end ของระบบ ได้รับสิ่งนี้ดูเหมือนว่าจำเป็นที่จะต้องใช้การเยาะเย้ยบ่อยครั้งเพื่อแยกรหัสหน่วยแยกเหล่านี้ รับโมเดลวัตถุดังนี้: ... ยังพิจารณาด้วยว่าความลึกของการพึ่งพาแอปพลิเคชันของเรานั้นลึกกว่าที่ฉันจะได้พอดีในภาพนี้เพื่อให้มีหลายเลเยอร์ N ระหว่าง 2-4 เลเยอร์และ 5-13 เลเยอร์ ถ้าฉันต้องการทดสอบการตัดสินใจเชิงตรรกะอย่างง่าย ๆ ในหน่วย # 1 และถ้าการอ้างอิงทุกครั้งถูกสร้างขึ้นในคอนสตรัคเตอร์โค้ดที่ขึ้นอยู่กับมันเช่นนั้นพูด 2 2 3 และ …

10 unit-testing  mocking 

ขณะนี้ฉันกำลัง refactoring ส่วนหนึ่งของ codebase ขนาดใหญ่ที่ไม่มีหน่วยทดสอบใด ๆ ฉันพยายาม refactor code ในแบบที่โง่เง่านั่นคือการพยายามเดาว่าโค้ดกำลังทำอะไรและการเปลี่ยนแปลงใดที่จะไม่เปลี่ยนความหมาย แต่ไม่ประสบความสำเร็จ: มันสุ่มแยกคุณสมบัติรอบ ๆ codebase โปรดทราบว่าการเปลี่ยนโครงสร้างรวมถึงการย้ายรหัส C # ดั้งเดิมไปสู่รูปแบบการทำงานที่มากขึ้น (รหัสดั้งเดิมไม่ได้ใช้คุณสมบัติใด ๆ ของ. NET Framework 3 และใหม่กว่ารวมถึง LINQ) การเพิ่มข้อมูลทั่วไปที่รหัสอาจได้รับประโยชน์จากพวกเขาเป็นต้น ฉันไม่สามารถใช้วิธีการที่เป็นทางการได้เพราะจะมีค่าใช้จ่ายเท่าใด ในทางกลับกันฉันคิดว่าอย่างน้อย"กฎใด ๆ ที่ได้รับการปรับเปลี่ยนใหม่จะต้องมาพร้อมกับการทดสอบหน่วย"ควรปฏิบัติตามกฎอย่างเคร่งครัดไม่ว่าจะต้องเสียค่าใช้จ่ายเท่าใด ปัญหาคือเมื่อฉันสร้างส่วนเล็ก ๆ ของวิธีส่วนตัว 500 LOC การเพิ่มการทดสอบหน่วยดูเหมือนจะเป็นงานที่ยาก สิ่งใดที่สามารถช่วยฉันในการรู้ว่าการทดสอบหน่วยใดที่เกี่ยวข้องกับโค้ดบางส่วน ฉันเดาว่าการวิเคราะห์โค้ดแบบคงที่จะมีประโยชน์ แต่เครื่องมือและเทคนิคที่ฉันสามารถใช้เพื่อ: รู้ว่าฉันควรสร้างการทดสอบหน่วยใด และ / หรือทราบว่าการเปลี่ยนแปลงที่ฉันทำมีผลกับรหัสต้นฉบับในแบบที่มันทำงานแตกต่างจากนี้หรือไม่?

10 unit-testing  refactoring  legacy  formal-methods 

เมื่อวันก่อนฉันอ่านเกี่ยวกับการทดสอบหน่วยเล็กน้อยและฉันเห็นตัวอย่างที่ผู้คนสร้างส่วนต่อประสานที่เก็บ (เช่นIExampleRepository) จากนั้นสร้างที่เก็บจริง ( public class ExampleRepository : IExampleRepository) และที่เก็บที่จะใช้สำหรับการทดสอบหน่วย ( FakeExampleRepository : IExampleRepository) ในIExampleRepositoryพวกเขาใช้วิธีการเดียวกันกับในExampleRepositoryแต่ด้วยคำสั่ง Linq ที่แตกต่างกัน อะไรคือวัตถุประสงค์ตรงนี้? ฉันคิดว่าส่วนหนึ่งของการทดสอบหน่วยของคุณคือตรวจสอบให้แน่ใจว่าวิธีการทำงานถูกต้องหรือไม่ แต่เมื่อฉันใช้แบบสอบถามที่แตกต่างกันสองข้อคำถามหนึ่งสำหรับ 'จริง' และอีกคำถามหนึ่งในการทดสอบการทดสอบมีความรู้สึกมากเพียงใด

10 c#  unit-testing  asp.net-mvc 

เมื่อเขียนการทดสอบหน่วยเป็นเรื่องปกติที่จะใช้อุปกรณ์ติดตั้ง: ข้อมูลที่ทดสอบได้เพียงเล็กน้อยดังนั้นเราจึงสามารถพูดได้: 1. รับลูกค้าทั้งหมดควรรวม Willy Wonka 2. ลบไคลเอนต์ 3 และตอนนี้รับไคลเอนต์ไม่ควรรวมวิลลี่วองก้าอีกต่อไป ไม่เป็นไรสำหรับการทดสอบหน่วย ใช้การตั้งค่า / การลดระดับเพื่อโหลดการแข่งขันอีกครั้งหรือย้อนกลับการทำธุรกรรม ดังนั้นการทดสอบสร้างปรับปรุงและลบจะทำภายในการทำธุรกรรม ข้อมูลชั่วคราวใหม่มีจำนวน จำกัด ตามความยาวของการทดสอบนั้นจะถูกรีเซ็ต แต่จะเกิดอะไรขึ้นเมื่อเราแยกเซิร์ฟเวอร์ REST ออกจากไคลเอนต์ REST เราต้องการตรวจสอบให้แน่ใจว่าลูกค้า REST ของเราไม่เพียง แต่อ่านอย่างถูกต้อง แต่สร้างอัปเดตและลบอย่างถูกต้อง ฉันไม่สามารถค้นหาตัวอย่างหรือคำแนะนำสำหรับวิธีการนี้กับเซิร์ฟเวอร์ REST ทดสอบระยะไกล สมมติว่าฉันได้ทดสอบเซิร์ฟเวอร์ REST ที่ให้บริการติดตั้งเท่านั้น ลักษณะไร้สัญชาติทั้งหมดของ HTTP หมายความว่าเป็นการยากที่จะส่ง "BEGIN TRANSACTION" และ "ROLLBACK TRANSACTION" หรือ "RELOAD FIXTURES" ประเภทข้อความใช่ไหม ฉันไม่สามารถเป็นคนแรกที่ต้องการทำสิ่งนี้ดังนั้นฉันจึงรู้สึกว่าฉันต้องการวิธีคิดที่แตกต่างออกไป ข้อเสนอแนะใด ๆ

10 unit-testing  api  rest 

ปัญหาเกิดขึ้นขณะทำ TDD หลังจากผ่านการทดสอบสองสามครั้งประเภทการคืนค่าของบางคลาส / โมดูลจะเปลี่ยนไป ในภาษาการเขียนโปรแกรมแบบสแตติกถ้าวัตถุที่เยาะเย้ยก่อนหน้านี้ถูกนำมาใช้ในการทดสอบของคลาสอื่น ๆและไม่ได้รับการแก้ไขเพื่อให้สะท้อนถึงการเปลี่ยนแปลงประเภทแล้วข้อผิดพลาดในการรวบรวมจะเกิดขึ้น อย่างไรก็ตามสำหรับภาษาแบบไดนามิกการเปลี่ยนแปลงประเภทการส่งคืนอาจไม่ถูกตรวจพบและการทดสอบของคลาสอื่นจะยังคงผ่าน แน่ใจว่าอาจมีการทดสอบการรวมที่จะล้มเหลวในภายหลัง แต่การทดสอบหน่วยจะผ่านอย่างผิดพลาด มีวิธีใดบ้างที่จะหลีกเลี่ยงปัญหานี้? การอัปเดตด้วยตัวอย่างเล็ก ๆ น้อย ๆ (ในบางภาษาที่สร้างขึ้น) ... รุ่น 1: Calc = { doMultiply(x, y) {return x * y} } //.... more code .... // On some faraway remote code on a different file Rect = { computeArea(l, w) {return Calc.doMultipy(x*y)} …

10 unit-testing  mocking  tdd 

ฉันมีชั้นเรียนที่ฉันกำลังทดสอบ ชั้นเรียนมีฟังก์ชั่น:apply(List<IRule> rules, List<ITarget> targets); ในการทดสอบหนึ่งครั้งฉันต้องการตรวจสอบให้แน่ใจว่าแต่ละเป้าหมายผ่านไปหนึ่งกฎ a: rule1.AssertWasCalled(fnord => fnord.Test(target1)); rule1.AssertWasCalled(fnord => fnord.Test(target2)); rule1.AssertWasCalled(fnord => fnord.Test(target3)); มันดูเหมือนว่าฉันที่ จำกัด ตัวเองเพื่อยืนยันคำสั่งเดียวจะค่อนข้างหลอกเด็ก ฉันถูกต้องในสมมติฐานนี้หรือมีวิธีอื่นที่ฉันสามารถยืนยันได้ว่าในความเป็นจริงแต่ละเป้าหมายมีการทดสอบแล้วหรือไม่?

10 unit-testing  code-quality 

ถ้าฉันมีฟังก์ชั่นในรหัสของฉันที่จะไป: class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } โดยปกติฉันจะ refactor นี้เพื่อใช้ Ploymorphism โดยใช้คลาสโรงงานและรูปแบบกลยุทธ์: public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } ตอนนี้ถ้าฉันใช้ TDD ฉันก็จะมีการทดสอบบางอย่างที่ทำงานกับต้นฉบับcalculateTax()ก่อนที่จะทำการรีแฟคเตอร์ อดีต: calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} …

10 design  design-patterns  unit-testing  tdd  refactoring 

ลองพิจารณาสองตัวอย่างนี้: ส่งผ่านวัตถุไปยังตัวสร้าง class ExampleA { private $config; public function __construct($config) { $this->config = $config; } } $config = new Config; $exampleA = new ExampleA($config); ยกระดับชั้นเรียน class ExampleB { private $config; public function __construct() { $this->config = new Config; } } $exampleA = new ExampleA(); วิธีใดที่ถูกต้องในการจัดการการเพิ่มวัตถุเป็นคุณสมบัติ เมื่อใดที่ฉันควรใช้อีกอันหนึ่ง? การทดสอบหน่วยมีผลต่อสิ่งที่ฉันควรใช้หรือไม่

10 object-oriented  unit-testing  configuration 

ในช่วงหนึ่งปีที่ผ่านมาฉันผลักดันทีมของฉันให้ก้าวไปสู่โหมดการพัฒนาที่วางจำหน่ายก่อนกำหนด (AKA: การพัฒนาแอปพลิเคชันอย่างรวดเร็วไม่ใช่ Agile) สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่เราปิดการสร้างดูคำตอบของฉันที่นี่: วิธีง่ายๆในการปรับปรุงคุณภาพการเผยแพร่ในสภาพแวดล้อม RAD เมื่อเราใช้ RAD ผู้คนค่อนข้างอิสระและพวกเขาทำการทดสอบหน่วยก่อน การทดสอบแบบบูรณาการเกิดขึ้นมากในภายหลังในกระบวนการ มันเป็นกระบวนการทางธรรมชาติสำหรับพวกเขาโดยไม่มีการบังคับใช้อย่างเป็นทางการมาก ตอนนี้สถานการณ์แตกต่างกันมาก: แพลตฟอร์มทั้งหมดได้รับการผสมผสานอย่างดีกับการสร้าง / วางจำหน่ายลูกค้าทำงานโดยไม่มีจุดร้อน ความต้องการฟังก์ชั่นใหม่ยังคงมาและเราจะเพิ่มพวกเขาในขณะที่เราไป การเปลี่ยนแปลงโดยรวมของระบบมีความสำคัญมากเพราะในขณะที่กลุ่มพัฒนาอิสระอาจทำตามกระบวนการที่ถูกต้องความล้มเหลวครั้งใหญ่เกิดขึ้นเนื่องจากสถานการณ์ที่ซับซ้อนและไม่ชัดเจน หลายส่วนของระบบเกี่ยวข้องกับอัลกอริธึมใหม่และข้อมูลการวิจัยดังนั้นความท้าทาย (และกลไกสำหรับการทดสอบ) จึงไม่สามารถคาดการณ์ได้อย่างถูกต้องเสมอไปเช่นการทดสอบคุณสมบัติในซอฟต์แวร์ที่กำหนดอย่างดี เมื่อเร็ว ๆ นี้ฉันพยายามทำให้ภาพรวมดีขึ้นเพื่อดูว่าเราต้องปรับปรุงกระบวนการหรือไม่ เมื่อฉันนั่งลงกับทีมของฉันพวกเขาหลายคนหยุดชะงัก: "เราไม่ทำการทดสอบหน่วยอีกต่อไป!" ในขณะที่คนอื่นคิดว่าเราไม่ควรเริ่มตอนนี้เพราะมันจะไม่มีประสิทธิภาพ การทดสอบหน่วยมีประโยชน์ในระบบที่ค่อนข้างสมบูรณ์หรือไม่? อย่างน้อยเราควรต้องชั่งน้ำหนักขอบเขตการทดสอบขึ้นอยู่กับวุฒิภาวะของหน่วย? การทดสอบหน่วยจะชะลอความเร็วของการพัฒนาหรือไม่ จำเป็นต้องประเมินการทดสอบหน่วยในวิธีอื่นหรือไม่? อะไรคือวิธีปฏิบัติที่ดีที่สุดในการทดสอบแพลตฟอร์มสำหรับผู้ใหญ่ในสภาพแวดล้อมที่มีการเปิดตัวเร็ว ๆ

10 unit-testing  rad 

ขณะนี้เรากำลังทำงานในโครงการ PHP / MySQL ขนาดกลาง / ใหญ่ เราทำการทดสอบหน่วยด้วย PHPUnit & QUnit และเรามีผู้ทดสอบเต็มเวลาสองคนที่ทำการทดสอบแอปพลิเคชันด้วยตนเอง ขณะนี้ข้อมูลการทดสอบ (จำลอง) ของเราสร้างขึ้นด้วยสคริปต์ SQL เรามีปัญหากับการบำรุงรักษาสคริปต์สำหรับข้อมูลการทดสอบ ตรรกะทางธุรกิจค่อนข้างซับซ้อนและการเปลี่ยนแปลง "ง่าย" หนึ่งครั้งในข้อมูลการทดสอบมักจะสร้างข้อบกพร่องหลายอย่างในแอปพลิเคชัน (ซึ่งไม่ใช่ข้อผิดพลาดจริง นี่เป็นภาระใหญ่สำหรับทั้งทีมเพราะเราสร้างและเปลี่ยนแปลงตารางอย่างต่อเนื่อง ฉันไม่เห็นจุดของการบำรุงรักษาข้อมูลการทดสอบในสคริปต์เพราะทุกอย่างสามารถเพิ่มได้ด้วยตนเองในแอปพลิเคชันในเวลาประมาณ 5 นาทีด้วย UI PM ของเราไม่เห็นด้วยและกล่าวว่าการมีโครงการที่เราไม่สามารถนำไปใช้กับข้อมูลทดสอบได้นั้นถือเป็นการปฏิบัติที่ไม่ดี เราควรละทิ้งการบำรุงรักษาสคริปต์ด้วยข้อมูลทดสอบและให้ผู้ทดสอบทดสอบแอปพลิเคชันโดยไม่มีข้อมูลหรือไม่ วิธีปฏิบัติที่ดีที่สุดคืออะไร

10 testing  unit-testing  quality  manual-testing 

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

10 unit-testing  dependencies 

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

10 unit-testing  tdd 

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

10 javascript  unit-testing