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


21

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

ในระหว่างการสัมภาษณ์คุณได้รับการบอกเล่าจากผู้บริหารว่าพวกเขา "สนับสนุนการทดสอบหน่วย" อย่างยิ่งและพวกเขาสนับสนุนอย่างเปิดเผย พวกเขาทำ แต่ทุกอย่างเกี่ยวกับการทดสอบตัวเองเป็นเพียงผิดธรรมดา เช่นเดียวกับข้อเท็จจริงที่ว่าพวกเขาอ้างความคุ้มครอง 100% เมื่อมีการทดสอบการรวม 100% แต่ครอบคลุมการทดสอบหน่วยที่ทำซ้ำได้น้อยกว่า 10% ปัญหาอื่น ๆ ที่ฉันพบ:

  1. ไม่มีข้อบ่งชี้ที่ชัดเจนระหว่างการทดสอบหน่วยและการทดสอบการรวมคืออะไร การทดสอบหน่วยและการรวมเข้าด้วยกันเป็นกลุ่มเดียวกัน

  2. การทดสอบการรวมที่ไม่มีการประกาศที่ชัดเจนเกี่ยวกับข้อมูลไดนามิกที่เฉพาะเจาะจงมากในฐานข้อมูลของสภาพแวดล้อมที่เฉพาะเจาะจง

  3. การทดสอบการรวมที่ไม่มีการทำธุรกรรมโดยทั่วไปการทดสอบที่อาจหรือไม่รำคาญที่จะทำความสะอาดหลังจากที่ตัวเองบางครั้งต้องใช้ฐานข้อมูลด้วยตนเอง "ขัด" เพื่อให้การทดสอบซ้ำ

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

  5. ไม่มีแบบแผนการตั้งชื่อที่ชัดเจนเพื่อดูชื่อการทดสอบอย่างรวดเร็วและกำหนดคร่าว ๆ ว่าการทดสอบใดที่กำลังทำอยู่

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

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

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

การทดสอบทั้งหมดควรได้รับการจัดทำใหม่ในความพยายามที่ยิ่งใหญ่ซึ่งครอบคลุมการเผยแพร่ทุกครั้งหรือไม่? คุณควรละทิ้งแนวคิดที่ว่าโครงการดั้งเดิมนี้อาจมีการทดสอบหน่วยหนึ่งวัน


6
ยินดีต้อนรับสู่โลกแห่งความเป็นจริงเพื่อนสนิท
tdammers

20
มีความสุขที่คุณมีการทดสอบ
Joel Etherton

3
ทำไมคุณถึงทำงานกับ บริษัท ที่มีระดับความสามารถต่ำกว่าคุณอย่างชัดเจน?
TrojanName

3
@Brian ฉันขอขอบคุณ ego stroke แต่ไม่มีผู้คนที่คิดเหมือนฉันมากนัก บริษัท เหล่านี้จะไม่มีวันเติบโต นี่เป็นครั้งแรกที่ฉันอยู่ในตำแหน่งที่มีอำนาจที่แท้จริงขณะที่ฉันพัฒนาความสำคัญทางการเมืองเล็กน้อยในครั้งเดียว ฉันมีโอกาสจริงที่นี่เพื่อนำทรัพยากรไปสู่สิ่งที่ดีขึ้น ฉันยังไม่พบ บริษัท ที่สมบูรณ์แบบโดยไม่ต้องทำงาน มันเป็นเหมือนสามีหรือภรรยาที่สมบูรณ์แบบพวกเขาไม่เพียงแค่เข้ามาคนที่ดีพอเข้ามาและจากนั้นคุณเปลี่ยนพวกเขาเป็นสิ่งที่คุณต้องการให้พวกเขาเป็น;)
maple_shaft

