ใครเป็นผู้พัฒนาระบบทดสอบ

23

ฉันทำงานในพื้นที่ขององค์กรในช่วง 4 ปีที่ผ่านมาและสังเกตว่าโดยทั่วไปแล้วองค์กรต่าง ๆ ไม่เอื้อต่อสภาพแวดล้อมในการพัฒนารูปแบบการทดสอบครั้งแรก โครงการมักจะคงที่ค่าใช้จ่ายคงที่ระยะเวลาและลักษณะน้ำตก การทดสอบหน่วยใด ๆ หากทำได้เลยมักเกิดขึ้นหลังจากการพัฒนาในเฟส QA และดำเนินการโดยทีมอื่น

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

ร้านค้า บริษัท และลูกค้าประเภทใดที่การพัฒนาโดยอาศัยการทดสอบนั้นทำงานได้ดีที่สุด? โครงการประเภทใดที่เอื้อต่อ TDD

— Edward J. Stembler
แหล่งที่มา

5

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

— bzlm

2

@bzlm สองสถานการณ์ที่การทดสอบ "การจ่ายเงิน" เป็นครั้งแรกที่ถูกต้อง ในกรณีที่ผู้ใช้คาดหวังว่าต้นแบบจำนวนมากที่มีการทำงานซ้ำจำนวนมากในทุกขั้นตอนเพราะพวกเขาไม่แน่ใจว่าผลลัพธ์ที่ดีที่สุดคืออะไรและค่าใช้จ่ายในการทำให้ผู้พัฒนาจำลองพฤติกรรมภายนอกอย่างถูกต้องเพียงพอที่จะมีการทดสอบที่ถูกต้อง ไม่จำเป็นต้องเป็นสถานที่ที่ดี แต่ทั้งคู่ก็สามารถอยู่ร่วมกันได้ในองค์กร

— Bill

6

ข้อสมมติฐานสองข้อที่มีข้อบกพร่องประการแรก TDD นั้นมีราคาแพงกว่า เปรียวน้อยราคาแพงกว่าน้ำตกเพราะคุณไม่ได้ใช้เวลาในการสร้างสิ่งที่ผิดและ TDD มีราคาแพงน้อยกว่าการทดสอบที่ผ่านมาเพราะคุณไม่ได้ใช้เวลาในการสร้างสิ่งที่จะไม่ได้ทำงาน ประการที่สอง TDD นั้นไม่ได้หมายความว่าคุณสามารถ "เริ่มการพัฒนาได้ทันที" ด้วย TDD คุณจะเริ่มพัฒนาได้ทันที TDD ไม่ได้หมายความว่าคุณจะต้องทำการทดสอบทั้งหมดก่อน หมายความว่าคุณเขียนการทดสอบครั้งแรกก่อน ไม่มีใครอยากทำ TDD ในแบบที่คุณดูเหมือนจะเข้าใจรวมถึงผู้ใช้ TDD

— Rein Henrichs

@Rein: สาธุพี่ชาย !!

— IAbstract

คำถามนี้ไม่สนับสนุนคำตอบของสไตล์รายการโดยไม่มีเกณฑ์จริงว่าเมื่อใดที่คำตอบนั้น "ถูกต้อง"? คำถามประเภทนี้ไม่ถือว่าไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของ StackExchange เพราะเราจบด้วยคำตอบ 16+ คำถามแต่ละข้อตอบคำถาม แต่ไม่มีคำตอบใดที่ตรงกับ "ทางออก" ที่มีอยู่จริงหรือไม่?

— นาธานซี Tresch

33

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

— mpenrow
แหล่งที่มา

19

ฉันยกระดับคุณไม่เฉพาะเจาะจงเพราะคุณทำ TDD แต่เพราะคุณทำในสิ่งที่คุณคิดว่าถูกต้องโดยไม่ต้องขออนุญาต นั่นคือสิ่งที่มืออาชีพทำ

— Sergio Acosta

24

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

— luis.espinal

6

