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

การตรวจสอบพฤติกรรมของระบบซอฟต์แวร์กับพฤติกรรมที่คาดหวังของระบบนั้น

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

9
โปรแกรมเมอร์เป็นผู้ทดสอบที่ไม่ดีหรือไม่?
ฉันรู้ว่ามันฟังดูเหมือนคำถามอื่น ๆ ที่ถูกถามไปแล้ว แต่จริงๆแล้วมันแตกต่างออกไปเล็กน้อย ดูเหมือนว่าโดยทั่วไปแล้วผู้เขียนโปรแกรมจะไม่เก่งในการทดสอบบทบาทของแอปพลิเคชัน ตัวอย่างเช่น: โจเอลซอฟแวร์ - Top Five (ผิด) เหตุผลที่คุณไม่ได้มีการทดสอบ (เหมืองเน้น) อย่าคิดแม้แต่จะพยายามบอกผู้สำเร็จการศึกษาจากวิทยาลัย CS ว่าพวกเขาสามารถมาทำงานให้คุณได้ แต่ "ทุกคนจะต้องควบคุมคุณภาพในช่วงเวลาหนึ่งก่อนที่จะเปลี่ยนเป็นรหัส" ฉันเห็นสิ่งนี้มากมาย โปรแกรมเมอร์ไม่ทำการทดสอบที่ดีและคุณจะสูญเสียโปรแกรมเมอร์ที่ดีซึ่งยากที่จะแทนที่ และในคำถามนี้หนึ่งในคำตอบที่ได้รับความนิยมมากที่สุดบอกว่า (อีกครั้งฉันขอเน้น): นักพัฒนาสามารถเป็นผู้ทดสอบได้ แต่พวกเขาไม่ควรเป็นผู้ทดสอบ นักพัฒนามีแนวโน้มที่จะหลีกเลี่ยงการใช้แอปพลิเคชั่นโดยไม่ตั้งใจ / ไม่ตั้งใจ นั่นเป็นเพราะพวกเขาเขียนและทดสอบเป็นส่วนใหญ่ในแบบที่ควรจะใช้ ดังนั้นคำถามคือโปรแกรมเมอร์ไม่ดีในการทดสอบหรือไม่ มีหลักฐานหรือข้อโต้แย้งอะไรบ้างที่สนับสนุนข้อสรุปนี้? โปรแกรมเมอร์ไม่ดีเพียงทดสอบรหัสของตนเองหรือไม่ มีหลักฐานที่แสดงว่าโปรแกรมเมอร์ดีจริง ๆที่ทดสอบหรือไม่ ฉันหมายถึงอะไรโดย "การทดสอบ" ฉันไม่ได้หมายถึงการทดสอบหน่วยหรือสิ่งใดก็ตามที่ถือว่าเป็นส่วนหนึ่งของวิธีการที่ทีมซอฟต์แวร์ใช้เพื่อเขียนซอฟต์แวร์ ฉันหมายถึงวิธีการประกันคุณภาพบางอย่างที่ใช้หลังจากสร้างรหัสและปรับใช้กับสิ่งที่ทีมซอฟต์แวร์จะเรียกว่า "สภาพแวดล้อมการทดสอบ"
36 testing  qa 

3
การทดสอบการรวมหมายถึงการทดสอบหน่วยทั้งหมดซ้ำหรือไม่?
สมมติว่าฉันมีฟังก์ชั่น (เขียนใน 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)