1
ฉันคิดว่าเราอาจทำงานให้กับทีมเดียวกัน ตอนนี้คุณ (และฉัน) รู้วิธีการถามคำถามจริง ๆ ระหว่างการสัมภาษณ์ครั้งต่อไปของเรา (ที่จริงแล้วสภาพแวดล้อมของฉันไม่มีที่อยู่ใกล้ 100% หรือ 10% ครอบคลุมการทดสอบการรวม [การทดสอบหน่วยจริงหรือไม่นั่นมันช่างพูดบ้า!] แต่คุณได้จับจุดอื่น ๆ ทั้งหมดที่ฉันจัดการด้วย)
Anthony Pegram

คำตอบ:


6

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

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

ความคิดที่ดีกว่าคือการพยายามพูดคุยกับพวกเขาเพื่อให้พวกเขาสามารถมีส่วนร่วมในความพยายามและคุณจะมีโอกาสน้อยที่จะปรากฏเป็นสมาร์ท - ลามันจะเป็น "เรา" มากกว่า "ฉัน"

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

  1. จะสร้างความแตกต่างระหว่างการทดสอบหน่วยและการรวมได้อย่างไร อาจมีการแก้ไขปัญหาต่อไปนี้และไม่ได้ จำกัด เฉพาะ:

    • Refactor ชื่อของวิธีทดสอบกรณี (ไม่ใช่คลาสเนื่องจากพฤติกรรมที่ถูกต้องคือให้กรณีทดสอบใช้ชื่อเดียวกันกับคลาสทดสอบ)
    • สร้างคำอธิบายประกอบสองรายการอันหนึ่งชื่อ "UnitTest" อีกอันหนึ่ง "IntegrationTest" คำอธิบายประกอบเหล่านี้สามารถใช้กับคลาสและวิธีการ หากทั้งคลาสนั้นประกอบด้วยการทดสอบหน่วยหรือการรวมคุณสามารถทำเครื่องหมายชั้นเรียนด้วยคำอธิบายประกอบที่ถูกต้อง หากไม่มีคุณสามารถทำเครื่องหมายแต่ละวิธีด้วยคำอธิบายประกอบที่ถูกต้อง นอกจากนี้คำอธิบายประกอบเหล่านี้อาจเป็นประโยชน์ในการฉีดติดตั้งแบบไดนามิกก่อนที่จะเริ่มการทดสอบ (เฟส 3)
  2. สำหรับการทดสอบการรวมแต่ละรายการรายการ "ชุดข้อมูล" ที่คาดว่าจะอยู่ในฐานข้อมูลที่จุดเริ่มต้นของการทดสอบแต่ละครั้งและสิ่งที่ควรลบออกในตอนท้ายของมัน (เช่น: ตาราง X ต้องการบันทึกด้วย "id" ตั้งค่าเป็น "1" และ "ชื่อ" ตั้งค่าเป็น "foo" เป็นต้น) โปรดทราบว่าสิ่งที่คุณลบอาจใหญ่กว่า / เล็กกว่าที่คุณมีในตอนเริ่มต้นเนื่องจากโค้ดนั้นอาจเพิ่ม / ลบวัตถุจากชั้นการคงอยู่ คุณอาจสังเกตได้อย่างรวดเร็วว่ากรณีทดสอบเหล่านี้หลายชุดต้องการชุดข้อมูลเดียวกันหรือเป็นส่วนหนึ่งของชุดข้อมูลเดียวกัน

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

คุณอาจสังเกตได้ว่าขั้นตอนที่ 1, 2 และ 3 อาจจะทำในชั้นเรียนทดสอบเดียวถ้าคุณต้องการที่จะแสดงให้เพื่อนร่วมงาน / การจัดการวิธีการที่สามารถทำได้ สิ่งนี้จะเป็นประโยชน์อย่างที่PéterTörökเขียนเพื่อแสดง "วิธีที่ดี" แก่เพื่อนร่วมทีมของคุณทันทีเพื่อหยุดการสร้างรหัสที่ไม่ดี อย่างไรก็ตามฉันคิดว่าส่วนที่เหลือของระยะที่ 2 ซึ่งระบุชุดข้อมูลการทดสอบทั้งหมดทำได้ดีที่สุดในขั้นตอนใหญ่เพียงขั้นตอนเดียว

