เราจำเป็นต้องทำการบันทึกเมื่อทำ TDD หรือไม่?

เมื่อทำการ Red, Green & Refactor cycle เราควรเขียนโค้ดขั้นต่ำเพื่อผ่านการทดสอบ นี่คือวิธีที่ฉันได้รับการสอนเกี่ยวกับ TDD และวิธีที่หนังสือเกือบทั้งหมดบรรยายกระบวนการ

แต่สิ่งที่เกี่ยวกับการเข้าสู่ระบบ?

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

ดังนั้นคำถามของฉันคือ:

1. เราจำเป็นต้องเข้าสู่ระบบหากเรากำลังทำ TDD อยู่หรือไม่? การทดสอบที่ล้มเหลวจะไม่เปิดเผยว่ามีอะไรผิดปกติกับแอปพลิเคชันหรือไม่
2. เราควรเพิ่มการทดสอบสำหรับกระบวนการบันทึกในแต่ละวิธีในแต่ละคลาสหรือไม่
3. หากระดับการบันทึกบางส่วนถูกปิดใช้งานในสภาพแวดล้อมการผลิตเช่นนั้นจะไม่แนะนำการพึ่งพาระหว่างการทดสอบและสภาพแวดล้อมหรือไม่?
4. ผู้คนพูดถึงวิธีที่ง่ายในการดีบัก แต่หนึ่งในข้อดีหลักเกี่ยวกับ TDD คือฉันมักจะรู้ว่ามีอะไรผิดปกติเนื่องจากการทดสอบที่ล้มเหลว

มีบางอย่างที่ฉันพลาดไปไหม

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

ซึ่งถือว่าคุณมีทุกการทดสอบที่เป็นไปได้ตามความต้องการของคุณซึ่งไม่ค่อยเป็นความจริง บันทึกช่วยให้คุณติดตามข้อบกพร่องที่คุณยังไม่ได้เขียนการทดสอบ

2) เราควรเพิ่มการทดสอบสำหรับกระบวนการบันทึกในแต่ละวิธีในแต่ละคลาสหรือไม่

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

3) หากบางระดับการบันทึกถูกปิดใช้งานในสภาพแวดล้อมการผลิตเช่นนั้นจะไม่แนะนำการพึ่งพาระหว่างการทดสอบและสภาพแวดล้อม?

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

"ระดับบันทึกทางรถไฟคือข้อมูลในโหมดการผลิตและการดีบักในการพัฒนาและทดสอบ" - http://guides.rubyonrails.org/debugging_rails_applications.html

แอปพลิเคชันอื่นใช้วิธีการที่คล้ายกัน

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

ข้อบกพร่องการผลิตจะผ่านการทดสอบทั้งหมดดังนั้นคุณอาจต้องมีการอ้างอิงอื่น ๆ เพื่อตรวจสอบปัญหาเหล่านั้น

การบันทึกมีประโยชน์ในการอธิบายพฤติกรรมที่ไม่พิเศษของแอปพลิเคชัน

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

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

เอาต์พุตของโปรแกรมของคุณคือ 0 ในขณะที่เราคาดว่ามันจะเป็น 1 ทำไมถึงเป็นเช่นนั้น

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

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

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

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

แน่นอนว่าระบบที่สำคัญต่อประสิทธิภาพสามารถ / ควรมีตัวชี้วัดประสิทธิภาพที่สำคัญสำหรับแดชบอร์ดการดำเนินงานบางอย่าง แต่การบันทึก "แบบคลาสสิก" สามารถให้รายละเอียดในระดับที่แตกต่างกัน

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

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

การบันทึกและ TDD แสดงข้อกังวลต่าง ๆ

1. ถ้าคุณไม่มีฝาครอบการทดสอบ 100% ซึ่งโดยปกติจะไม่เป็นเช่นนั้นคุณไม่สามารถรู้ได้ว่าซอฟต์แวร์ของคุณจะไม่มีปัญหา (EDIT: และ - ดังที่ได้กล่าวไว้ในความคิดเห็น) แม้ว่าจะมีบางสิ่งที่เป็นอิสระจากซอฟต์แวร์ของคุณก็ตาม ความผิดพลาด); มันเหมือนกับที่คุณคิดว่าคุณสามารถทำซอฟต์แวร์ที่ไม่มีข้อบกพร่องอย่างแน่นอน (แม้แต่ NASA ก็สามารถทำได้) อย่างน้อยที่สุดคุณต้องบันทึกความผิดพลาดที่อาจเกิดขึ้นได้ในกรณีที่โปรแกรมของคุณขัดข้องเพื่อให้คุณทราบสาเหตุได้

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

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

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

ใช่ในกรณีทั่วไปคุณต้องเข้าสู่ระบบ

การบันทึกไม่ได้เกี่ยวกับการดีบัก ทีนี้ส่วนหนึ่งของการบันทึกคือเกี่ยวกับการดีบักและคุณสามารถข้ามส่วนนั้นได้หากคุณไม่ต้องการในระหว่างการพัฒนา

แต่ส่วนที่สำคัญที่สุดของการบันทึกคือการบำรุงรักษา การบันทึกที่ออกแบบมาอย่างดีอาจตอบคำถามต่อไปนี้:

• แอปพลิเคชันยังมีชีวิตอยู่และเตะหรือไม่? (โดยการบันทึกการเต้นของหัวใจทุก ๆ 1,000 วินาที)
• ประสิทธิภาพของแอปพลิเคชันเปลี่ยนไปในช่วง 10 เดือนที่ผ่านมาหรือไม่? (โดยการบันทึกสถิติของประสิทธิภาพของกรณีการใช้งาน)
• การโหลดของแอปพลิเคชันเปลี่ยนไปในช่วง 10 เดือนที่ผ่านมาหรือไม่? (โดยการบันทึกจำนวนการร้องขอต่อประเภทคำขอ)
• อินเทอร์เฟซของเรามีการเปลี่ยนแปลงคุณสมบัติด้านประสิทธิภาพหรือไม่?
• รุ่นใหม่ทำให้เกิดลักษณะการใช้งานที่แตกต่างกันไปสู่ระบบย่อยบางส่วนหรือไม่?
• เราอยู่ภายใต้การโจมตี DoSหรือไม่?
• เกิดข้อผิดพลาดประเภทใด

ทั้งหมดนี้สามารถทำได้โดยการบันทึก และใช่ควรมีการวางแผนและออกแบบและทดสอบโดยอัตโนมัติดีกว่า

การบันทึกเป็นคุณสมบัติที่ควรได้รับการปฏิบัติเช่นเดียวกับคุณสมบัติอื่น ๆ

TL; DR: การบันทึกและ TDD เป็นมุมฉาก การมีอันหนึ่งไม่จำเป็นต้องมีอีก

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

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

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

เราควรเพิ่มการทดสอบสำหรับกระบวนการบันทึกในแต่ละวิธีในแต่ละคลาสหรือไม่

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

หากระดับการบันทึกบางส่วนถูกปิดใช้งานในสภาพแวดล้อมการผลิตเช่นนั้นจะไม่แนะนำการพึ่งพาระหว่างการทดสอบและสภาพแวดล้อมหรือไม่?

หากคุณเขียนรหัสโดยใช้ IoC และใช้ mocks คุณควรจะสามารถทดสอบการบันทึกทั้งหมดของคุณได้อย่างมีประสิทธิภาพโดยไม่ต้องอาศัยการตั้งค่าด้านสิ่งแวดล้อม

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

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

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

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

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

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