10
นักพัฒนาซอฟต์แวร์ควรรับผิดชอบการทดสอบอื่น ๆ นอกเหนือจากการทดสอบหน่วยหากเป็นเช่นนั้น
ขณะนี้ฉันกำลังทำงานในโครงการที่ค่อนข้างใหญ่และฉันได้ใช้ JUnit และ EasyMock เพื่อฟังก์ชั่นการทดสอบหน่วยอย่างกว้างขวาง ตอนนี้ฉันสนใจในการทดสอบประเภทอื่นที่ฉันควรกังวล ในฐานะนักพัฒนาฉันต้องรับผิดชอบเกี่ยวกับสิ่งต่างๆเช่นการทำงานหรือการทดสอบการถดถอยหรือไม่ มีวิธีที่ดีในการรวมสิ่งเหล่านี้เข้าด้วยกันในเครื่องมือเช่น Maven / Ant / Gradle หรือไม่? สิ่งเหล่านี้เหมาะสำหรับผู้ทดสอบหรือปริญญาตรีหรือไม่? มีการทดสอบประเภทอื่น ๆ ที่มีประโยชน์อีกหรือไม่
35 testing 

6
ควรมีการทดสอบหน่วยสำหรับนิพจน์ปกติที่ซับซ้อนหรือไม่
ฉันควรเขียนการทดสอบหน่วยสำหรับนิพจน์ปกติที่ซับซ้อนในใบสมัครของฉันหรือไม่ ในอีกด้านหนึ่งพวกเขาทดสอบได้ง่ายเพราะรูปแบบอินพุตและเอาต์พุตมักจะง่ายและกำหนดไว้อย่างดีและพวกเขามักจะกลายเป็นความซับซ้อนดังนั้นการทดสอบของพวกเขาโดยเฉพาะมีค่า ในทางกลับกัน: พวกมันเองไม่ค่อยเป็นส่วนหนึ่งของส่วนต่อประสานของบางหน่วย อาจเป็นการดีกว่าที่จะทดสอบเฉพาะส่วนต่อประสานและดำเนินการทดสอบ regexes โดยปริยาย แก้ไข: ผมเห็นด้วยกับหมอสีน้ำตาลที่ของเขาในการแสดงความคิดเห็นหมายเหตุที่เป็นกรณีพิเศษนี้หน่วยทดสอบของชิ้นส่วนภายใน แต่เนื่องจากส่วนประกอบภายใน regexes มีคุณสมบัติพิเศษบางอย่าง: regex บรรทัดเดียวนั้นซับซ้อนจริงๆโดยไม่ต้องเป็นโมดูลแยกต่างหาก Regexes แม็พอินพุตกับเอาต์พุตโดยไม่มีผลข้างเคียงใด ๆ และง่ายต่อการทดสอบแยกต่างหาก