อย่าใช้สิ่งที่ฉันพูดเป็นคำนิยามของสิ่งที่เป็นมืออาชีพ และอย่าคาดหวังว่าการแสดงความคิดเห็นสองประโยคนั้นเป็นการรักษาเชิงลึกของเรื่องที่ซับซ้อน ขอโทษ

— Sergio Acosta

22

ช่างเป็นมืออาชีพทำในสิ่งที่ถูกต้องโดยไม่ต้องบอกให้ทำ " ดีขึ้นหรือไม่ นั่นคือสิ่งที่ฉันหมายถึง

— Sergio Acosta

3

@CraigTp - มีทั้งบทในหนังสือ Peopleware: โครงการที่มีประสิทธิผลและทีมงานที่พูดกับ "ระเบียบวิธี" ที่กล่าวว่ามันฆ่าแรงจูงใจและดับเปลวไฟภายในได้ถ้า "ระเบียบวิธี" แน่นเกินไปเพราะมันลบ เสรีภาพของแต่ละบุคคลสมมติว่าพวกเขาจะเลือกอย่างไม่เป็นระบบ สภาพแวดล้อมการทำงานที่ดีนั้นเป็นสิ่งที่บุคคลสามารถตัดสินใจได้ว่าเขาตัดสินดีที่สุดสำหรับ "ดีกว่า" ถ้ามันล้มเหลวจากนั้นปรับตัว แต่อย่างอื่นให้บุคคลเป็นศูนย์กลางของการตัดสินใจไม่ใช่ "ระเบียบวิธี"

— JF Dion

17

วันนี้เจ้านายของฉันเลี้ยงดูฉันอย่างดีฉันคิดว่าฉันจะขโมยมันเหมือนเขาขโมยจากคนอื่น

"คุณคาดหวังว่าช่างไม้จะวัดกระดานก่อนที่เขาจะตัดมันหรือ"

ฉันเข้าเรียนที่ร้านขายไม้ในโรงเรียนมัธยมและทำงานก่อสร้างผ่านโรงเรียน มนต์ของเรามักจะ "วัดสองครั้งตัดครั้งเดียว" ซึ่งตามมาด้วยการเสียดสี "ฉันตัดมันแล้วตัดอีกครั้งและมันก็ยังสั้นเกินไป!"

— MIA
แหล่งที่มา

ฉันไม่สามารถพูดได้ว่าฉันเห็นด้วยกับการเปรียบเทียบ มันไม่ได้เข้าใกล้ความซับซ้อนในการพัฒนา แต่อีกครั้งฉันไม่เชื่อใน TDD อย่างเต็มที่

— xil3

@ xil3 ใช่การเปรียบเทียบไม่ดี มันน่าจะมากกว่า "การวัดโดยประมาณไม่ตรวจสอบหลังจากแล้วตัด" แต่คำตอบก็ยังดีมาก

— BЈовић

12

หากคุณทำการทดสอบในภายหลังคุณสร้างการทำงานซ้ำเนื่องจากรหัสที่คุณจะเขียนนั้นยากที่จะทดสอบ เมื่อคุณทำการทดสอบครั้งแรกหรือแม้กระทั่งการทดสอบซอฟต์แวร์ที่คุณสร้างขึ้นจะง่ายต่อการทดสอบ องค์กรที่สร้างการทดสอบหน่วยหลังจากเขียนรหัสการผลิตเพื่อให้เป็นไปตามรายการตรวจสอบเป็นการสิ้นเปลืองความพยายาม

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

คุณสามารถทดสอบรหัสไดรฟ์แม้ในโครงการน้ำตกมันเป็นวินัยทางวิศวกรรมไม่ใช่เทคนิคการจัดการโครงการ

ฉันไม่ใช่คนคลั่งไคล้ TDD แต่อย่างใด แต่มันสอนให้คุณรู้มากมายเกี่ยวกับการออกแบบซอฟต์แวร์

— Ryan Roberts
แหล่งที่มา

1

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

— elysium กลืนกิน

