ฉันเขียนเกี่ยวกับ TDD มากมาย จึงไม่แปลกใจเลยที่ตอนที่ฉันเผยแพร่บทความที่แล้วเกือบ นาทีที่แน่นอน David Heinemeier Hansson พูดถึง TDD ในระหว่างการกล่าวสุนทรพจน์ RailsConf ฉันมีคำถาม:
คุณเห็นด้วยกับความคิดเห็นของ DHH เกี่ยวกับ TDD หรือไม่? คุณยังคงแนะนำ TDD หรือไม่? ถ้าไม่ฉันควรทำอย่างไรแทน?
สิ่งที่ DHH พูด
หากคุณพลาดประเด็นสำคัญ เรียงความของ DHH จะจับส่วนสำคัญของมัน:
อาจจำเป็นต้องใช้การทดสอบก่อนเป็น RAM ที่ตอบโต้ได้ง่ายสำหรับการทำลายอุตสาหกรรมที่ขาดการทดสอบอัตโนมัติและถดถอย บางทีอาจเป็นคำอุปมาที่ไม่ได้ตั้งใจให้เป็นคำอธิบายตามตัวอักษรของการทำงานในแต่ละวันของการเขียนซอฟต์แวร์ แต่ไม่ว่าจะเริ่มต้นอย่างไร ไม่นานมันก็พังทลายลง ใช้เป็นค้อนทุบผู้ไม่เชื่อ ประกาศว่าพวกเขาไม่เป็นมืออาชีพและไม่เหมาะที่จะเขียนซอฟต์แวร์ การทดสอบสารสีน้ำเงิน
เพียงพอ. ไม่มีอีกแล้ว ฉันชื่อ David และฉันไม่ได้เขียนซอฟต์แวร์ทดสอบก่อน ฉันปฏิเสธที่จะขอโทษสำหรับเรื่องนั้นอีกต่อไป ซ่อนน้อยกว่านั้นมาก ฉันรู้สึกขอบคุณสำหรับสิ่งที่ TDD ทำเพื่อลืมตาไปสู่การทดสอบการถดถอยอัตโนมัติ แต่ฉันได้เปลี่ยนจากหลักความเชื่อในการออกแบบมานานแล้ว
…
ใช่ การทดสอบก่อนตายสำหรับฉัน แต่แทนที่จะเต้นรำบนหลุมศพ ฉันอยากจะให้เกียรติกับผลงานของมันมากกว่าที่จะนั่งเลียนแบบ ถือเป็นช่วงสำคัญในประวัติศาสตร์ของเรา แต่ถึงเวลาต้องก้าวต่อไป
เนื้อหาทั้งหมดน่าอ่าน แต่ฉันแยกประเด็นหลักบางส่วนออก:
- TDD เป็นโปรแกรมแฮ็กใจเพื่อสนับสนุนการทดสอบการถดถอยอัตโนมัติ
- การใช้วาทศิลป์ครั้งแรกในการทดสอบความโกรธนำไปสู่ความโศกเศร้าและความสิ้นหวัง
- TDD นำไปสู่เว็บที่ซับซ้อนเกินไปของวัตถุและทางอ้อม
- คุณควรเลือกใช้การทดสอบระบบแบบแยกส่วนมากกว่าการทดสอบหน่วย
- แต่คุณไม่ควรเปลี่ยนความชอบนั้นเป็นศาสนาอื่น
- ด้วยเหตุผลเหล่านี้ การทดสอบก่อนจึงไม่ใช่แนวทางปฏิบัติด้านการออกแบบที่คุณควรใช้อีกต่อไป
ในเรียงความ ประเด็นเหล่านี้ส่วนใหญ่เชื่อมโยงกัน พวกเขามีเหตุผลในตัวเอง แต่ไม่ได้เกี่ยวพันกันอย่างที่คิดไว้
ถ้าคุณไม่แยกประเด็นออกจากกัน การโต้เถียงประเด็นหนึ่งจะถือว่ามีประเด็นอื่นๆ ที่คุณอาจไม่เห็นด้วยจริงๆ เมื่อคุณรวมสิ่งนี้เข้ากับความขุ่นเคืองของ Twitter และขีดจำกัดอักขระ 140 ตัว คุณจะจบลงด้วยความสับสน
แต่ฉันจะพูดถึงประเด็นเหล่านี้แยกกันต่างหาก
TDD นำไปสู่เว็บที่ซับซ้อนเกินไปของวัตถุและทางอ้อม
เมื่อเร็ว ๆ นี้ ฉันได้เห็นการตั้งค่าในชุมชนการทดสอบ Ruby สำหรับ "เว็บที่ซับซ้อนของวัตถุและทางอ้อม" ฉันคิดว่านี่เป็นสิ่งที่ไม่ดี (นี่เป็นหนึ่งในเหตุผลที่ฉันเริ่มใช้ Java!) แต่ฉันไม่เห็นด้วยว่า TDD เป็นสาเหตุ
ฉันมี TDD มาเกือบทศวรรษแล้ว และฉันไม่ได้แยกการทดสอบออกจากฐานข้อมูล การทดสอบการทำงานระดับคอนโทรลเลอร์และชุดทดสอบการรวมที่มีประสิทธิภาพเป็นส่วนสำคัญของชุดทดสอบทั้งหมดของฉัน ไม่ว่าจะทำงานช้าเพียงใด
การแยกการทดสอบออกจากระบบเป็นเพียงการเพิ่มประสิทธิภาพ และ YAGNI กล่าวว่าอาจยังไม่สำคัญทั้งหมด นอกจากนี้ ฉันควรได้รับการเร่งความเร็วทั่วกระดานจากการโหลด SSD และการโหลดแอปล่วงหน้า แทนที่จะพยายามเพิ่มประสิทธิภาพการทดสอบแต่ละรายการ
ที่กล่าวว่า TDD ยังคงมีผลต่อการออกแบบระบบของคุณ
TDD ขยายโค้ดของคุณแบบออร์แกนิก นี้สามารถเป็นสิ่งที่ดี! แต่บางครั้ง นักพัฒนาซอฟต์แวร์ที่มีทักษะสามารถเขียนโค้ดที่ดูดีกว่า TDD ที่ออกแบบไว้ อาจแนบแน่นกว่ากับโค้ดอื่น ๆ อาจไม่เป็นไปตามกฎ OOD ทั้งหมด แต่มีความชัดเจน ตรงไปตรงมา และเรียบง่าย (ดีเอชเอช ปิงปอง มีตัวอย่างดีๆ)
TDD ยังสามารถล็อกคุณเข้าสู่การออกแบบ API ของอ็อบเจ็กต์ได้ ก่อนที่คุณจะรู้ว่าคุณกำลังสร้างอะไรอยู่ ทำให้ยากต่อการเปลี่ยน API ในภายหลัง และความเสียดทานนั้นอาจทำให้คุณเลือกดีไซน์ที่แย่กว่านั้นได้
Test-first ไม่ใช่แนวทางปฏิบัติด้านการออกแบบที่คุณควรใช้อีกต่อไป
TDD เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการสร้างโค้ดที่ยืดหยุ่นและผ่านการทดสอบมาอย่างดี ดังนั้นฉันจึงไม่เห็นด้วยกับประเด็นนี้โดยสิ้นเชิง ฉันได้พูดถึงประโยชน์มากมายของ TDD ในบทความก่อนหน้านี้แล้ว:
- คุณจะพบว่าตัวเองมีโมเดลออบเจ็กต์ที่ผ่านการทดสอบและยืดหยุ่นมากขึ้น
- ระบบของคุณสามารถทดสอบได้ตามคำจำกัดความ ทำให้การทดสอบในอนาคตมีราคาไม่แพงนัก
- คุณตัดจำหน่ายต้นทุนการทดสอบของคุณตลอดกระบวนการพัฒนา ทำให้การประมาณของคุณแม่นยำยิ่งขึ้น
- ช่วยให้คุณไม่พลาดทุกความเคลื่อนไหว เพราะคุณไม่จำเป็นต้องตัดสินใจว่าจะทำอะไรต่อไป
นอกจากประโยชน์เหล่านั้นแล้ว ยังช่วยให้คุณฝึกฝน การทดสอบ เพราะคุณมักจะเขียนแบบทดสอบก่อนเสมอ คุณจะต้องสอบ มาก มากกว่าที่จะลองทดสอบตามความเป็นจริง . คุณจะรู้ได้ทันทีว่าการทดสอบของคุณถูกต้องหรือไม่ (เพราะจะล้มเหลวก่อน) นอกจากนี้ คุณไม่มีข้ออ้างที่จะข้ามการทดสอบ “ครั้งนี้ครั้งเดียว”
วาทศาสตร์ก่อนการทดสอบด้วยความโกรธนำไปสู่ความโศกเศร้าและความสิ้นหวัง
เห็นด้วยอย่างยิ่ง 100% ใช่ ฉันกำลังโพสต์สิ่งนี้อีกครั้ง แต่ถ้าบางคนไม่ได้ TDD เพราะพวกเขาไม่รู้เกี่ยวกับประโยชน์ที่ได้รับ หรือพวกเขายังไม่ได้เรียนรู้วิธีการทำ หรือรู้สึกไม่สบายใจกับมัน วิธีการที่ถูกต้องไม่ใช่การทำให้พวกเขาอับอาย มันคือ ช่วยเหลือ เหล่านั้น หาก TDD มีประโยชน์สำหรับคุณ แสดงให้พวกเขาเห็นว่าสิ่งนี้ช่วยคุณได้อย่างไร หากพวกเขาสนใจ โปรดช่วยพวกเขาเริ่มต้น
หากพวกเขาไม่ได้ TDDing เพราะพวกเขาต้องการวิธีที่โค้ดปรากฏโดยไม่มี TDD ก็ปล่อยให้พวกเขาไป
เมื่อคุณสร้างความเชี่ยวชาญ คุณจะพัฒนาสัญชาตญาณของคุณเอง รสนิยมของคุณเอง และเทคนิคที่คุณชอบสำหรับการพัฒนาซอฟต์แวร์ และไม่มีข้อโต้แย้งทางอินเทอร์เน็ตที่จะสอนผู้เชี่ยวชาญให้เพิกเฉยต่อสิ่งเหล่านั้น
ดังนั้น หากคุณกำลังจะวิพากษ์วิจารณ์ใครบางคนที่ไม่ทำตามแนวคิดของคุณเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด คุณกำลังทำร้ายความสามารถในการเรียนรู้ของพวกเขาหรือกรีดร้องด้วยความว่างเปล่า ซึ่งเป็นการเสียเวลาในกรณีที่ดีที่สุด และทำร้ายสาเหตุของคุณอย่างเลวร้ายที่สุด
คุณควรใช้ TDD ต่อไปหรือไม่
ใช่! ฉันขอแนะนำอย่างยิ่งให้คุณเรียนรู้และฝึกฝนมัน
ฉันให้เครดิต TDD ในการสอนวิธีทดสอบให้ฉัน และฉันยังได้รับประโยชน์มหาศาลเมื่อทำ TDD ไม่สมบูรณ์แบบ แต่ไม่มีเทคนิคใดเป็นกุญแจสำคัญในการสร้างโค้ดที่ดีขึ้นอย่างน่าอัศจรรย์
คุณต้องเรียนรู้รูปแบบ เทคนิค และเครื่องมือใหม่ๆ อยู่เสมอ ฝึกใช้จนกว่าคุณจะใช้รูปแบบที่ถูกต้องในสถานที่ที่เหมาะสมเพราะ รู้สึกใช่ .
ขณะที่คุณเรียนรู้ ให้ใช้เวลาในการแก้ไข ปรับโครงสร้างใหม่ และทดลองกับโค้ดของคุณ ดูรหัสเก่าและรหัสใหม่ของคุณ หาคนที่มีประสบการณ์มากกว่าคุณมาทบทวน คุณทำให้มันดีขึ้นหรือไม่? นั่นคือวิธีที่คุณเติบโต
