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

ฉันพยายามที่จะจับกับการทดสอบหน่วย สมมติว่าเรามีแม่พิมพ์ซึ่งสามารถมีจำนวนด้านเริ่มต้นเท่ากับ 6 (แต่สามารถมี 4, 5 ด้าน ฯลฯ ): import random class Die(): def __init__(self, sides=6): self._sides = sides def roll(self): return random.randint(1, self._sides) ต่อไปนี้เป็นการทดสอบที่ถูกต้อง / มีประโยชน์หรือไม่ ทดสอบม้วนในช่วง 1-6 สำหรับแม่พิมพ์แบบ 6 ด้าน ทดสอบม้วน 0 สำหรับแม่พิมพ์แบบ 6 ด้าน ทดสอบม้วน 7 สำหรับแม่พิมพ์แบบ 6 ด้าน ทดสอบม้วนในช่วง 1-3 สำหรับแม่พิมพ์ 3 ด้าน ทดสอบม้วน 0 สำหรับแม่พิมพ์ …

18 python  unit-testing  tdd 

ในระหว่างการฝึกอบรม TDD ตามกรณีซอฟต์แวร์ทางการแพทย์เรากำลังใช้เรื่องต่อไปนี้: "เมื่อผู้ใช้กดปุ่มบันทึกระบบควรเพิ่มผู้ป่วยเพิ่มอุปกรณ์และเพิ่มบันทึกข้อมูลอุปกรณ์" การใช้งานขั้นสุดท้ายจะมีลักษณะดังนี้: if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed) { AddPatient(); AddDevice(); AddDeviceDataRecords(); } เรามีสองวิธีในการติดตั้ง: การทดสอบสามครั้งที่แต่ละวิธีตรวจสอบหนึ่งวิธี (AddPatient, AddDevice, AddDeviceDataRecords) ถูกเรียก หนึ่งการทดสอบที่ตรวจสอบทั้งสามวิธีถูกเรียก ในกรณีแรกหากมีสิ่งผิดปกติเกิดขึ้นหากเงื่อนไขข้อการทดสอบทั้งสามจะล้มเหลว แต่ในกรณีที่สองหากการทดสอบล้มเหลวเราไม่แน่ใจว่ามีอะไรผิดปกติ คุณต้องการแบบไหน

18 unit-testing  tdd 

ฉันกำลังทำงานกับเครื่องมือเปรียบเทียบรายการเพื่อช่วยในการจัดเรียงรายการผลการค้นหาที่ไม่เรียงลำดับตามข้อกำหนดเฉพาะจากลูกค้าของเรา ข้อกำหนดเรียกร้องให้อัลกอริทึมความเกี่ยวข้องจัดอันดับด้วยกฎต่อไปนี้ตามลำดับความสำคัญ: ตรงกับชื่อ คำค้นหาทั้งหมดในชื่อหรือคำพ้องความหมายของผลลัพธ์ คำค้นหาบางคำในชื่อหรือคำพ้องความหมายของผลลัพธ์ (% จากมากไปหาน้อย) คำทั้งหมดของคำค้นหาในคำอธิบาย คำบางส่วนของคำค้นหาในคำอธิบาย (% มากไปหาน้อย) วันที่แก้ไขล่าสุดจากมากไปน้อย ตัวเลือกการออกแบบตามธรรมชาติสำหรับตัวเปรียบเทียบนี้ดูเหมือนจะเป็นอันดับที่จัดอันดับขึ้นอยู่กับพลังของ 2 ผลรวมของกฎที่สำคัญน้อยกว่านั้นไม่สามารถเป็นได้มากกว่าการจับคู่เชิงบวกกับกฎที่มีความสำคัญสูงกว่า นี่คือความสำเร็จโดยคะแนนต่อไปนี้: 32 16 8 (คะแนน tie-breaker รองตาม% จากมากไปน้อย) 4 2 (คะแนน tie-breaker รองตาม% จากมากไปน้อย) 1 ในจิตวิญญาณ TDD ฉันตัดสินใจเริ่มต้นด้วยการทดสอบหน่วยของฉันก่อน ในการมีกรณีทดสอบสำหรับแต่ละสถานการณ์ที่ไม่ซ้ำกันจะต้องมีอย่างน้อย 63 กรณีทดสอบที่ไม่ซ้ำกันโดยไม่พิจารณากรณีทดสอบเพิ่มเติมสำหรับตรรกะตัวแบ่งลำดับที่สองในกฎข้อที่ 3 และ 5 ซึ่งดูเหมือนจะเป็นเรื่องที่น่ากลัว การทดสอบจริงจะน้อยลง ตามกฎจริงเองกฎบางอย่างทำให้มั่นใจได้ว่ากฎที่ต่ำกว่าจะเป็นจริงเสมอ (เช่นเมื่อ 'คำค้นหาทั้งหมดปรากฏในคำอธิบาย' จากนั้นกฎ 'คำค้นหาคำบางคำที่ปรากฏในคำอธิบาย' จะเป็นจริงเสมอ) ยังคงมีระดับความพยายามในการเขียนแต่ละกรณีทดสอบเหล่านี้คุ้มค่าหรือไม่ นี่เป็นระดับของการทดสอบที่มักจะถูกเรียกเมื่อพูดถึงการครอบคลุมการทดสอบ 100% …