@deveded elysium: ฉันเห็นด้วย: การทดสอบการเขียนครั้งแรกไม่ใช่วิธีเดียวที่จะเขียนโค้ดที่สามารถทดสอบได้

— Giorgio

6

ทนกับฉันเช่นนี้จะมีรสชาติ. Net อย่างชัดเจน: p

เกี่ยวกับประเภทของโครงการที่คล้อยตามแนวทางการทดสอบครั้งแรกสิ่งที่ฉันควรระวัง:

คุณจัดการกับรหัสฐานที่มีอยู่? บ่อยครั้งที่มันมีราคาแพงอย่างมากในการติดตั้งชุดทดสอบใหม่รับความคิดว่าหนี้ทางเทคนิคที่ได้รับมานั้นมีจำนวนเท่าใด
แพลตฟอร์มและกรอบบางอย่างนั้นมีการทดสอบที่ไม่เป็นมิตร ประสบการณ์เมื่อเร็ว ๆ นี้ที่ทำให้ฉันคิดถึง - SharePoint ตัวอย่างเช่น TDD นั้นยากมาก (แต่ไม่เป็นไปไม่ได้) สำหรับสิ่งเช่นนี้คุณอาจต้องใช้ผลิตภัณฑ์ตัวแยกเชิงพาณิชย์เช่น TypeMock สามารถช่วยได้
วิธีการใช้งานบางอย่างให้ผลดีกว่า TDD ตัวอย่างเช่น ASP.Net ที่มีการใช้โค้ด - ไม่สามารถทดสอบได้ ASP.Net MVC - ทดสอบได้ Silverlight ที่มีโค้ดล้าหลัง - ไม่สามารถทดสอบได้ Silverlight พร้อม MVVM - ทดสอบได้

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

+1 กับความคิดเห็นของ mpenrow เกี่ยวกับการไม่บอก mgmt หากพวกเขามีปัญหากับมัน: p

— HY
แหล่งที่มา

1

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

— Wayne Molina

6

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

คุณสามารถทำธุรกิจที่ดีได้:

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

... และเพียงจำ; สิ่งที่สำคัญที่สุดที่คุณสามารถทำได้คือนำโดยตัวอย่าง หากคุณใช้ TDD อย่างคร่าวๆคุณควรลงทุนชั่วโมงพิเศษเพื่อให้ดีขึ้น เมื่อคุณมีความเชี่ยวชาญกำลังเพียงแค่เริ่มต้นทำมันในที่ทำงาน (จะผู้จัดการของคุณจริงๆบ่นว่าคุณเขียนทดสอบ?) ต่อสู้หนึ่งครั้งในแต่ละครั้งและทำตามขั้นตอนต่อไป - ไปที่ shebang ทั้งหมดจะทำให้เกิดความล้มเหลวและความผิดพลาดจะตกอยู่กับคุณหากคุณพยายามอย่างหนัก

— STW
แหล่งที่มา

2

ฉันทำ. มันเป็นวิธีการพัฒนาที่ฉันชอบและฉันทำงานให้กับ บริษัท เงินทุนขนาดใหญ่ที่มีความสุขสำหรับฉันในการทำงานในแบบที่ฉันเห็นว่าเหมาะสมตราบใดที่ฉันพบกับกำหนดเวลาและสร้างรหัสคุณภาพ ทำอย่างถูกต้องทดสอบการพัฒนาครั้งแรกไม่จำเป็นต้องใช้เวลานานกว่าการทดสอบหลังจากการพัฒนาและอย่าลืมผลตอบแทนการทดสอบอื่น ๆ ของการพัฒนาครั้งแรกที่มีข้อบกพร่องน้อยลงจากการทดสอบระบบในภายหลัง

— คริสอัศวิน
แหล่งที่มา

2

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

หากคุณอธิบายว่า "ฉันกำลังเขียนบททดสอบ" ดังนั้นพลังที่สามารถพูดได้ว่า "โอ้เราสามารถกำจัดมันได้!" แต่ถ้าคุณไม่บอกใครคุณก็ยังคงมีการทดสอบที่เหลืออยู่ของกระบวนการเข้ารหัส

