มันคือความโกรธในปัจจุบัน "ทุกคน" แนะนำให้มัน ในตัวของมันเองและทำให้ฉันสงสัย
มีข้อเสียอะไรบ้างที่คุณพบเมื่อทำการพัฒนาแบบทดสอบก่อน ฉันกำลังมองหาประสบการณ์ส่วนตัวจากผู้ปฏิบัติงานที่มีความรู้ - ฉันสามารถอ่าน musings สมมุติของหนึ่งร้อย wannabes ที่อื่น ๆ บนอินเทอร์เน็ต
ฉันถามไม่ได้เพราะฉันกำลังมองหาที่จะเกลียด TDD แต่เป็นหน้าที่ของฉันในการปรับปรุงกระบวนการพัฒนาซอฟต์แวร์และยิ่งเราสามารถเรียนรู้เกี่ยวกับปัญหาที่ผู้คนพบมากขึ้นโอกาสที่เราจะปรับปรุงกระบวนการดีขึ้น
คำตอบ:
มีค่อนข้างน้อย แต่ข้อดีไกลเกินดุลข้อเสีย
มีเส้นโค้งการเรียนรู้ที่สูงชัน
นักพัฒนาหลายคนคาดหวังว่าพวกเขาจะมีประสิทธิภาพด้วยการเขียนโปรแกรมทดสอบครั้งแรกตั้งแต่วันแรก น่าเสียดายที่มันใช้เวลานานมากในการรับประสบการณ์และโปรแกรมด้วยความเร็วเท่าเดิม คุณไม่สามารถหลีกเลี่ยงได้
จะเจาะจงมากขึ้นมันง่ายมากที่จะเข้าใจผิด คุณสามารถทดสอบได้อย่างง่ายดาย (ด้วยความตั้งใจดีมาก) ซึ่งอาจยากต่อการบำรุงรักษาหรือทดสอบสิ่งที่ผิด เป็นการยากที่จะยกตัวอย่างที่นี่ - ปัญหาประเภทนี้จะต้องใช้ประสบการณ์เพื่อแก้ไข คุณต้องมีความรู้สึกที่ดีในการแยกข้อกังวลและการออกแบบเพื่อการทดสอบ คำแนะนำที่ดีที่สุดของฉันที่นี่คือทำการจับคู่กับคนที่รู้จัก TDD ได้ดีจริงๆ
คุณเขียนโค้ดล่วงหน้ามากขึ้น
การทดสอบก่อนหมายความว่าคุณไม่สามารถข้ามการทดสอบ (ซึ่งดี) และหมายความว่าคุณจะจบการเขียนโค้ดล่วงหน้าเพิ่มเติม นี่หมายถึงเวลามากขึ้น คุณไม่สามารถหลีกเลี่ยงได้อีก คุณจะได้รับรางวัลด้วยรหัสที่ง่ายต่อการบำรุงรักษาขยายและลดข้อบกพร่องโดยทั่วไป แต่ใช้เวลา
สามารถขายยากให้กับผู้จัดการ
โดยทั่วไปผู้จัดการซอฟต์แวร์จะเกี่ยวข้องกับช่วงเวลาเท่านั้น หากคุณเปลี่ยนไปใช้การเขียนโปรแกรมทดสอบครั้งแรกและคุณใช้เวลา 2 สัปดาห์ในการกรอกคุณสมบัติแทนหนึ่งรายการพวกเขาจะไม่ชอบมัน นี่คือการต่อสู้ที่คุ้มค่าแน่นอนและผู้จัดการหลายคนรู้แจ้งเพียงพอที่จะได้รับ แต่มันอาจเป็นยอดขายที่ยากลำบาก
สามารถขายยากให้กับนักพัฒนาเพื่อน
เนื่องจากมีช่วงการเรียนรู้ที่สูงชันไม่ใช่นักพัฒนาทุกคนเช่นการเขียนโปรแกรมทดสอบครั้งแรก ในความเป็นจริงฉันเดาว่านักพัฒนาส่วนใหญ่ไม่ชอบในตอนแรก คุณสามารถทำสิ่งต่าง ๆ เช่นการเขียนโปรแกรมจับคู่เพื่อช่วยให้พวกเขาทำงานได้เร็วขึ้น แต่ก็สามารถขายได้ยาก
ในท้ายที่สุดข้อดีนั้นมีมากกว่าข้อเสีย แต่ก็ไม่ได้ช่วยอะไรคุณเพียงแค่เพิกเฉยต่อข้อเสีย การรู้ว่าคุณกำลังทำอะไรอยู่ตั้งแต่แรกเริ่มจะช่วยให้คุณสามารถเจรจาข้อเสียบางอย่างถ้าไม่ใช่ทั้งหมด
การทดสอบก่อนสมมติว่าคุณกำลังเขียนโค้ดที่:
หากโครงการของคุณไม่เป็นไปตามข้อกำหนดเหล่านั้นคุณจะประสบปัญหา โปรโมเตอร์ของ TDD ไม่มีคำตอบที่ดีสำหรับเรื่องนี้เพื่อแนะนำให้คุณออกแบบผลิตภัณฑ์ของคุณใหม่เพื่อให้อยู่ในขอบเขตที่ดีขึ้น มีสถานการณ์ที่เป็นไปไม่ได้หรือไม่พึงปรารถนา
ในทางปฏิบัติอาจเป็นปัญหาใหญ่สำหรับฉันที่คนคิดว่าการทดสอบก่อนการทดสอบจริง ๆ แล้วพิสูจน์อะไรเกี่ยวกับฟังก์ชันที่ถูกต้องของโปรแกรม ในหลายกรณีสิ่งนี้ไม่เป็นความจริง แต่แม้ในกรณีที่เป็นความจริงมันก็ยังห่างไกลจากภาพความถูกต้องทั้งหมด ผู้คนเห็นการทดสอบผ่านหลายร้อยครั้งและคิดว่ามันปลอดภัยที่จะทดสอบน้อยลงตั้งแต่ก่อน TDD พวกเขาเพียงแค่ทำการทดสอบเพียงไม่กี่ร้อยครั้ง จากประสบการณ์ของฉัน TDD หมายความว่าคุณจำเป็นต้องมีการทดสอบแบบบูรณาการมากขึ้นเนื่องจากนักพัฒนาจะมีการรักษาความปลอดภัยที่ผิดพลาดและความเจ็บปวดจากการเปลี่ยนแปลงการทดสอบทั้งหมดเพื่อทำ Redactor ขนาดใหญ่สามารถนำนักพัฒนาไปสู่การทำงานที่น่าสนใจ
ตัวอย่าง:
ตัวอย่างที่ดีที่สุดส่วนตัวของฉันคือเมื่อเขียนรหัสความปลอดภัยสำหรับ asp.net หากพวกเขาตั้งใจที่จะทำงานในสภาพแวดล้อมที่เป็นมิตรจากการกำหนดค่าเครื่องพวกเขาจะ gac'ed ลงนามและปิดผนึกและเพราะพวกเขากำลังทำงานกับ IIS พระเจ้าวัตถุพวกเขาจะยากที่จะเยาะเย้ยอย่างถูกต้องมาก เพิ่มข้อ จำกัด บางประการสำหรับประสิทธิภาพและการใช้หน่วยความจำและคุณจะสูญเสียความยืดหยุ่นอย่างรวดเร็วในการใช้วัตถุตัวยึดตำแหน่งในพื้นที่ที่เหลือ
การจัดเรียงตัวควบคุมขนาดเล็กหรือรหัสสภาพแวดล้อมทรัพยากรต่ำอื่น ๆ อาจเป็นไปไม่ได้ที่จะทำการออกแบบสไตล์ OO อย่างแท้จริงเนื่องจาก abstractions ไม่ได้ปรับให้เหมาะสมและคุณมีข้อ จำกัด ด้านทรัพยากรต่ำ เช่นเดียวกันอาจกล่าวได้ว่าเป็นกิจวัตรที่มีประสิทธิภาพสูงในหลายกรณีเช่นกัน
ข้อเสียเปรียบที่ยิ่งใหญ่ที่สุดที่ฉันเคยเห็นไม่ใช่กับตัว TDD แต่กับผู้ฝึก พวกเขาใช้วิธีการดันทุรังและกระตือรือร้นที่ทุกอย่างต้องผ่านการทดสอบ บางครั้ง (หลายต่อหลายครั้ง) นั่นไม่จำเป็น นอกจากนี้อาจไม่สามารถใช้งานได้ (.ie. แนะนำองค์กรไปยัง TDD)
วิศวกรที่ดีพบว่ามีการแลกเปลี่ยนและใช้ดุลยภาพที่เหมาะสมเมื่อ / ที่ไหน / อย่างไรที่จะใช้การทดสอบครั้งแรก นอกจากนี้หากคุณพบว่าตัวเองใช้เวลาอย่างต่อเนื่องในการพัฒนาแบบทดสอบมากกว่าการใช้รหัสจริง (ประมาณ 2-3 ครั้งขึ้นไป) แสดงว่าคุณกำลังมีปัญหา
กล่าวอีกนัยหนึ่งควรให้ความสำคัญในทางปฏิบัติและสมเหตุสมผลกับ TDD (หรือสิ่งใดก็ตามในการพัฒนาซอฟต์แวร์สำหรับเรื่องนั้น)
ฉันเริ่มทำ TDD ในต้นเดือนสิงหาคม 2009 และโน้มน้าวให้ บริษัท ของฉันเปลี่ยนไปใช้ในเดือนกันยายน / ตุลาคม 2009 ปัจจุบันทีม dev ทั้งหมดได้รับการดัดแปลงอย่างสมบูรณ์ มันทำงานได้ดีสำหรับเราและฉันไม่สามารถจินตนาการเปลี่ยนกลับไปเป็นรหัสคาวบอยได้
อย่างไรก็ตามมีสองปัญหาที่สังเกตได้ค่อนข้างชัดเจน
ต้องทำการบำรุงรักษาชุดทดสอบ
เมื่อคุณจริงจังกับ TDD คุณจะต้องเขียนการทดสอบจำนวนมาก ยิ่งไปกว่านั้นมันต้องใช้เวลาและประสบการณ์ในการรู้ว่าอะไรคือสิ่งที่ถูกต้องในการทดสอบ (การทำมากเกินไปเกือบจะไม่ดีเท่าการทดสอบ) การทดสอบเหล่านี้เป็นรหัสและพวกเขามีความอ่อนไหวต่อ bitrot ซึ่งหมายความว่าคุณต้องรักษามันไว้เป็นอย่างอื่น: อัปเดตเมื่อคุณอัปเกรดไลบรารีที่พวกเขาต้องพึ่งพาปรับเปลี่ยนเป็นครั้งคราว ... เมื่อคุณทำการเปลี่ยนแปลงรหัสของคุณครั้งใหญ่การทดสอบจำนวนมากจะล้าสมัยหรือ แม้ผิดธรรมดา หากคุณโชคดีคุณสามารถลบได้ แต่หลายครั้งคุณจะต้องแยกบิตที่มีประโยชน์และปรับให้เข้ากับสถาปัตยกรรมใหม่
การทดสอบ abstractions รั่วไหลเป็นครั้งคราว
เราใช้ Django ซึ่งมีกรอบการทดสอบที่ยอดเยี่ยมมาก อย่างไรก็ตามบางครั้งมันทำให้สมมติฐานที่ขัดแย้งกับความเป็นจริงเล็กน้อย ตัวอย่างเช่นมิดเดิลแวร์บางตัวอาจทำลายการทดสอบ หรือการทดสอบบางอย่างสร้างสมมติฐานเกี่ยวกับแบ็กเอนด์แคช นอกจากนี้หากคุณใช้ฐานข้อมูล "ของจริง" (ไม่ใช่ SQLite3) การเตรียมฐานข้อมูลสำหรับการทดสอบจะใช้เวลานาน แน่นอนว่าคุณสามารถ (และควร) ใช้ SQLite3 และฐานข้อมูลในหน่วยความจำสำหรับการทดสอบที่คุณทำในเครื่อง แต่บางรหัสจะทำงานแตกต่างกันไปขึ้นอยู่กับฐานข้อมูลที่คุณใช้ การตั้งค่าเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ทำงานในการตั้งค่าที่เหมือนจริงเป็นสิ่งจำเป็น
(บางคนจะบอกคุณว่าคุณควรเยาะเย้ยทุกสิ่งเช่นฐานข้อมูลหรือการทดสอบของคุณไม่ได้ "บริสุทธิ์" แต่นั่นเป็นเพียงการพูดเชิงอุดมการณ์ถ้าคุณทำผิดพลาดในรหัสการเยาะเย้ย (และเชื่อฉันคุณจะ) Testuite ของคุณจะไร้ค่า)
ทั้งหมดนี้กล่าวว่าปัญหาที่ฉันอธิบายเริ่มสังเกตเห็นได้ก็ต่อเมื่อคุณค่อนข้างก้าวหน้ากับ TDD ... เมื่อคุณเพิ่งเริ่มต้นด้วย TDD (หรือทำงานในโครงการขนาดเล็ก) การทดสอบการรีแฟคเตอร์จะไม่เป็นปัญหา
สำหรับฉันมีปัญหาทางจิตวิทยาลึก ๆ เกี่ยวกับการทดสอบเมื่อใดก็ตามที่ฉันพยายามที่จะนำไปใช้อย่างกว้างขวางเช่นเดียวกับใน TDD: ถ้าพวกเขาอยู่ที่นั่นฉันรหัสอย่างเลอะเทอะเพราะฉันเชื่อว่าการทดสอบจะจับปัญหาใด ๆ แต่ถ้าไม่มีการทดสอบเพื่อให้เครือข่ายความปลอดภัยฉันรหัสอย่างระมัดระวังและผลที่ได้จะดีกว่าการทดสอบอย่างสม่ำเสมอ
อาจจะเป็นเพียงฉัน แต่ฉันได้อ่านบางแห่งว่ารถยนต์ที่มีระฆังนิรภัยทุกประเภทและเสียงนกหวีดมีแนวโน้มที่จะพังมากกว่า (เพราะคนขับรู้ว่ามีคุณลักษณะด้านความปลอดภัยอยู่ที่นั่น) ดังนั้นบางทีนี่อาจเป็นสิ่งที่ควรยอมรับ TDD อาจเข้ากันไม่ได้กับบุคคลบางคน
สถานการณ์หนึ่งที่การทดสอบครั้งแรกได้มาในทางของฉันคือเมื่อฉันต้องการลองใช้ความคิดอย่างรวดเร็วและดูว่ามันสามารถทำงานได้ก่อนที่ฉันจะเขียนการใช้งานที่เหมาะสม
วิธีการของฉันเป็นปกติ:
บางครั้งฉันไม่ได้ไปขั้นตอนที่ 2
ในกรณีนี้การใช้ TDD กลายเป็นข้อเสียมากกว่าข้อดีสำหรับฉัน:
ดังนั้นเมื่อฉันต้องสำรวจความคิดใหม่ ๆ ฉันไม่ได้ใช้ TDD และแนะนำการทดสอบหน่วยเมื่อฉันรู้สึกว่ารหัสใหม่กำลังจะไปที่ไหนสักแห่ง
หมายเหตุ: มีช่วง TDD หลากหลายประเภท โดยไม่คำนึงถึงยูนิต BDD, ATDD หรือตัวแปรอื่น ๆ ยังคงมีปัญหาอยู่หลายประการ
ผลข้างเคียง
ไม่ว่าจะเป็นการเยาะเย้ยการแข่งขันหรือการทดสอบการทำงานการพึ่งพารัฐภายนอกหรือระบบมักเป็นแหล่งของความซับซ้อนมากที่สุดในการทดสอบความสับสนในวิธีการทดสอบและความเสี่ยงที่ใหญ่ที่สุดในการทำผิด ปัญหาเล็กน้อยที่ฉันเคยเห็น:
คุณจะต้องเปลี่ยนวิธีการในการเขียนโปรแกรมสำหรับบางอย่างมันจะเป็นการเปลี่ยนแปลงที่รุนแรง
รหัสคนต่างกันด้วยวิธีที่แตกต่างกัน ใน TDD คุณต้องเริ่มต้นด้วยการทดสอบที่กำหนดพฤติกรรมที่เฉพาะเจาะจงแล้วนำไปใช้เพื่อให้การทดสอบผ่าน ฉันเคยเห็นและเป็นโปรแกรมเมอร์ที่การเขียนโปรแกรมไม่เอื้อต่อ TDD ฉันใช้เวลาประมาณ 2 เดือนเมื่อฉันเริ่มคุ้นเคยกับการเปลี่ยนแนวทางการพัฒนาของฉัน
ต้องใช้เวลาในการทำความเข้าใจสิ่งที่คุณสนใจเกี่ยวกับการทดสอบและสิ่งที่คุณไม่สนใจเกี่ยวกับการทดสอบ
ทุกทีมควรตัดสินใจอย่างชัดเจนว่าพวกเขาต้องการวาดเส้นในการทดสอบอย่างไร สิ่งที่พวกเขาให้คุณค่าที่พวกเขาต้องการทดสอบและสิ่งที่พวกเขาไม่ มันมักจะเป็นกระบวนการที่เจ็บปวดในการเรียนรู้วิธีการเขียนการทดสอบที่ดีและสิ่งที่คุณสนใจเกี่ยวกับการทดสอบ ในขณะเดียวกันรหัสจะยังคงอยู่ในสถานะฟลักซ์จนกว่าจะมีความสอดคล้องทั้งในรูปแบบและวิธีการ
หน่วยทดสอบเฉพาะ: refactors ขนาดใหญ่
refactor ขนาดใหญ่หรือพื้นฐานของ codebase ที่สำคัญพร้อมกับการทดสอบหน่วยนับหมื่นจะสร้างค่าใช้จ่ายมากในการปรับปรุงการทดสอบทั้งหมด สิ่งนี้มักจะปรากฏชัดในการผลักดันการทำ refactor แม้ว่ามันจะเป็นสิ่งที่ถูกต้องที่จะทำเพียงเพราะค่าใช้จ่ายที่เกี่ยวข้องกับการทำมัน
การเปรียบเทียบของฉันคือสิ่งกีดขวางบนเส้นทาง Scalextric หากคุณใส่พวกเขาคุณจะได้รับความระมัดระวังน้อยลง
ผู้คนยังได้รับพื้นที่ว่างเล็กน้อยเกี่ยวกับการทดสอบของพวกเขา - เพราะพวกเขาทำงานได้ดีพวกเขาเชื่อว่ารหัสนั้นถูกทดสอบอย่างสมบูรณ์ในขณะที่มันเป็นเพียงจุดเริ่มต้นของกระบวนการทดสอบ
ในความคิดของฉัน TDD เป็นหินแห่งก้าวสู่ BDD การทดสอบที่รันไม่ได้ช่วยนักพัฒนาโดยไม่รู้ว่าการทดสอบทำอะไร ด้วย BDD ผลลัพธ์ของการทดสอบจะเป็นภาษาอังกฤษซึ่งจะทำการบันทึกการทดสอบและสร้างความเข้าใจในระบบ
ประโยชน์ของ TDD คือมันบังคับให้คุณปกป้องรหัสของคุณกับผู้ที่ไม่เข้าใจ ใช่สิ่งนี้มักจะรวมถึงตัวคุณเอง แต่จะเกิดอะไรขึ้นเมื่อรหัสไม่คุ้มค่าในการปกป้อง มีรหัสมากมายที่ไม่ควรมีตั้งแต่แรก! ดังนั้นปัญหากับ TDD คือเมื่อมันมาถึงนักพัฒนาที่เขียนโค้ดไม่ดี TDD อาจไม่ช่วยให้พวกเขาเขียนโค้ดที่ดีมีโอกาสมากที่พวกเขาจะเขียนแบบทดสอบที่น่ากลัวเช่นกัน ดังนั้นในกรณีของพวกเขา TDD จะเพิ่มความยุ่งเหยิง; การเขียนที่ไม่ดีและ / หรือการทดสอบซ้ำซ้อนนั้นไม่ได้สนุกไปกว่าโค้ดที่ไม่ดีรูปแบบอื่น ๆ