18 algorithms  unit-testing  tdd 

“ ทำไมแค่คิดว่าการทดสอบของคุณดีเมื่อคุณรู้แน่? บางครั้งเจสเตอร์บอกการทดสอบของฉันว่าเป็นสุญญากาศ แต่บางครั้งการเปลี่ยนแปลงที่พบก็เกิดขึ้นราวกับสายฟ้าออกจากสีน้ำเงิน แนะนำเป็นอย่างยิ่ง” - Kent Beck แต่ฉันเห็นว่าไม่มีแม้แต่แท็กที่ชื่อว่า " Jester " ใน stackoverflow ดังนั้นสิ่งที่ทดแทนที่ทันสมัยสำหรับเจสเตอร์ถ้ามี? เราจะแน่ใจได้อย่างไรว่าการทดสอบหน่วยที่เขียนไว้นั้นมั่นคงกว่าการค้นหาสถิติจากการครอบคลุมโค้ดจากเครื่องมือเช่นCoberturaและClover ?

18 java  unit-testing  code-quality  tdd 

ฉันมีวิธี DAO ที่ใช้ Spring สำหรับการเข้าถึง JDBC มันคำนวณอัตราความสำเร็จของผู้ขายในการขายสินค้า นี่คือรหัส: public BigDecimal getSellingSuccessRate(long seller_id) { String sql = "SELECT SUM(IF(sold_price IS NOT NULL, 1, 0))/SUM(1) FROM transaction WHERE seller_id = ?"; Object[] args = {seller_id}; return getJdbcTemplate().queryForObject(sql, args, BigDecimal.class); } ฉันควรจะทดสอบวิธีนี้หรือวิธี DAO กับ JUnit อย่างไร แนวทางปฏิบัติที่ดีที่สุดในการทดสอบตรรกะการเข้าถึงข้อมูลคืออะไร ฉันคิดว่าจะทดสอบกับฐานข้อมูลแบบฝังที่โหลดด้วยข้อมูลบางส่วน แต่เราไม่ควรทำการทดสอบการรวมที่คล้ายกับสภาพแวดล้อมการผลิตในแง่ของ RDBMS และสคีมาหรือไม่

17 java  programming-practices  testing  tdd 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา มีแอพพลิเคชั่นโอเพนซอร์ซที่พัฒนาขึ้นโดยใช้การพัฒนาแบบทดสอบที่ทำหน้าที่เป็นตัวอย่างของการทดสอบหน่วยที่ดี ฉันต้องการดูตัวอย่างใน C # และ. NET (โปรดทราบว่าฉันพูดถึงแอปพลิเคชันไม่ใช่เฉพาะห้องสมุด) ฉันเป็นโปรแกรมเมอร์ระดับกลางที่ต้องการเชื่อและฝึกฝน TDD จริงๆ แอพที่ฉันทำงานในงานประจำวันนั้นค่อนข้างซับซ้อน - มีโค้ดประมาณ 1 ล้านบรรทัดและฉันชอบที่จะแนะนำการทดสอบหน่วยเพิ่มเติม เรามีการทดสอบหน่วยในสถานที่ แต่ความพยายามของฉันที่ TDD และการทำงานกับรหัสที่อยู่ภายใต้การทดสอบยังไม่ได้รับการสนับสนุน จากประสบการณ์ที่ จำกัด ของฉันดูเหมือนว่า TDD จะส่งเสริมความซับซ้อนมากมายในนามของการแยก บิตของแอปที่ยากต่อการทดสอบ - และที่บังเอิญมีแนวโน้มจะสำคัญ - ถูกผลักออกไปที่ขอบนอกสู่ขอบเขตของการทดสอบการรวมที่อาจหรือไม่อาจถูกเขียนขึ้นมา (ฉันกำลังคิดถึงผู้ต้องสงสัยตามปกติที่นี่การเข้าถึงระบบไฟล์การให้ความชุ่มชื้นวัตถุจากฐานข้อมูลการโทรทางเว็บแบบอะซิงโครนัส ฯลฯ ) รหัสที่อยู่ภายใต้การทดสอบมีแนวโน้มที่จะเกี่ยวข้องกับการทำงานร่วมกันระหว่างวัตถุและอาจมีตรรกะการไหลอย่างง่าย ๆ ซึ่งทั้งหมดเกิดขึ้นในหน่วยความจำและสามารถเขียนได้ในวิธีที่ง่ายกว่าและเข้าใจได้มากกว่า สำหรับการทดสอบ ฉันเข้าใจเทคนิคในการล้อเลียนการอ้างอิงและเช่นนี้ แต่ในประสบการณ์ของฉันการใช้การเยาะเย้ยอย่างหนักนำไปสู่การทดสอบที่เปราะบางมาก ถ้าสัญชาตญาณแรกของฉันเมื่อเห็นการทดสอบเป็นสีแดงก็คือ …

