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

ฉันมีประสบการณ์มากกว่า 2 ปีในการพัฒนาแอพพลิเคชั่น ในสองปีที่ผ่านมาแนวทางการพัฒนาของฉันมีดังต่อไปนี้ วิเคราะห์ข้อกำหนด Identity Core องค์ประกอบ / วัตถุฟังก์ชันที่จำเป็น, พฤติกรรม, กระบวนการและข้อ จำกัด สร้างคลาสความสัมพันธ์ระหว่างพวกเขาข้อ จำกัด เกี่ยวกับพฤติกรรมของวัตถุ & รัฐ สร้างฟังก์ชั่นการประมวลผลด้วยข้อ จำกัด พฤติกรรมตามความต้องการ ทดสอบแอปพลิเคชันด้วยตนเอง หากความต้องการเปลี่ยนแปลงแก้ไของค์ประกอบ / ฟังก์ชั่นให้ทดสอบโปรแกรมด้วยตนเอง เมื่อเร็ว ๆ นี้ฉันได้รับการแนะนำให้รู้จักกับ TDD และรู้สึกว่านี่เป็นวิธีที่ดีมากในการพัฒนาเนื่องจากโค้ดที่พัฒนาแล้วมีเหตุผลที่แข็งแกร่งที่มีอยู่ แต่ปัญหาของฉันคือฉันไม่สามารถสร้างการทดสอบก่อนได้ แต่ฉันจะระบุส่วนประกอบและเพียงแค่เขียนการทดสอบสำหรับพวกเขาก่อนที่ฉันจะเขียนส่วนประกอบจริง ๆ คำถามของฉันคือ ฉันทำถูกไหม? ถ้าไม่ใช่สิ่งที่ฉันต้องเปลี่ยนแน่นอน มีวิธีใดที่คุณสามารถระบุได้ว่าแบบทดสอบที่คุณเขียนนั้นเพียงพอหรือไม่ เป็นการดีหรือไม่ที่จะทดสอบการเขียนสำหรับฟังก์ชั่นที่ง่ายมากซึ่งอาจเทียบเท่ากับ 1 + 1 = 2 หรือเป็นเพียงภาพซ้อนทับ? มันเป็นการดีที่จะเปลี่ยนฟังก์ชั่นและตามการทดสอบว่ามีการเปลี่ยนแปลงข้อกำหนด?

15 programming-practices  unit-testing  tdd  acceptance-testing 