การเขียนโปรแกรมเป็นมากกว่าการพิมพ์คำแถลงการทำงานลงในโปรแกรมแก้ไข หากผู้คนไม่สามารถจัดการสิ่งนั้นได้จงป้องกันพวกเขาจากความจริงนี้จนกว่าพวกเขาจะพร้อมรับมือกับมัน "พร้อมที่จะจัดการกับมัน" ในกรณีนี้หมายความว่าเมื่อคุณมีโครงการที่เสร็จสมบูรณ์หรือสองโครงการเสร็จตรงเวลาด้วยรหัสที่มั่นคงเชื่อถือได้และใช่แล้วดูสิคุณมีการทดสอบหน่วยด้วยเช่นกัน

— Andy Lester
แหล่งที่มา

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

— จอร์โจ

2

น่าเศร้าที่จะบอกว่าฉันยังไม่ได้รับโอกาสที่จะใช้มันในความรู้สึกแรกของการทดสอบแบบดั้งเดิมอย่างแท้จริงดังนั้นฉันจึงไม่สามารถพูดว่า "ฉัน! ฉัน! ฉันทำมันได้!" ฉันสมมติว่าคำถามนี้ถามว่า "อุตสาหกรรมใดบ้างที่ บริษัท ใช้ TDD ทั่วกระดาน" แทนที่จะเป็น "ใคร ๆ ก็สามารถแอบ TDD เข้ามาในชีวิตประจำวันได้" ฉันยอมรับว่านักพัฒนาแต่ละคนสามารถทำ TDD ได้อย่างสมบูรณ์โดยไม่บังคับให้ทั้งกลุ่มทำมันฉันไม่คิดว่านั่นเป็นประเด็นคำถาม

ความประทับใจของฉันจากการฟังรอบอุตสาหกรรมคือคุณมีแนวโน้มที่จะเห็น TDD ในกลุ่มพัฒนาส่วนใหญ่ใน บริษัท ในสถานการณ์ที่:

ไม่มีฐานรหัสขนาดใหญ่ที่มีอยู่ก่อนที่จะเริ่ม TDD
บริษัท มีขนาดไม่ใหญ่มากดังนั้นจึงไม่มี "ย้อนกลับที่เราเคยทำมาแล้ว"
บริษัท ไม่มีการซื้อจำนวนมากในกระบวนการที่เป็นทางการ นั่นไม่ได้หมายความว่าคุณไม่สามารถใช้ TDD ในตัวอย่างเช่น บริษัท ที่ได้รับการรับรอง CMMI - แต่ถ้าคุณมีกระบวนการที่ไม่ใช่ TDD การรับกระบวนการทั้งหมดที่คุณตรวจสอบด้วย CMMI ที่ได้รับการปรับปรุงนั้นอาจเป็นการลงทุนที่สำคัญ
การทดสอบสามารถเขียนสคริปต์ - นี่คือฐานรหัสที่ซับซ้อนที่สุดเนื่องจากแม้ว่าคุณจะไม่สามารถสคริปต์เลเยอร์ที่ใกล้เคียงที่สุดให้กับผู้ใช้ได้อย่างง่ายดายคุณสามารถสคริปต์ภายในบางอย่างได้ แต่ฉันเห็นสถานการณ์ที่มีตัวเลือกที่ได้รับการพัฒนาอย่างดีสำหรับการทดสอบระบบอัตโนมัติเป็นจุดที่ดีที่สุดสำหรับ TDD เนื่องจากมันขึ้นอยู่กับการทดสอบทั้งแบตเตอรี่ที่ทดสอบซ้ำและไม่ทำลายซึ่งคุณต้องการคำติชมเกี่ยวกับการทดสอบอย่างรวดเร็ว ความคิดของฉันคือแอพพลิเคชั่นเว็บแบบสแตนด์อโลนเป็นเป้าหมาย TDD ที่ดีระบบที่มีการรวม COTS หรืออินพุตที่ไม่ได้อิง GUI อาจเป็นเรื่องยุ่งยาก
ระบบในสถานะที่ไม่ได้เป็นต้นแบบ จะเป็นการดีที่จะมีรุ่นใหญ่ต่อไปหลังจากต้นแบบ - ซึ่งการพิสูจน์แนวคิดเสร็จสิ้นแล้วและโครงการได้รับเงินทุน แต่ทุกคนรู้ว่าความพยายามครั้งต่อไปจะต้องกระโดดในคุณภาพ
ผู้มีส่วนได้เสียที่ลงทุนในกระบวนการ