17 unit-testing  tdd 

ฉันไม่ได้ใหม่กับการเขียนโปรแกรมและฉันได้ทำงานกับระดับต่ำ C และ ASM ใน AVR แต่ฉันไม่สามารถไปรอบ ๆ โครงการ C ขนาดใหญ่ที่ฝังตัวได้ ด้วยความเสื่อมของปรัชญารูดี้ของ TDD / BDD ฉันไม่สามารถเข้าใจได้ว่าผู้คนเขียนและทดสอบโค้ดเช่นนี้อย่างไร ฉันไม่ได้บอกว่ามันเป็นรหัสที่ไม่ดีฉันไม่เข้าใจว่ามันจะทำงานได้อย่างไร ฉันอยากจะเขียนโปรแกรมระดับล่างให้มากขึ้น แต่ฉันไม่รู้ว่าจะทำอย่างไรกับสิ่งนี้เพราะมันดูเหมือนความคิดที่แตกต่างไปจากเดิมอย่างสิ้นเชิงที่ฉันคุ้นเคย ฉันไม่มีปัญหาในการทำความเข้าใจตัวบ่งชี้ทางคณิตศาสตร์หรือการจัดสรรหน่วยความจำทำงานอย่างไร แต่เมื่อฉันเห็นว่าโค้ด C / C ++ ที่ซับซ้อนมีลักษณะอย่างไรเมื่อเทียบกับ Ruby ดูเหมือนว่ายากมาก ตั้งแต่ฉันสั่งบอร์ด Arduino มาเองฉันชอบที่จะเพิ่มระดับ C ที่ต่ำลงและเข้าใจวิธีการทำสิ่งต่าง ๆ ได้อย่างถูกต้อง แต่ดูเหมือนว่าไม่มีกฎของภาษาระดับสูงมาใช้ เป็นไปได้ไหมที่จะทำ TDD บนอุปกรณ์ฝังตัวหรือเมื่อพัฒนาไดรเวอร์หรือสิ่งต่าง ๆ เช่น bootloader แบบกำหนดเองเป็นต้น

17 c  tdd  embedded-systems 

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

17 design  tdd 

สมมติว่าเรามีแอปพลิเคชันระดับองค์กรขนาดใหญ่โดยไม่มีการทดสอบหน่วย / การทำงานใด ๆ ไม่มีกระบวนการพัฒนาที่ขับเคลื่อนด้วยการทดสอบในระหว่างการพัฒนาอันเนื่องมาจากกำหนดเวลาที่เข้มงวดมาก (ฉันรู้ว่าเราไม่ควรสัญญาวันครบกำหนดที่แน่นเมื่อเราไม่แน่ใจ แต่สิ่งที่ทำเสร็จแล้ว!) ตอนนี้ทุกอย่างผ่านไปและทุกอย่างสงบลงทุกคนตกลงที่จะเปลี่ยนเราให้เป็นทีมงานที่มีประสิทธิผลของ TDD / BDD ... ตอนนี้คำถามเกี่ยวกับรหัสที่เรามีอยู่แล้ว: (1) มันยังไม่เป็นไรหรือเป็นความคิดที่ดีที่จะหยุดการพัฒนาส่วนใหญ่และเริ่มเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดตั้งแต่เริ่มต้นถึงแม้ว่าทุกอย่างจะทำงานได้อย่างสมบูรณ์ ? หรือ (2) เป็นการดีกว่าที่จะรอสิ่งที่ไม่ดีเกิดขึ้นจากนั้นในระหว่างการแก้ไขการทดสอบหน่วยการทดสอบใหม่หรือ (3) แม้กระทั่งลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่าง มีไม่กี่ที่ดีและบทความที่เกี่ยวข้องเช่นนี้ ฉันยังไม่แน่ใจว่ามันคุ้มค่าหรือไม่ที่จะพิจารณาเรื่องนี้เพราะเรามีเวลา จำกัด และโครงการ / งานอื่น ๆ อีกมากมายกำลังรอเราอยู่ หมายเหตุ : คำถามนี้อธิบาย / จินตนาการถึงสถานการณ์ที่น่าอึดอัดใจในทีมพัฒนา นี่ไม่เกี่ยวกับฉันหรือเพื่อนร่วมงานของฉัน มันเป็นเพียงสถานการณ์ในจินตนาการ คุณอาจคิดว่าสิ่งนี้ไม่ควรเกิดขึ้นหรือผู้จัดการฝ่ายพัฒนารับผิดชอบต่อความยุ่งเหยิง! แต่อย่างไรก็ตามสิ่งที่ทำเสร็จแล้ว หากเป็นไปได้โปรดอย่าโหวตเพราะคุณคิดว่าสิ่งนี้จะไม่เกิดขึ้น

