ทำการเปลี่ยนแปลงเล็กน้อยทดสอบแล้ว "ล้างและทำซ้ำ" เป็นนิสัยที่ไม่ดีหรือไม่?


54

ฉันเป็นโปรแกรมเมอร์ที่มีประสบการณ์หลายปี ฉันรู้ว่าฉันมีนิสัยบางอย่าง ฉันไม่แน่ใจว่ามันเป็นนิสัยที่ไม่ดีจริง ๆ หรือไม่

ฉันได้รับรายการงานที่ต้องดำเนินการเพื่อแก้ไขปัญหาแม้แต่งานเล็ก ๆ เช่น

  1. เปลี่ยนทรัพยากรของการควบคุมผู้ใช้นี้
  2. เปลี่ยนขนาดของอีกอันหนึ่ง
  3. เพิ่ม HTML และการเข้ารหัสในการควบคุมผู้ใช้อื่น

งานทั้งหมดนี้มีขนาดเล็ก ฉันหมายความว่าพวกเขาสามารถทำได้ภายใน 10 นาทีแต่ฉันได้เป็นนิสัยที่ไม่ดีของการเปลี่ยนแปลงเล็ก ๆ แล้วทดสอบพวกเขาอีกครั้งและอีกครั้งในเว็บเบราเซอร์ นี่เป็นวิธีปฏิบัติที่ดีหรือไม่?

หรือฉันควรแสดงทั้งหมดในครั้งเดียวแล้วทดสอบด้วยกัน?

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



3
@gnat คำตอบที่ได้รับการโหวตสูงสุดของคุณนั้นเป็นไปตามความเห็นเช่นกัน - programmers.stackexchange.com/questions/154733/… ทุกคำตอบที่ฉันอ่านจะให้ความเห็นของตัวเองความคิดเห็นใด ๆ
คณิตศาสตร์

2
แค่นั้นแหละ วิธีการเกี่ยวกับคำตอบที่ได้รับคะแนนสูงสุดอันดับสองของคุณ - programmers.stackexchange.com/questions/159964/ ...... - ความเห็นก็ไม่ได้เป็นไปตามเช่นกัน?
คณิตศาสตร์

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

5
ฉันจะบอกว่าสิ่งที่ตรงกันข้ามกับนิสัยการเปลี่ยนแปลงมากมายและจากนั้นทดสอบมันเป็นนิสัยที่ไม่ดี
Chris B. Behrens

คำตอบ:


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

9
AFAIK สำหรับการเขียนโปรแกรม UI ไม่เพียง แต่เป็นแนวปฏิบัติที่ดีเท่านั้น แต่เป็นแนวปฏิบัติที่ยอมรับได้เท่านั้น นั่นเป็นเหตุผลที่ บริษัท ซอฟต์แวร์สร้างWhat you see is what you getเครื่องมือมากมายสำหรับนักพัฒนาซอฟต์แวร์ที่ทำงานกับ HTML, CSS, Widget และอื่น ๆ อีกมากมาย
InformedA

38

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

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

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


18

คำถามของคุณมีสองส่วน:

  1. ฉันควรแสดงทั้งหมดครั้งเดียวแล้วทดสอบด้วยกัน?

    ฉันถือว่าคุณกำลังใช้VCSอยู่
    และติดตามงานที่ได้ทำมันทำให้รู้สึกที่จะแจกจ่ายรายการของงานในรายการกระทำ: หนึ่งงานหนึ่งกระทำ

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

    คำตอบนั้นชัดเจน:

    ไม่ทำให้เกิดการเปลี่ยนแปลงเพียงคนเดียวโดย 1-1 งานหนึ่งกระทำ

  2. แต่ฉันมีนิสัยที่ไม่ดีในการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ แล้วทดสอบพวกเขาซ้ำแล้วซ้ำอีกในเว็บเบราว์เซอร์นี่เป็นวิธีปฏิบัติที่ดีใช่ไหม

    มันเป็นวิธีที่ดีในการทดสอบรหัส / UI อะไรก็ตามแต่มันเป็นเรื่องไร้สาระที่จะทำมันซ้ำแล้วซ้ำอีกครั้งในเบราว์เซอร์ มีเครื่องมือที่จะทำโดยอัตโนมัติสำหรับคุณ ( ซีลีเนียม, PhantomJS / Casper, ZombieJS )

    คำตอบสำหรับกรณีนี้คือ:

    ใช่เป็นแนวปฏิบัติที่ดีในการทดสอบซอฟต์แวร์มากกว่าหนึ่งครั้ง แต่ใช้ระบบอัตโนมัติ


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

งานหนึ่งที่ยืนยันว่ามีศักยภาพที่จะทำให้บันทึก VCS เป็นระเบียบที่ไม่สามารถเข้าใจได้สำหรับคำจำกัดความต่าง ๆ ของ "งานเดี่ยว"
whatsisname

ขึ้นอยู่กับว่าคุณกำหนดภารกิจละเอียดอย่างไร;) หรือหากคุณต้องการ: หนึ่ง "ตั๋ว" หนึ่งกระทำ / สาขา การใช้คอมไพล์ทำให้มันง่าย
โทมัสขยะ

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

@scarar ใช่ ระบบอัตโนมัติสำหรับการทดสอบการถดถอย
Thomas Junk

6

สำหรับนิสัยใด ๆ ที่นักพัฒนามีอยู่ 2 คำถามหลัก:

  1. มันมีผลต่อคุณภาพของรหัสที่คุณทำอย่างไร
  2. มันมีผลต่อผลผลิตของคุณอย่างไร?

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

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

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

ดังนั้น - ถ้า 90% ของวันทำงานของคุณกำลังเปลี่ยนแปลงเล็ก ๆ น้อย ๆ - มันเป็นนิสัยที่สมบูรณ์แบบที่จะมี หากวันทำงานของคุณเป็นเช่นนั้นคุณอาจต้องการทบทวนรูปแบบการทำงานของคุณ (หรือที่ทำงาน)


4

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

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

  • "ขนาน" ขั้นตอนการทำงานของคุณ (เช่นทำงานบนหลาย ๆ งานพร้อมกัน) หรือ
  • ทำหลายสิ่งให้มากที่สุดในคราวเดียวหรือ
  • สร้างส่วนเล็ก ๆ ที่เป็นอิสระเพื่อทำงานและรวมเข้ากับโครงการขนาดใหญ่ในภายหลัง

(อาจมีวิธีอื่นด้วย)


+1 สำหรับการทำในเบราว์เซอร์โดยตรง ฉันมักจะทำให้การปรับแต่ง CSS ในเบราว์เซอร์เป็นแบบอย่างที่ดีของงานจริงที่ฉันจะทำ
RubberDuck

0

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

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