6
ฉันจะทดสอบระบบที่วัตถุนั้นยากที่จะเลียนแบบได้อย่างไร
ฉันกำลังทำงานกับระบบต่อไปนี้: Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern เมื่อเร็ว ๆ นี้เรามีปัญหาเมื่อฉันอัปเดตเวอร์ชันของห้องสมุดที่ฉันใช้ซึ่งทำให้เกิดการประทับเวลา (ซึ่งห้องสมุดของบุคคลที่สามกลับมาเป็นlong) ซึ่งจะเปลี่ยนจากมิลลิวินาทีหลังจากยุคเป็นนาโนวินาทีหลังจากยุค ปัญหา: หากฉันเขียนการทดสอบที่จำลองวัตถุของห้องสมุดบุคคลที่สามการทดสอบของฉันจะผิดถ้าฉันทำผิดเกี่ยวกับวัตถุของห้องสมุดบุคคลที่สาม ตัวอย่างเช่นฉันไม่ทราบว่าการประทับเวลาเปลี่ยนความแม่นยำซึ่งส่งผลให้จำเป็นต้องเปลี่ยนการทดสอบหน่วยเนื่องจากการจำลองของฉันคืนข้อมูลผิด นี่ไม่ใช่ข้อผิดพลาดในไลบรารีมันเกิดขึ้นเพราะฉันพลาดบางสิ่งบางอย่างในเอกสาร ปัญหาคือฉันไม่แน่ใจเกี่ยวกับข้อมูลที่มีอยู่ในโครงสร้างข้อมูลเหล่านี้เพราะฉันไม่สามารถสร้างข้อมูลจริงได้หากไม่มีฟีดข้อมูลจริง วัตถุเหล่านี้มีขนาดใหญ่และซับซ้อนและมีข้อมูลจำนวนมากแตกต่างกัน เอกสารสำหรับห้องสมุดบุคคลที่สามไม่ดี คำถาม: ฉันจะตั้งค่าการทดสอบเพื่อทดสอบพฤติกรรมนี้ได้อย่างไร ฉันไม่แน่ใจว่าฉันสามารถแก้ปัญหานี้ได้ในการทดสอบหน่วยเพราะการทดสอบนั้นผิดพลาดได้ง่าย นอกจากนี้ระบบรวมมีขนาดใหญ่และซับซ้อนและง่ายต่อการพลาดบางสิ่งบางอย่าง ตัวอย่างเช่นในสถานการณ์ข้างต้นฉันได้ปรับการจัดการการประทับเวลาในหลายสถานที่อย่างถูกต้อง แต่ฉันพลาดหนึ่งในนั้น ระบบดูเหมือนจะทำสิ่งที่ถูกต้องเป็นส่วนใหญ่ในการทดสอบการรวมระบบของฉัน แต่เมื่อฉันปรับใช้กับการผลิต (ซึ่งมีข้อมูลมากขึ้น) ปัญหาก็ชัดเจน ตอนนี้ฉันไม่มีกระบวนการทดสอบการรวมเข้าด้วยกัน การทดสอบนั้นสำคัญ: พยายามทำให้การทดสอบหน่วยดีเพิ่มการทดสอบเพิ่มเติมเมื่อสิ่งแตกหักจากนั้นปรับใช้กับเซิร์ฟเวอร์ทดสอบของฉันและตรวจสอบให้แน่ใจว่าสิ่งต่าง ๆ ดูมีเหตุผล ปัญหาการประทับเวลานี้ผ่านการทดสอบหน่วยเนื่องจาก mocks ถูกสร้างขึ้นผิดจากนั้นจะผ่านการทดสอบการรวมเนื่องจากไม่ได้ทำให้เกิดปัญหาที่ชัดเจนและทันที ฉันไม่มีแผนกควบคุมคุณภาพ

9
เจ้าหน้าที่ QA จะทดสอบตรรกะการแคชที่พวกเขามองไม่เห็นได้อย่างไร
ฉันเพิ่งนำเลเยอร์แคชไปใช้ในเว็บแอปพลิเคชันของฉันและตอนนี้ฉันสงสัยว่า QA นั้นควรทดสอบอย่างไรเนื่องจากการแคชนั้นโปร่งใสสำหรับผู้ใช้ หนึ่งความคิดที่ฉันมีคือการใส่การบันทึกในวิธีการที่เรียกใช้รหัสที่เติมแคชและบันทึกเมื่อวัตถุถูกดึงออกมาจากแคชและเมื่อมันต้องการนันทนาการจากฐานข้อมูลจากนั้นผู้ทดสอบสามารถดูบันทึกเพื่อดูว่า ตัวอย่างเช่นวัตถุบางอย่างถูกโหลดใหม่จาก db ทุก ๆ 10 นาทีแทนที่จะดูทุกหน้า แต่ทุกคนสามารถแนะนำวิธีปฏิบัติที่ดีกว่าสำหรับสถานการณ์นี้ได้ไหม
33 testing  caching 

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

21
การทดสอบซอฟต์แวร์จำเป็นหรือไม่
ฉันเป็นนักเรียนที่ทำงานเกี่ยวกับ BE (CS) และคำถามของฉันคือ: จำเป็นต้องทำการทดสอบในสาขาซอฟต์แวร์หรือไม่? ถ้าเราสร้างซอฟต์แวร์ด้วยความระมัดระวังเราจะทดสอบทำไม หลังจากการทดสอบเรามั่นใจได้หรือไม่ว่าเราบรรลุเป้าหมายนี้ (ผลิตภัณฑ์ / ซอฟต์แวร์ทำงานตามที่ตั้งใจ) เพราะเราทำการทดสอบเสร็จแล้ว? มันเป็นไปได้? คำถามของฉัน: จำเป็นต้องมีการทดสอบซอฟต์แวร์หรือไม่