สำหรับ API / เทคโนโลยีนั้นคุณดูเหมือนจะรู้เรื่อง

หวังว่าจะช่วยได้เล็กน้อย

หมายเหตุ: สำหรับข้อเสนอของฉันฉันคิดว่าคุณเป็นรหัสใน Java / C # ที่ฉันรู้ว่าคำอธิบายประกอบและ AOP เป็นไปได้ ฉันแน่ใจว่านี่อาจเป็นไปได้ในภาษาอื่น แต่ฉันจะไม่เขียนเกี่ยวกับสิ่งที่ฉันไม่รู้


1
ขอบคุณ ... ฉันถือว่าการใช้คำอธิบายประกอบเป็นป้ายกำกับเพื่อระบุว่าเป็นการทดสอบการรวมระบบและการทดสอบหน่วยคืออะไร ... คุณรู้หรือไม่ว่าสามารถกำหนดค่าเซิร์ฟเวอร์ CI เช่น CruiseControl เพื่อแยกการทดสอบบางอย่างจากคำอธิบายประกอบได้หรือไม่ อาจเป็นคำถามแยกต่างหาก
maple_shaft

ฉันขอโทษที่ฉันไม่รู้จักใช้ CruiseControl ดังนั้นฉันจึงไม่รู้เรื่องนั้น ฉันค้นหาในการกำหนดค่าปลั๊กอิน Surefire ของ Maven เพื่อความอยากรู้อยากเห็นและดูเหมือนจะเป็นไปไม่ได้ แต่ก็เป็นไปได้ที่จะข้ามการทดสอบตามชื่อของหลักสูตร
Jalayn

14

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

ก่อนอื่นคุณไม่สามารถ 'แก้ไข' หรือปรับเปลี่ยนรหัสที่มีอยู่เว้นแต่ว่าคุณมีการทดสอบคุณภาพที่ครอบคลุมดังนั้นฉันจะมุ่งเน้นไปที่การแก้ไขโครงสร้างพื้นฐานการทดสอบของคุณก่อน

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

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

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

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


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

2
+1 สำหรับกฎลูกเสือเป็นเรื่องง่ายกว่าที่จะใช้และขายมากกว่าวิธีการยกเครื่อง
Matthieu M.

10

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

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

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

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


6

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

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


2
ฉันควรจะกล่าวว่าไม่มีผู้สร้างระเบียบต้นฉบับอยู่ที่นี่อีกต่อไป พวกเขาไม่รู้สึกอยากจัดการกับหนี้ทางเทคนิคที่พวกเขาสร้างและเดินหน้าต่อไป
maple_shaft

4
@maple_shaft: มันเป็นเรื่องดีที่พวกเขาจะหายไป ... คุณสามารถปรับปรุงสิ่งต่าง ๆ โดยไม่มีใครเสียหน้า
วินไคลน์

2

สิ่งที่ดีเกี่ยวกับการเป็นทีมใหม่คือคุณมีวิธีการ "สด" ในสิ่งต่าง ๆ ส่วนที่ไม่ดีอาจเป็นเพราะคนอื่นอาจมีเวลายากที่จะเชื่อคุณ

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

แต่ให้ช้าลงทีละคนและหวังว่าความคิดของคุณจะค่อยๆ "จับ" ในกลุ่มใหม่


2

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

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

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

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

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


2

แก้ไขเมื่อเวลาผ่านไป

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

ฉันเองไม่สนใจว่าการทดสอบเป็นการทดสอบหน่วยหรือการทดสอบการรวมเข้าด้วยกันตราบใดที่เป็นการทดสอบที่ดี จากการทดสอบที่ดีฉันหมายความว่า:

  • ทำความสะอาดหลังจากนั้น
  • ทำซ้ำได้
  • ลดการเกิดปฏิกิริยาต่อสิ่งแวดล้อม
  • มีความสอดคล้อง

ตลอดทางที่ฉันประกาศเรื่องการสร้างการทดสอบที่ดีขึ้น

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