ฉันกำลังปรับโครงสร้างคลาสรหัสเดิมอีกครั้ง Refactoring (ฉันเข้าใจ) สนับสนุนสิ่งนี้: เขียนแบบทดสอบสำหรับคลาสดั้งเดิม refactor heck ออกจากชั้นเรียน ปัญหา: เมื่อฉันปรับโครงสร้างห้องเรียนใหม่การทดสอบของฉันในขั้นตอนที่ 1 จะต้องมีการเปลี่ยนแปลง ตัวอย่างเช่นสิ่งที่ครั้งหนึ่งเคยเป็นวิธีดั้งเดิมตอนนี้อาจเป็นชั้นแยกต่างหาก อะไรคือวิธีการหนึ่งที่อาจมีหลายวิธี ภูมิทัศน์ทั้งหมดของชั้นเรียนดั้งเดิมอาจถูกลบล้างเป็นสิ่งใหม่ดังนั้นการทดสอบที่ฉันเขียนในขั้นตอนที่ 1 เกือบจะเป็นโมฆะ ในสาระสำคัญฉันจะเพิ่มขั้นตอนที่ 3 เขียนการทดสอบของฉันอย่างล้นเหลือ อะไรคือจุดประสงค์ในการเขียนแบบทดสอบก่อนที่จะสร้างใหม่? ฟังดูคล้ายกับแบบฝึกหัดทางวิชาการในการสร้างงานให้ตัวเองมากขึ้น ฉันกำลังเขียนแบบทดสอบสำหรับวิธีนี้และฉันกำลังเรียนรู้เพิ่มเติมเกี่ยวกับวิธีทดสอบสิ่งต่าง ๆ และวิธีการทำงานแบบเดิม เราสามารถเรียนรู้สิ่งนี้ได้โดยการอ่านรหัสดั้งเดิม แต่การทดสอบการเขียนนั้นคล้ายกับการถูจมูกของฉันและการบันทึกความรู้ชั่วคราวนี้ในการทดสอบแยกต่างหาก ด้วยวิธีนี้ฉันแทบจะไม่มีทางเลือกนอกจากเรียนรู้ว่าโค้ดทำอะไร ฉันพูดว่าชั่วคราวที่นี่เพราะฉันจะ refactor heck ออกจากรหัสและเอกสารและการทดสอบทั้งหมดของฉันจะเป็นโมฆะและเป็นโมฆะเป็นส่วนสำคัญยกเว้นความรู้ของฉันจะอยู่และอนุญาตให้ฉันสดใน refactoring นั่นคือเหตุผลที่แท้จริงในการเขียนการทดสอบก่อน refactor - เพื่อช่วยให้ฉันเข้าใจรหัสได้ดีขึ้น? จะต้องมีเหตุผลอื่น! กรุณาอธิบาย! บันทึก: มีโพสต์นี้: มันทำให้รู้สึกถึงการเขียนการทดสอบสำหรับรหัสดั้งเดิมเมื่อไม่มีเวลาสำหรับการปรับโครงสร้างที่สมบูรณ์? แต่มันบอกว่า "เขียนการทดสอบก่อน refactor" แต่ไม่ได้พูดว่า "ทำไม" หรือจะทำอย่างไรถ้า "การทดสอบการเขียน" ดูเหมือนว่า …

15 testing  refactoring  tdd  legacy-code 

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

15 tdd  estimation 

ฉันต้องการถามคนอื่น ๆ ว่าในกรณีนี้การทดสอบหน่วยการพิมพ์แบบสแตติกทำงานได้ดีตามที่เขียนใน haskell, scala, ocaml, nemerle, f # หรือ haXe (สุดท้ายคือสิ่งที่ฉันสนใจจริงๆ แต่ฉันต้องการ แตะเข้าไปในความรู้ของชุมชนที่ใหญ่กว่า) ฉันถามสิ่งนี้เพราะจากความเข้าใจของฉัน: ด้านหนึ่งของการทดสอบหน่วยคือการมีรายละเอียดในรูปแบบที่รันได้ อย่างไรก็ตามเมื่อใช้รูปแบบการประกาศที่แมปข้อมูลจำเพาะอย่างเป็นทางการกับความหมายของภาษาเป็นไปได้หรือไม่ที่จริงแล้วมันเป็นไปได้หรือไม่ที่จะแสดงรายละเอียดในรูปแบบที่รันได้ในวิธีที่แยกจากกัน ลักษณะที่ชัดเจนของการทดสอบหน่วยคือการติดตามข้อผิดพลาดที่ไม่สามารถเปิดเผยได้ผ่านการวิเคราะห์แบบคงที่ เนื่องจากรหัสการทำงานที่ปลอดภัยประเภทนั้นเป็นเครื่องมือที่ดีในการเขียนโค้ดที่ใกล้เคียงกับที่ตัววิเคราะห์สถิตของคุณเข้าใจมากดูเหมือนว่าคุณสามารถเปลี่ยนความปลอดภัยไปสู่การวิเคราะห์แบบสถิต อย่างไรก็ตามข้อผิดพลาดง่าย ๆ เช่นการใช้xแทนy(ทั้งคู่เป็นพิกัด) ในรหัสของคุณไม่สามารถครอบคลุม ความผิดพลาดดังกล่าวอาจเกิดขึ้นในขณะที่เขียนรหัสทดสอบดังนั้นฉันไม่แน่ใจว่ามันคุ้มค่ากับความพยายามหรือไม่ การทดสอบหน่วยจะนำเสนอความซ้ำซ้อนซึ่งหมายความว่าเมื่อต้องการเปลี่ยนแปลงรหัสการใช้งานและการทดสอบที่ครอบคลุมรหัสนี้จะต้องเปลี่ยนทั้งคู่ แน่นอนว่าค่าโสหุ้ยนี้เป็นเรื่องเกี่ยวกับค่าคงที่ดังนั้นเราจึงสามารถโต้แย้งได้ว่ามันไม่สำคัญ ในความเป็นจริงในภาษาอย่าง Ruby นั้นไม่ได้เปรียบเทียบกับประโยชน์ที่ได้รับ แต่เนื่องจากการเขียนโปรแกรมเชิงฟังก์ชันที่ครอบคลุมการทดสอบหน่วยภาคพื้นดินจำนวนมากนั้นมีจุดประสงค์เพื่อให้ความรู้สึกว่าเป็นค่าใช้จ่ายที่คงที่เพียงอย่างเดียว จากนี้ฉันจะอนุมานว่าการทดสอบหน่วยค่อนข้างล้าสมัยในรูปแบบการเขียนโปรแกรมนี้ แน่นอนว่าการอ้างสิทธิ์ดังกล่าวสามารถนำไปสู่สงครามศาสนาเท่านั้นดังนั้นให้ฉันตั้งคำถามนี้ง่ายๆ เมื่อคุณใช้รูปแบบการเขียนโปรแกรมคุณใช้ขอบเขตการทดสอบแบบใดและเพราะเหตุใด (คุณหวังว่าจะได้คุณภาพสำหรับโค้ดของคุณ) หรือในทางกลับกัน: คุณมีเกณฑ์ที่คุณสามารถมีคุณสมบัติหน่วยของรหัสการทำงานแบบคงที่ตามที่ครอบคลุมโดยตัววิเคราะห์แบบคงที่และโดยไม่จำเป็นต้องครอบคลุมการทดสอบหน่วย?

