ฉันจะสร้างสภาพแวดล้อมที่การทดสอบแก้ไขถูกมองว่าเป็นลำดับความสำคัญได้อย่างไร


22

ฉันเป็นวิศวกรซอฟต์แวร์ที่ บริษัท ขนาดกลาง เรามีแพลตฟอร์มการทดสอบที่ค่อนข้างแข็งแกร่งซึ่งใช้งานบน TeamCity มันทำการทดสอบหน่วยในการเช็คอินทุกครั้งและการทดสอบหน่วย / BVT รายวัน

ปัญหาคือ - เรามีการทดสอบหน่วยแตกหัก

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

ฉันต้องการปลูกเมล็ดพันธุ์ที่จะสร้างวัฒนธรรมของนิสัยที่ดี - แก้ไขการทดสอบเมื่อพวกเขาแตกหักเห็นว่ามันมีค่าจัดลำดับความสำคัญของการแก้ไขการทดสอบพร้อมกับงานอื่น ๆ

ฉันได้ลองติดสินบน (ขนมอบ) แล้วก็ถามธรรมดาและพูดกับหัวหน้าทีม ทุกคนบอกว่ามันเป็นความคิดที่ดี แต่ฉันเห็นว่าเป็นคนเดียวที่ทำอะไรเกี่ยวกับมัน

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

หากมีวิธีอัตนัยน้อยกว่าที่จะถามสิ่งนี้ฉันยินดีที่จะยอมรับเคล็ดลับใด ๆ


2
ปืน nerf อัตโนมัติพุ่งเป้าไปที่คนที่ทำลายการสร้าง ...
ratchet freak

เราจริงจะมีปืน Nerf อัตโนมัติ ... แต่สร้างไม่เสียเพียงการทดสอบหน่วย :)
Codeman

7
การทำลายการทดสอบหน่วยควรบอกเป็นนัยถึงการสร้าง ;)
Jeroen Vannevel

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

2
หากโดนัทล้มเหลวคุณจะปิ้งขนมปัง :-)
Ross Patterson

คำตอบ:


28

ทำให้เป็นไปไม่ได้ที่จะปล่อยสิ่งใดโดยไม่แก้ไขการทดสอบ

  1. สร้างบิลด์ล้มเหลวหากการทดสอบใด ๆ ล้มเหลว
  2. การบิลด์ล้มเหลวหากการทดสอบใด ๆ ถูกเพิกเฉย
  3. การสร้างล้มเหลวหากความครอบคลุมการทดสอบต่ำกว่าระดับที่กำหนด (เพื่อให้ผู้คนไม่สามารถลบการทดสอบเพื่อแก้ไขได้)
  4. ใช้เซิร์ฟเวอร์ CI เพื่อทำบิลด์ของคุณและอนุญาตเฉพาะบิลด์จากการปล่อยบิลด์ของเซิร์ฟเวอร์เพื่อเลื่อนระดับเป็น UAT / staging / production / อะไรก็ตาม

ความจริงของเรื่องคือถ้าสร้างของคุณเสียนานกว่าประมาณ 15 นาทีในช่วงเวลา (และที่มีการทดสอบล้มเหลว) แล้วคุณไม่ได้ทำรวมอย่างต่อเนื่อง

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

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

PS ถ้าคุณอยู่แล้วมีจำนวนมากของการทดสอบล้มเหลวคุณสามารถใช้ "เกณฑ์ต่อท้าย" ใน CI ตั้งขึ้นเพื่อให้การสร้างเพียงล้มเหลวถ้ามีมากขึ้นความล้มเหลวในการทดสอบกว่าครั้งที่แล้ว สิ่งนี้พร้อมกับกฎความครอบคลุมจะบังคับให้นักพัฒนาปรับปรุงสถานการณ์การทดสอบในที่สุดหากพวกเขาต้องการทำงานต่อไป

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


1
ในขณะที่คำแนะนำทางเทคนิคทั้งหมดของคุณมีประโยชน์ฉันคิดว่าส่วนที่มีค่าที่สุดของคำตอบของคุณคือ "มันเป็นวัฒนธรรมของคุณ" เพราะปัญหาวินัยมากกว่ามันเป็นปัญหาของการรับรู้การทดสอบยูทิลิตี้ ฉันอยากจะวางไว้ข้างหน้ามากกว่าใน PPS
user40989

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

FWIW: กระบวนการวางจำหน่ายทั้งหมดของเราตอนนี้เป็นไปโดยอัตโนมัติและผู้คนจะไม่คิดถึงการทดสอบที่ไม่สมบูรณ์ หัวหน้าทีมทำการรวมกันเป็นหลักแล้วเริ่มสร้างบิลด์และส่งคำขอโปรโมชันไปยัง sysadmins ที่กดปุ่มเพื่อปรับใช้จากบิวด์บิวด์และรันเบราว์เซอร์อัตโนมัติและทดสอบ API ไม่มีใครเคยบ่นเกี่ยวกับกระบวนการนี้เลยเพราะมันช่วยประหยัดเวลา - เราเคยใช้เวลา 2 สัปดาห์กับการปล่อยวางตลาดตอนนี้มันเป็นคลื่นมือ นี่คือสิ่งที่ฉันหมายถึงโดยการปลูกฝังวัฒนธรรม - ทุกคนรู้ว่า 2 นาทีพิเศษเพื่อแก้ไขการทดสอบจะประหยัด 2 ชั่วโมงต่อมา
Aaronaught

10

หน่วยทดสอบที่ล้มเหลวไม่ใช่ปัญหา พวกเขาเป็นอาการ

ปัญหาที่แท้จริงคือในวัฒนธรรม คุณจำเป็นต้องดอกยางเบา ๆ : นี่เป็นมังกร คุณไม่สามารถเปลี่ยนวัฒนธรรมได้ด้วยตัวเองและในที่สุดการเป็นคนล้อเลียนจะทำให้คุณกลายเป็นคนนอกรีต อย่างแท้จริง

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

ไม่มีคำตอบง่าย ๆ


การเป็นวงล้อส่งเสียงดังทำให้ฉันเป็นผู้นำทีม อาจจะมีบางอย่างผิดปกติกับสารภาพของคุณ? ในทุกกรณีที่พูดถึงปัญหาวัฒนธรรมที่แตกต่างกันมากไม่ได้อยู่กับทีมพัฒนา แต่รวมถึงการจัดการของ บริษัท หากฝ่ายบริหารตอบสนองต่อไฟที่ลุกลามใส่แว่นตากันแดดให้ดับลงจากที่นั่น แต่ถ้าคุณเป็นร้านค้าที่เป็นจริงเมื่อเทียบกับแผนกไอทีขององค์กรที่ทำซอฟแวร์จากศูนย์ต้นทุนก็มีแนวโน้มว่าผู้จัดการจะสนใจสิ่งต่าง ๆ เช่นความถี่และความปลอดภัยที่คุณสามารถปล่อยออกสู่ตลาดได้
Aaronaught
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.