— bethlakshmi
แหล่งที่มา

2

+1 สำหรับจุดแรกเพียงอย่างเดียว ในการทำ TDD อย่างถูกต้องคุณจะไม่สามารถทำ codebase ที่มีขนาดใหญ่ได้โดยไม่ต้องใช้ TDD (หรือทดสอบโดยทั่วไป) หากคุณทำเช่นนั้นคุณอาจจะไม่สามารถเพิ่มได้เนื่องจากคุณต้อง A) ติดตั้งแอปพลิเคชันทั้งหมดใหม่เพื่อรองรับการทดสอบเนื่องจากมีแนวโน้มว่าจะไม่ได้เขียนด้วย abstractions ที่เหมาะสมในการทดสอบหน่วยหรือ B) เขียนซ้ำ สิ่งทั้งหมดตั้งแต่เริ่มต้นและใช้ TDD ตั้งแต่เริ่มต้น

— Wayne Molina

2

ฉันเคยลองแล้วที่เป็นไปได้ - แต่ฉันคิดว่ามันเป็นเรื่องของสภาพแวดล้อมขององค์กรที่คุณพบว่าตัวเองเป็นจริง ฉันทำงานในอุตสาหกรรมเกมเป็นเวลาหลายปี (ในฐานะศิลปิน btw) และไม่มีแนวคิดของ TDD - เป็นวิธีการควบคุมคุณภาพที่ดุร้าย ฉันย้ายไปที่การพัฒนาเว็บและยังไม่ได้ทำงานกับเอเจนซี่ที่ได้รับการยอมรับอย่างเป็นทางการ (หรือความรู้เกี่ยวกับ ... ) การทดสอบหน่วย / TDD เช่นเดียวกันสำหรับคนรอบข้างส่วนใหญ่ในอุตสาหกรรมที่ทำงานในสาขาวิชาที่หลากหลาย

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

เนื่องจากหนังสือเช่นDeath Marchชี้ไปที่ปรากฏการณ์ที่แพร่หลายเช่นอุตสาหกรรมที่เต็มไปด้วยการพัฒนา "ก้าวร้าว" และ "ก้าวสำคัญ" - ฉันเดิมพันว่า TDD อาจหายากนอก บริษัท ที่เพิ่งเริ่มต้นได้รับเงินสนับสนุนหรือร้านค้าองค์กรขนาดใหญ่ ไม่ใช่ว่าคนที่นั่นไม่เชื่อในคุณค่าของ TDD - แต่มันเป็นนามธรรมเกินกว่าจะขายให้กับลูกค้า

— sunwukung
แหล่งที่มา

2

ฉันพยายามเข้าสู่ TDD ด้วยตัวเอง ฉันคิดว่าตราบใดที่คุณติดตามเส้นทางที่คุณรู้อยู่ทุกวันมันค่อนข้างง่าย แต่ฉันไม่สามารถคาดหัวการทดสอบสำหรับส่วน UI หรือเมื่อคุณต้องหาวิธีแก้ไขปัญหาใหม่ที่คุณไม่เคยพบมาก่อน หรือใช้กรอบที่คุณไม่รู้

ดังนั้นฉันเดาว่าคุณต้องทำ LearningTests บางอย่างแยกการพิสูจน์แนวคิดและเขียนใหม่ในภายหลังเป็นต้นหรือฉันผิด

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

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