17 unit-testing  testing  tdd  bdd  acceptance-testing 

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

17 testing  unit-testing  tdd 

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

16 unit-testing  tdd  integration-tests  mocking 

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

16 unit-testing  testing  tdd  integration-tests  acceptance-testing 

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

16 agile  testing  unit-testing  tdd  sdlc 

ในการพูดคุยของเขาTDD มันผิดพลาดที่ไหนเอียนคูเปอร์ผลักดันความตั้งใจดั้งเดิมของเบ็คเบ็คหลังการทดสอบหน่วยใน TDD (เพื่อทดสอบพฤติกรรม ในกรณีของพฤติกรรมเช่นsave X to some data sourceในระบบที่มีชุดบริการและที่เก็บทั่วไปเราจะทดสอบการบันทึกข้อมูลบางอย่างในระดับการบริการผ่านที่เก็บโดยไม่ต้องเชื่อมต่อการทดสอบกับรายละเอียดการใช้งาน (เช่นการเรียกวิธีการเฉพาะ )? การหลีกเลี่ยงการมีเพศสัมพันธ์แบบนี้จริง ๆ แล้วไม่คุ้มค่าความพยายาม / ไม่ดีในบางวิธี?

16 unit-testing  tdd  coupling 

ฉันค่อนข้างใหม่สำหรับ TDD และฉันมีปัญหาในการสร้างการทดสอบครั้งแรกของฉันเมื่อมันมาก่อนรหัสการติดตั้งใด ๆ หากไม่มีกรอบในการติดตั้งโค้ดฉันมีอิสระที่จะเขียนการทดสอบครั้งแรกของฉันได้ แต่ฉันต้องการ แต่มันก็ดูจะเสียไปโดยวิธีการคิดแบบ Java / OO ของฉันเสมอ ตัวอย่างเช่นในGithub ConwaysGameOfLifeของฉันตัวอย่างการทดสอบครั้งแรกที่ฉันเขียน (rule1_zeroNeighbours) ฉันเริ่มต้นด้วยการสร้างวัตถุ GameOfLife ที่ยังไม่ได้ใช้งาน เรียกว่าชุดวิธีการที่ไม่มีอยู่วิธีการขั้นตอนที่ไม่มีอยู่วิธีรับที่ไม่มีอยู่แล้วใช้การยืนยัน การทดสอบพัฒนาขึ้นเมื่อฉันเขียนการทดสอบและปรับโครงสร้างใหม่ แต่เดิมแล้วมันมีลักษณะดังนี้: @Test public void rule1_zeroNeighbours() { GameOfLife gameOfLife = new GameOfLife(); gameOfLife.set(1, 1, true); gameOfLife.step(); assertEquals(false, gameOfLife.get(1, 1)); } สิ่งนี้รู้สึกแปลก ๆ เนื่องจากฉันถูกบังคับให้ออกแบบการนำไปใช้ตามวิธีที่ฉันตัดสินใจในช่วงแรกนี้เพื่อเขียนการทดสอบครั้งแรก ในวิธีที่คุณเข้าใจ TDD มันโอเคไหม? ฉันดูเหมือนจะปฏิบัติตามหลักการ TDD / XP ในการทดสอบและการใช้งานของฉันที่พัฒนาตลอดเวลาด้วยการปรับโครงสร้างใหม่และดังนั้นหากการออกแบบเริ่มต้นนี้ได้พิสูจน์แล้วว่าไร้ประโยชน์มันจะเปิดให้มีการเปลี่ยนแปลง แต่รู้สึกว่าฉันกำลังบังคับทิศทาง …

15 java  testing  tdd  extreme-programming