4
วิธีที่ถูกต้องในการจัดการกับการแก้ปัญหาการส่งออกใน Java คืออะไร
ในขณะที่โครงการ Java ปัจจุบันของฉันเติบโตขึ้นเรื่อย ๆ ฉันรู้สึกว่าจำเป็นที่จะต้องเพิ่มการดีบักเอาต์พุตในหลาย ๆ จุดของโค้ดของฉัน หากต้องการเปิดใช้งานหรือปิดใช้งานคุณลักษณะนี้อย่างเหมาะสมขึ้นอยู่กับการเปิดหรือปิดเซสชันการทดสอบฉันมักจะใส่private static final boolean DEBUG = falseจุดเริ่มต้นของชั้นเรียนที่การทดสอบของฉันกำลังตรวจสอบอยู่และใช้วิธีนี้เล็กน้อย (เช่น): public MyClass { private static final boolean DEBUG = false; ... some code ... public void myMethod(String s) { if (DEBUG) { System.out.println(s); } } } และไม่ชอบ แต่นั่นไม่ได้ทำให้ฉันสุขใจเพราะแน่นอนว่ามันใช้ได้ แต่อาจมีหลายคลาสเกินไปที่จะตั้งค่า DEBUG ให้เป็นจริงถ้าคุณไม่จ้องมองเพียงสองสามคน ในทางกลับกันฉัน (เหมือน - ฉันคิดว่า …

4
วิธีแก้ปัญหาหรือทดสอบรหัสใหม่อย่างมีประสิทธิภาพเมื่อการตั้งค่าฮาร์ดแวร์เพื่อสร้างข้อบกพร่องเป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะได้รับ?
ฉันทำงานที่ บริษัท ขนาดกลาง (พนักงาน 150 คน, ทีมวิศวกรขนาด 10 ~ คน) และโครงการส่วนใหญ่ของฉันเกี่ยวข้องกับการเชื่อมต่อกับอุปกรณ์ห้องปฏิบัติการ (oscilloscopes, เครื่องวิเคราะห์สเปกตรัมแบบออปติคอล ฯลฯ ) เพื่อวัตถุประสงค์ในการทดสอบแบบกึ่งอัตโนมัติ ฉันพบสถานการณ์ที่แตกต่างกันสองสามอย่างซึ่งฉันไม่สามารถแก้ไขปัญหาหรือทดสอบรหัสใหม่ได้อย่างมีประสิทธิภาพเพราะฉันไม่ได้ตั้งค่าฮาร์ดแวร์ให้ฉันอีกต่อไป ตัวอย่าง 1:การตั้งค่าที่กระบวนการ 10-20 "เบิร์นอิน" ทำงานอย่างอิสระโดยใช้เซ็นเซอร์ประเภทท็อปบัลลังก์ - ฉันสามารถรับเซ็นเซอร์หนึ่งตัวสำหรับการทดสอบและสามารถขโมยวินาทีในการจำลองการเชื่อมต่อทั้งหมดเพื่อจำลอง อุปกรณ์หลายอย่าง (การค้นหาการเชื่อมต่อการสตรีม ฯลฯ ) ในที่สุดข้อผิดพลาดปรากฏขึ้น (และในที่สุดก็ลงเอยอยู่ในอุปกรณ์เฟิร์มแวร์ & ไดรเวอร์) ที่ยากมากที่จะทำซ้ำอย่างถูกต้องด้วยหน่วยเดียว แต่เข้าใกล้ระดับ "โชว์จุก" เมื่อ 10-20 ของอุปกรณ์เหล่านี้ถูกใช้พร้อมกัน สิ่งนี้ยังคงไม่ได้รับการแก้ไขและกำลังดำเนินการอยู่ ตัวอย่างที่ 2:การทดสอบที่ต้องใช้เครื่องวิเคราะห์สเปกตรัมแสงที่มีราคาแพงเป็นองค์ประกอบหลักของมัน อุปกรณ์นั้นค่อนข้างเก่าล้าสมัยตามผู้ผลิตที่ได้รับมาจาก บริษัท ขนาดใหญ่และถูกทำลายโดยทั่วไปและเอกสารเพียงอย่างเดียวคือเอกสารที่ยืดยาว (และไม่เป็นทางการ) ที่ดูเหมือนจะแปลไม่ดี ในระหว่างการพัฒนาเริ่มต้นฉันสามารถเก็บอุปกรณ์ไว้ที่โต๊ะทำงานของฉันได้ แต่ตอนนี้มันเชื่อมโยงกันทั้งทางร่างกายและตามกำหนดเวลาในระหว่างการทดสอบตลอด 24 ชั่วโมงทุกวัน …

7
ฉันควรทดสอบวิธีที่สืบทอดมาหรือไม่
สมมติว่าฉันได้เรียนผู้จัดการมาจากชั้นฐานของพนักงานและลูกจ้างมีวิธีgetEmail ()ที่สืบเชื้อสายมาจากผู้จัดการ ฉันควรทดสอบว่าพฤติกรรมของเมธอด getEmail ()ของผู้จัดการจริงๆแล้วเหมือนกับพนักงานหรือไม่? ในขณะที่การทดสอบเหล่านี้เขียนขึ้นพฤติกรรมจะเหมือนกัน แต่แน่นอนในบางจุดในอนาคตบางคนอาจแทนที่วิธีนี้เปลี่ยนพฤติกรรมของมันและทำให้แอปพลิเคชันของฉันพัง อย่างไรก็ตามมันดูค่อนข้างแปลกที่จะทดสอบว่าไม่มีการแทรกแซงของโค้ด (โปรดทราบว่าวิธีการทดสอบManager :: getEmail ()ไม่ได้ปรับปรุงการครอบคลุมโค้ด (หรือแน่นอนการวัดคุณภาพโค้ดอื่น ๆ (?)) จนกระทั่งManager :: getEmail ()ถูกสร้าง / เขียนทับ) (หากคำตอบคือ "ใช่" ข้อมูลบางอย่างเกี่ยวกับวิธีจัดการการทดสอบที่ใช้ร่วมกันระหว่างคลาสพื้นฐานและคลาสที่ได้รับจะมีประโยชน์) การกำหนดคำถามที่เทียบเท่า: หากคลาสที่ได้รับสืบทอดวิธีการจากคลาสพื้นฐานคุณจะแสดง (ทดสอบ) อย่างไรว่าคุณคาดหวังให้วิธีการสืบทอดมา: ประพฤติในแบบเดียวกับที่ฐานทำในตอนนี้ (ถ้าพฤติกรรมของการเปลี่ยนแปลงฐานพฤติกรรมของวิธีการที่ได้รับไม่ได้) ประพฤติตนในลักษณะเดียวกับฐานตลอดเวลา (หากพฤติกรรมของคลาสฐานเปลี่ยนไปพฤติกรรมของคลาสที่ได้รับก็เปลี่ยนไปเช่นกัน) หรือ ประพฤติ แต่มันต้องการ (คุณไม่สนใจเกี่ยวกับพฤติกรรมของวิธีนี้เพราะคุณไม่เคยเรียกมันว่า)

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

9
ทฤษฎี TDD เท่านั้น
น้อยกว่าหนึ่งปีที่ผ่านมาฉันโชคดีที่สามารถหยุดงานได้ 9 เดือน ฉันตัดสินใจว่าในเวลานั้นฉันจะฝึกฝนทักษะ C # ของฉัน ฉันเริ่มทำงานหลายโครงการและบังคับให้ตัวเองต้องติดตาม TDD มันเป็นกระบวนการที่ค่อนข้างกระจ่างแจ้ง มันยากในตอนแรก แต่เมื่อเวลาผ่านไปฉันเรียนรู้วิธีเขียนโค้ดที่ทดสอบได้มากขึ้น (ซึ่งกลายเป็นว่ามีแนวโน้มที่จะเป็นรหัสที่มั่นคงมากขึ้น) และในกระบวนการฉันก็เพิ่มทักษะการออกแบบ OO ของฉัน ตอนนี้ฉันกลับมาทำงานแล้วและฉันสังเกตเห็นบางสิ่งแปลก ๆ ฉันไม่ต้องการติดตาม TDD ฉันพบว่า TDD ทำให้ฉันช้าลงและทำให้ยากต่อการออกแบบแอปพลิเคชั่นที่สะอาด ฉันได้ใช้แนวทางที่แตกต่างเล็กน้อย (หนาแน่น) แทน เลือกชิ้นงานตามแนวตั้ง พัฒนาต้นแบบการทำงาน Refactor จนกว่าทุกอย่างจะดีและเป็นระเบียบ เอนหลังชื่นชมความสวยงามและรหัสที่ทดสอบได้ที่ฉันเขียน คุณอาจสังเกตเห็นว่าขั้นตอนที่ 1 ไม่ได้ "กำหนดพื้นผิวสาธารณะของเป้าหมายการทดสอบของฉัน" และขั้นตอนที่ 2 ไม่ใช่ "ทดสอบ bejesus จากพื้นผิวสาธารณะดังกล่าว" คุณอาจสังเกตเห็นว่าไม่มีขั้นตอนใดที่เกี่ยวข้องกับการทดสอบ ฉันกำลังเขียนโค้ดที่สามารถทดสอบได้ แต่ฉันยังไม่ได้ทดสอบ ... ตอนนี้ฉันต้องการทำให้ชัดเจนว่าจริง ๆ แล้วฉันไม่ได้ทำการทดสอบใด ๆ รหัสที่ฉันกำลังเขียนนั้นใช้งานได้ …

4
เราควรจะทำการทดสอบบั๊กเมื่อทำการแก้ไขหรือไม่?
เมื่อแก้ไขข้อผิดพลาดมันเป็นกำลังใจที่ฉันทำงานเพื่อเขียนการทดสอบครั้งแรกที่ล้มเหลวด้วยข้อผิดพลาดที่กำหนดและจากนั้นเพื่อแก้ไขรหัสจนกว่าการทดสอบผ่าน สิ่งนี้เป็นไปตามแนวทางปฏิบัติของ TDD และควรจะเป็นแนวปฏิบัติที่ดี แต่ฉันสังเกตเห็นว่ามีแนวโน้มที่จะสร้างแบบทดสอบความลับที่ใกล้เคียงกับการนำไปใช้จริง ตัวอย่างเช่นเรามีปัญหาเมื่อมีการส่งงานไปถึงสถานะที่แน่นอนถูกยกเลิกและลองใหม่ ในการทำซ้ำข้อผิดพลาดนี้การทดสอบครั้งใหญ่ถูกเขียนด้วยการซิงโครไนซ์เธรดในนั้นมีการเยาะเย้ยและสิ่งต่าง ๆ มากมาย ... มันทำงานได้ แต่ตอนนี้เมื่อฉันทำการปรับรหัสใหม่ฉันพบว่ามันดึงดูดมาก มันจะต้องใช้งานจำนวนมาก (อีกครั้ง) เพื่อให้พอดีกับการออกแบบใหม่ และเป็นเพียงการทดสอบคุณสมบัติเล็ก ๆ แห่งหนึ่งในกรณีเฉพาะ ดังนั้นคำถามของฉัน: คุณจะทดสอบข้อบกพร่องที่ทำซ้ำได้อย่างไร? คุณจะหลีกเลี่ยงการสร้างสิ่งต่าง ๆ ที่ทดสอบการใช้งานและเจ็บ refactoring และการอ่านได้อย่างไร
29 testing  tdd 

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.