— Carsten
แหล่งที่มา

1

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

— อเล็กซาน
แหล่งที่มา

ข้อได้เปรียบมาในภายหลังเพราะคุณมักจะบันทึกพฤติกรรมเป็นรหัส การเปลี่ยนแปลงรหัสใด ๆ จะต้องผ่านการทดสอบหรือพฤติกรรมที่เปลี่ยนไป

1

ฉันทำมัน. ความคืบหน้าของเรื่องราวของผู้ใช้ของเราถูกติดตามบนกระดาน Kanban ซึ่งมี"มีการทดสอบหรือไม่" คอลัมน์ทางซ้าย (ต้นน้ำ) ของการพัฒนา

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

การวนคำติชมการทดสอบการยอมรับนั้นใช้เวลานาน: อาจใช้เวลาหลายวันกว่าจะเสร็จสิ้นเรื่องราว การพัฒนามีลูปข้อเสนอแนะ TDD สั้นลง

"[... ไม่มีรูปแบบการทดสอบครั้งแรก ... ] คล้ายกับ Agile มากกว่า ... "

นี่คือการบิดเบือนความจริงที่สมบูรณ์ของ Agile คำจำกัดความของการทำคือองค์ประกอบสำคัญของ Agile และหนึ่งในเสาหลักที่วางไว้คือการทดสอบการยอมรับอัตโนมัติ (สิ่งที่ฉันอธิบายไว้ข้างต้นเป็นวิธีหนึ่งที่จะทำได้) หากใช้ Programming Extreme (XP) เป็นวิธีการใช้งาน Agile กำหนด ATDD / BDD และ TDD

— azheglov
แหล่งที่มา

1

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

โดยพื้นฐานแล้วฉันทำเมื่อความซับซ้อนของข้อกำหนดหมายถึงฉันอาจหลงทางในโค้ดได้

มันเป็นนิสัยที่ยากที่จะเริ่มต้นและไม่จำเป็นต้องมีการจัดการซื้อ แต่เมื่อการทดสอบของคุณเริ่มแบ่งครึ่งทางผ่านการพัฒนามันสามารถช่วยชีวิต!

— johnc
แหล่งที่มา

1

ฉันอยากถามคำถามนี้เพื่อดูว่ามี บริษัท กี่แห่งที่ฝึกซ้อม TDD

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

ที่ บริษัท สุดท้ายที่ฉันทำงานให้กับ (ผู้เผยแพร่ทางวิชาการด้านมนุษยศาสตร์และวิทยาศาสตร์ออนไลน์) เรารู้ว่าเราจำเป็นต้องฝึกฝน TDD แต่เราไม่เคยไปถึงที่นั่น ในการป้องกันของเราเรามีฐานรหัส 250k ดังนั้นการเพิ่มการทดสอบลงในฐานรหัสที่ไม่สามารถทดสอบได้ของขนาดนั้นรู้สึกไม่สามารถเอาชนะได้ (ฉันรู้สึกผิดที่พิมพ์ตอนนี้!) แม้แต่ที่ดีที่สุดของเราทำผิดพลาด

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

เราขยายทีมงาน QA ของเราชั่วคราว (จากคนหนึ่งอาจเป็นสองคนครึ่งโหลหรือมากกว่านั้น) เพื่อทดสอบแพลตฟอร์มก่อนที่จะมีการเปิดตัว มันใช้เวลาค่อนข้างแพงทั้งในด้านการเงินและทางการเงินบางรุ่นอาจใช้เวลาสามเดือนในการ 'ทดสอบ' แม้แล้วเราก็รู้ว่าเรากำลังจัดส่งด้วยปัญหาพวกเขาก็ไม่ได้ 'บล็อค' หรือ 'สำคัญ' เพียงแค่ 'ลำดับความสำคัญสูง'