15 unit-testing  functional-programming  tdd  haskell  scala 

Code Retreat เป็นกิจกรรมการฝึกอบรมตลอดทั้งวันที่มุ่งเน้นไปที่พื้นฐานของการพัฒนาซอฟต์แวร์ มีวันล่าถอยรหัส "ทั่วโลก" ที่กำลังจะมาถึงและฉันรอคอยมันอยู่ ที่กล่าวว่าฉันเคยเป็นหนึ่งก่อนและต้องบอกว่ามีจำนวนมากของความโกลาหล ... ซึ่งเป็นเรื่องปกติ สิ่งหนึ่งที่ฉันยังไม่เข้าใจคือทำไม "เกมแห่งชีวิต" เป็นปัญหาที่ดีสำหรับ TDD และสิ่งที่ดีและไม่ดีสำหรับ TDD สำหรับมันรู้สึก ตระหนักว่านี่เป็นคำถามที่เปิดกว้างดังนั้นอย่าลังเลที่จะแสดงความคิดเห็น

15 tdd 

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

15 testing  algorithms  tdd  artificial-intelligence 

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

15 testing  tdd  anti-patterns  object-oriented-design  mocking 

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

15 web-development  unit-testing  web-applications  tdd 

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

15 architecture  testing  tdd  domain-driven-design 

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

15 tdd  ruby-on-rails  communication 

ฉันได้ยินมามากมายจากผู้ฝึกอบรมTDDว่าข้อดีอย่างหนึ่งของ TDD คือบังคับให้นักพัฒนาปฏิบัติตามหลักการของSOLID (ความรับผิดชอบเดี่ยว, เปิด - ปิด, การทดแทน Liskov, การแยกอินเตอร์เฟสและการผกผันการพึ่งพา) แต่สำหรับฉันแล้วมันก็เพียงพอแล้วที่จะเขียนการทดสอบ (การทดสอบหน่วยเบื้องต้น) เพื่อให้เข้าใจว่าการติดตาม SOLID เป็นสิ่งสำคัญ TDD บังคับให้ผู้พัฒนาติดตาม SOLID มากกว่าการเขียนบททดสอบหรือไม่?

