วิธีปรับปรุงการทดสอบรหัสของคุณเอง [ปิด]


12

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

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

ดังนั้นตอนนี้ฉันขอให้พวกคุณ: คุณมี groundrules บางอย่างเมื่อทดสอบรหัสของคุณ?


1
สิ่งนี้อาจช่วยได้: programmers.stackexchange.com/questions/45479/…
Amir Rezaei

คำตอบ:


17

เขียนการทดสอบก่อนที่คุณจะทำการเปลี่ยนแปลงรหัส

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

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


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

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

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

นี่เป็นเพื่อนแนะนำที่ยอดเยี่ยมขอบคุณมาก!
Shaheer

@ อัลหรือในระยะสั้น

3

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


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

2

ทำตามคำแนะนำทางเทคนิคในคำตอบเชิงเทคนิค มันเป็นสิ่งที่ดี คำตอบของฉันเกี่ยวกับทัศนคติ

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

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

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

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


ฉันเข้าใจสิ่งที่คุณพูดเกี่ยวกับความอับอายของสาธารณะ แต่ในขณะเดียวกันก็น่าผิดหวังที่ถูกบล็อกเพราะการสร้างใช้งานไม่ได้เพราะ Joe Bloggs ไม่ได้สร้างแพลตฟอร์มทั้งหมดก่อนที่จะเช็คอิน
10

@tenpn - ทั้งหมด แต่สิ่งที่ฉันพูดก็เป็นเรื่องจริงเกี่ยวกับ Joe Bloggs เช่นกัน เขายังไม่ได้รหัสของเขา ในฐานะเพื่อนร่วมงานเราต้องต่อต้านแรงกระตุ้นที่จะเปลี่ยนโจให้เป็นคนงี่เง่าในสายตาของเราเพราะเขาทำผิดพลาดที่พวกเราคนใดคนหนึ่งสามารถทำได้
Dan Ray

@tenpn จริงคุณสามารถตำหนิระบบที่ไม่ทดสอบการสร้างโดยอัตโนมัติก่อนที่จะยอมรับการเปลี่ยนแปลงใน trunk / master
David

2
@tenpn - ไม่มีการร่วมงานกับเพื่อนร่วมงานของคุณ
Dan Ray

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

2

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


0

ไอเดียหนึ่งที่ฉันใช้เป็นครั้งคราวคือสิ่งนี้

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


0

คุณมี groundrules บางอย่างเมื่อทำการทดสอบรหัสของคุณหรือไม่?

  • หน่วยทดสอบรหัสของคุณเสมอและพยายามเข้าถึงความครอบคลุมสูงที่สุดเท่าที่จะทำได้

คะแนนทั่วไปเพิ่มเติมบางส่วน:

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