หากคุณได้ประสบการณ์ในเชิงพาณิชย์ปีคุณจะชื่นชมว่าทุก บริษัท อ้างที่สำคัญงานแล้วประดิษฐ์ระดับความสำคัญสูงกว่านั้นและมีแนวโน้มมากที่สุดคนหนึ่งดังกล่าวข้างต้นที่มากเกินไป - โดยเฉพาะอย่างยิ่งเมื่อมีคนจากข้างต้นจะผลักดันคุณลักษณะ / แก้ไขข้อผิดพลาด ฉันเชือนแช ...

ฉันดีใจที่ได้รายงานว่าฉันกำลังฝึกซ้อม TDD ใน บริษัท ปัจจุบันของฉัน (การสื่อสารโทรคมนาคมเว็บและบ้านพัฒนาแอพมือถือ) ควบคู่กับ Jenkins CI เพื่อให้รายงานการวิเคราะห์แบบคงที่อื่น ๆ (การครอบคลุมรหัสเป็นประโยชน์มากที่สุดหลังจากยืนยันชุดทดสอบผ่าน) . โครงการที่ฉันใช้ TDD เป็นระบบการชำระเงินและระบบประมวลผลกริด

สนามขาย ...

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

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

ผู้เขียนโปรแกรมที่ไม่ใช่ (มัก) จะไม่มีความเข้าใจด้านนี้และดังนั้น TDD จึงไม่ถือค่ามากนักและถูกมองว่าเป็นทางลัดที่ใช้แล้วทิ้งไปจนถึงวันที่วางจำหน่ายก่อนหน้านี้

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

ในความคิดของฉันอุตสาหกรรมการพัฒนาซอฟต์แวร์ (โดยรวม) ในปัจจุบันขาดความจริงที่ว่าการทดสอบซอฟต์แวร์ของคุณไม่ใช่บรรทัดฐาน

ลองนึกภาพสิ่งนี้ในอุตสาหกรรมอื่น ๆ : ทางการแพทย์, การบิน, รถยนต์, เครื่องสำอางค์, ของเล่นนุ่ม ๆ , เครื่องดื่มแอลกอฮอล์ ฯลฯ ฉันขอคู่หมั้นของฉันตั้งชื่ออุตสาหกรรมที่พวกเขาไม่ได้ทดสอบผลิตภัณฑ์และเธอทำไม่ได้!

บางทีมันอาจไม่ยุติธรรมที่จะบอกว่าไม่มีการทดสอบเกิดขึ้นเพราะมันเป็น ... แต่ใน บริษัท ที่ไม่มีการทดสอบอัตโนมัติมันเป็นกระบวนการที่ต้องใช้คน / คน (อ่าน clunky และมักจะเกิดข้อผิดพลาดได้ง่าย)

จุดหนึ่งที่ฉันจะโต้แย้งในคำถามของคุณ ...

พวกเขาต้องการให้การพัฒนาเริ่มต้นทันทีหรือหลังจากการออกแบบระยะสั้น คล้ายกับ Agile

การเป็น "เปรียว" ไม่ได้กำหนดให้ดำเนินการต่อโดยไม่มีการทดสอบสมาชิกรายแรกที่อยู่ในagilemanifesto.orgคือKent Beckผู้สร้าง XP และ TDD!

ฉันขอแนะนำหนังสือสองเล่มถ้าคุณสนใจ TDD หรือแค่ยังไม่ได้อ่านและเป็นโปรแกรมเมอร์ที่กระตือรือร้น

การพัฒนาซอฟต์แวร์เชิงวัตถุเชิงนำโดยการทดสอบ

Clean Code - Robert C Martin ("ลุงบ็อบ") ซีรี่ส์

หนังสือสองเล่มนี้ชมเชยกันและย่อความรู้สึกลงในหลาย ๆ หน้า

ขอบคุณที่ถามคำถามนี้ :)

— Greg K
แหล่งที่มา

0

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

— P Shved
แหล่งที่มา

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

— Frank Shearar

0

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

โค้ด 73,000 บรรทัด
บรรทัดการทดสอบ 91,378,600 บรรทัด

ดูhttp://www.sqlite.org/testing.html

— Paul D. Waite
แหล่งที่มา