15 unit-testing  tdd  solid 

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

14 unit-testing  tdd  bug 

เมื่อมีการรวมอย่างต่อเนื่องในการดำเนินการทดสอบในแต่ละการกระทำแนวทางปฏิบัติที่ดีที่สุดคือการทดสอบทั้งหมดที่ผ่านตลอดเวลา (หรือที่รู้จักว่า ฉันพบปัญหาบางอย่างกับที่: ตัวอย่างหนึ่งไม่สามารถช่วยโครงการโอเพ่นซอร์สโดยการสร้างการทดสอบที่สอดคล้องกับตั๋ว ฉันรู้ว่าฉันเสนอ Pull Request ให้กับโปรเจคโอเพ่นซอร์สที่มีการทดสอบความล้มเหลวบิลด์จะถูกทำเครื่องหมายว่าล้มเหลวและโปรเจ็กต์จะไม่ต้องการรวมเข้ากับที่เก็บเพราะมันจะ "ทำลายบิลด์" และฉันไม่เชื่อว่ามันเป็นสิ่งที่ไม่ดีที่มีการทดสอบที่ล้มเหลวใน repo ของคุณเหมือนมีปัญหาในตัวติดตามของคุณ สิ่งเหล่านี้เป็นเพียงสิ่งที่รอการแก้ไข เช่นเดียวกับใน บริษัท หากคุณทำงานกับ TDD คุณจะไม่สามารถเขียนทดสอบกระทำและเขียนรหัสตรรกะที่ทำแบบทดสอบได้ นั่นหมายความว่าถ้าฉันเขียนแบบทดสอบ 4-5 เรื่องบนแล็ปท็อปของฉันฉันไม่สามารถยืนยันได้ก่อนวันหยุด ไม่มีใครสามารถคืนงานของฉันได้ ฉันไม่สามารถแม้แต่ "แบ่งปัน" กับเพื่อนร่วมงานได้ยกเว้นโดยการส่งทางอีเมลเช่น นอกจากนี้ยังป้องกันการทำงานกับคนคนหนึ่งที่เขียนแบบทดสอบอีกคนหนึ่งเขียนแบบ ทั้งหมดที่จะพูดว่าฉันใช้ผิด / เข้าใจผิดกระบวนการสร้าง / บูรณาการอย่างต่อเนื่องหรือไม่ สำหรับฉันแล้วดูเหมือนว่า "ผ่าน" / "ไม่ผ่าน" เป็นตัวบ่งชี้ที่แคบเกินไป มีวิธีที่จะทำให้การรวมระบบอย่างต่อเนื่องและเข้ากันได้กับ TDD หรือไม่? อาจมีวิธีแก้ปัญหามาตรฐาน / การปฏิบัติเพื่อแยก "การทดสอบใหม่" (ที่สามารถล้มเหลว) และ "การทดสอบการถดถอย" (ที่ไม่ควรล้มเหลวเพราะพวกเขาเคยทำงาน)?

14 tdd  continuous-integration  tests 

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

14 database  sql  tdd  test-automation 

ฉันเรียนรู้ที่จะพัฒนา Test Driven Development (TDD), Dependency Injection (DI) และ Inversion of Control (IoC) ทั้งหมดในเวลาเดียวกัน เมื่อฉันเขียนรหัสโดยใช้ TDD ฉันมักจะจบลงด้วยการใช้ DI ใน Constructor ของชั้นเรียน ฉันสงสัยว่านี่เป็นเพราะฉันเรียนรู้ที่จะทำ TDD หรือถ้านี่เป็นผลข้างเคียงตามธรรมชาติของ TDD ดังนั้นคำถามของฉันคือ: ทำตามหลักการของ TDD และการทดสอบหน่วยการเขียนที่ไม่ได้ขึ้นอยู่กับบริการภายนอกที่นำไปสู่ ​​DI อย่างหลีกเลี่ยงไม่?

14 tdd  dependency-injection  inversion-of-control