หน่วยทดสอบแคตตาล็อกรูปแบบการต่อต้าน

anti-pattern : ต้องมีองค์ประกอบสำคัญอย่างน้อยสองอย่างในปัจจุบันที่จะแยกแยะรูปแบบการต่อต้านที่แท้จริงจากนิสัยที่ไม่ดีแบบง่าย ๆ การฝึกฝนที่ไม่ดีหรือความคิดที่ไม่ดี:

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

โหวตให้กับรูปแบบการต่อต้าน TDD ที่คุณเคยเห็น "ในป่า" หนึ่งครั้งมากเกินไป
โพสต์บล็อกโดยเจมส์คาร์และ การสนทนาที่เกี่ยวข้องกับการพัฒนาทดสอบกลุ่ม yahoogroup

หากคุณพบหนึ่ง 'ไม่มีชื่อ' .. โพสต์ 'em เกินไป โพสต์ต่อการต่อต้านแบบหนึ่งโปรดให้คะแนนโหวตบางสิ่ง

ความสนใจของฉันคือการหาเซตย่อยอันดับต้น ๆ เพื่อที่ฉันจะได้พูดคุยกับพวกเขาในกล่องอาหารกลางวันที่จะพบกันในอนาคตอันใกล้

พลเมืองชั้นสอง - รหัสการทดสอบไม่ได้รับการปรับสภาพใหม่เช่นเดียวกับรหัสการผลิตซึ่งมีรหัสซ้ำจำนวนมากทำให้ยากต่อการบำรุงรักษาการทดสอบ

The Free Ride / Piggyback - James Carr, Tim Ottinger
แทนที่จะเขียนวิธีทดสอบเคสใหม่เพื่อทดสอบคุณสมบัติ / ฟังก์ชั่น / ฟังก์ชั่นที่แตกต่างออกไปการยืนยันแบบใหม่ (และการกระทำที่สอดคล้องกันเช่น .

เส้นทางที่มีความสุข

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

JUnit Antipatterns

ฮีโร่ท้องถิ่น

กรณีทดสอบที่ขึ้นอยู่กับสิ่งที่เฉพาะเจาะจงกับสภาพแวดล้อมการพัฒนาที่เขียนขึ้นเพื่อใช้งาน ผลลัพธ์คือการทดสอบส่งผ่านกล่องพัฒนา แต่ล้มเหลวเมื่อมีคนพยายามเรียกใช้ที่อื่น

การพึ่งพาที่ซ่อนอยู่

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

น่าเศร้าที่พบเห็นสิ่งนี้มาหลายครั้งด้วยไฟล์. dll โบราณซึ่งขึ้นอยู่กับไฟล์. ini ที่หลากหลายและหลากหลายซึ่งซิงค์กันตลอดเวลาในระบบการผลิตใด ๆ ก็ตาม ถอนหายใจ

ห่วงโซ่แก๊ง

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

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

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

ที่มา: โพสต์ของ James Carr

The Silent Catcher - Kelly?
การทดสอบที่ผ่านไปหากมีการโยนข้อยกเว้น .. แม้ว่าข้อยกเว้นที่เกิดขึ้นจริงนั้นเป็นข้อยกเว้นที่แตกต่างจากที่ผู้พัฒนาตั้งใจไว้
ดูเพิ่มเติมที่: Secret Catcher

[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
   // some code that throws another exception yet passes the test
}

สารวัตร
A ทดสอบหน่วยที่ละเมิด encapsulation ในความพยายามที่จะบรรลุความครอบคลุมรหัส 100% แต่รู้มากเกี่ยวกับสิ่งที่เกิดขึ้นในวัตถุที่ความพยายามใด ๆ ที่จะ refactor จะทำลายการทดสอบที่มีอยู่และต้องการการเปลี่ยนแปลงใด ๆ ที่จะสะท้อนให้เห็นในหน่วย ทดสอบ.

'ฉันจะทดสอบตัวแปรสมาชิกของฉันได้อย่างไรโดยไม่ทำให้เป็นสาธารณะ ... แค่ทดสอบหน่วย?'

การตั้งค่ามากเกินไป - James Carr
การทดสอบที่ต้องใช้การตั้งค่าขนาดใหญ่เพื่อเริ่มการทดสอบ บางครั้งมีการใช้โค้ดหลายร้อยบรรทัดเพื่อเตรียมสภาพแวดล้อมสำหรับการทดสอบหนึ่งครั้งโดยมีวัตถุหลายอย่างที่เกี่ยวข้องซึ่งทำให้ยากต่อการตรวจสอบสิ่งที่ถูกทดสอบเนื่องจาก "เสียงรบกวน" ของการตั้งค่าทั้งหมดที่เกิดขึ้น (Src: โพสต์ของ James Carr )

โพรบทางทวารหนัก

การทดสอบที่ต้องใช้วิธีการที่บ้าผิดกฎหมายหรือไม่ดีต่อสุขภาพเช่น: การอ่านฟิลด์ส่วนตัวโดยใช้setAccessible (จริง)ของ Java หรือขยายคลาสเพื่อเข้าถึงฟิลด์ / วิธีการป้องกันหรือต้องทดสอบในแพคเกจบางอย่างเพื่อเข้าถึง แพ็คเกจ / ฟิลด์ทั่วโลก

หากคุณเห็นรูปแบบนี้คลาสที่อยู่ภายใต้การทดสอบจะใช้การซ่อนข้อมูลมากเกินไป

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

ความคิดเห็นโดย Michael Borgwardt: นี่ไม่ใช่ปฏิปักษ์ทดสอบจริง ๆ มันเป็นประโยชน์ที่จะจัดการกับข้อบกพร่องในรหัสที่กำลังทดสอบ แน่นอนว่าดีกว่าที่จะแก้ไขข้อบกพร่องเหล่านั้น แต่อาจเป็นไปไม่ได้ในกรณีของห้องสมุดบุคคลที่สาม

Aaron Digulla: ฉันเห็นด้วย บางทีรายการนี้เหมาะสำหรับวิกิ "JUnit HOWTO" ที่ดีกว่าและไม่ใช่ antipattern ความคิดเห็น?

บททดสอบที่ไม่มีชื่อ - Nick Pellow

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

สองปีต่อมาเมื่อการทดสอบนั้นล้มเหลวคุณอาจต้องลองหา BUG-123 ในเครื่องมือติดตามบั๊กของคุณก่อนเพื่อค้นหาจุดประสงค์ของการทดสอบ

The Poke ช้า

การทดสอบหน่วยที่ทำงานช้าอย่างไม่น่าเชื่อ เมื่อนักพัฒนาเริ่มเขี่ยพวกเขามีเวลาไปเข้าห้องน้ำคว้าควันหรือแย่กว่านั้นเริ่มการทดสอบก่อนที่จะกลับบ้านในตอนท้ายของวัน (Src: โพสต์ของ James Carr )

หรือที่รู้จักในการทดสอบที่จะไม่ทำงานบ่อยเท่าที่ควร

ผีเสื้อ

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

ค้างคาวของปีกสามารถก่อให้เกิดพายุเฮอริเคนในอีกด้านหนึ่งของโลก - Edward Lorenz, The Butterfly Effect

The Flickering Test (ที่มา: Romilly Cocking)

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

อาจเป็นชุดสุดยอดในรูปแบบต่อต้าน' Wait and See ' และรูปแบบการต่อต้าน ' The Sleeper '

การสร้างล้มเหลวใช่แล้วเพียงเรียกใช้งานการสร้างอีกครั้ง - นักพัฒนานิรนาม

รอดู

การทดสอบที่เรียกใช้รหัสการตั้งค่าบางอย่างแล้วต้อง 'รอ' ระยะเวลาที่กำหนดก่อนที่จะสามารถ 'ดู' หากรหัสที่อยู่ภายใต้การทดสอบทำงานตามที่คาดไว้ วิธีทดสอบที่ใช้ Thread.sleep () หรือเทียบเท่านั้นแน่นอนที่สุดคือการทดสอบ "Wait and See"

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

การทดสอบดังกล่าวอาจเป็นLocal Heroเนื่องจากจะล้มเหลวเมื่อทำงานบนกล่องที่ช้ากว่าหรือเซิร์ฟเวอร์ CI ที่โอเวอร์โหลด

รอและดูรูปแบบการป้องกันไม่ให้สับสนกับนอน

Fixture Shared อย่างไม่เหมาะสม - Tim Ottinger
กรณีทดสอบหลายรายการในฟิกซ์เจอร์ทดสอบไม่แม้แต่ใช้หรือต้องการการตั้งค่า / การฉีกขาด ส่วนหนึ่งเป็นเพราะความเฉื่อยของนักพัฒนาเพื่อสร้างฟิกซ์เจอร์ทดสอบใหม่ ... ง่ายกว่าเพียงแค่เพิ่มกรณีทดสอบอีกหนึ่งกอง

ยักษ์

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

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

ฉันจะเชื่อเมื่อฉันเห็น GUIs ที่กระพริบ
การตรึง / ครอบงำจิตใจที่ไม่ดีต่อการทดสอบแอปผ่าน GUI ของมัน 'เหมือนกับผู้ใช้จริง'

การทดสอบกฎเกณฑ์ทางธุรกิจผ่าน GUI นั้นเป็นรูปแบบการเชื่อมต่อที่แย่มาก หากคุณเขียนการทดสอบนับพันผ่านทาง GUI จากนั้นเปลี่ยน GUI ของคุณการทดสอบหลายพันครั้งจะหยุดพัก
ค่อนข้างทดสอบสิ่ง GUI ผ่าน GUI และจับคู่ GUI กับระบบจำลองแทนระบบจริงเมื่อคุณรันการทดสอบเหล่านั้น ทดสอบกฎเกณฑ์ทางธุรกิจผ่าน API ที่ไม่เกี่ยวข้องกับ GUI - บ็อบมาร์ติน

“ คุณต้องเข้าใจว่าการมองนั้นกำลังเชื่อ แต่ต้องรู้ด้วยว่าการเชื่อกำลังเห็นอยู่” - Denis Waitley

The Sleeper หรือที่รู้จักในนาม Mount Vesuvius - Nick Pellow

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

'The Sleeper' ไม่ควรสับสนกับรูปแบบต่อต้าน' Wait And See '

รหัสนั้นจะถูกแทนที่มานานก่อนปี 2000 - นักพัฒนาจำนวนมากในปี 1960

ต้นไม้ที่ตายแล้ว

การทดสอบที่สร้างต้นขั้ว แต่การทดสอบไม่ได้ถูกเขียนขึ้นจริง

ฉันเห็นสิ่งนี้จริงๆในรหัสการผลิตของเรา:

class TD_SomeClass {
  public void testAdd() {
    assertEquals(1+1, 2);
  }
}

ฉันไม่รู้ด้วยซ้ำว่าจะคิดยังไง

ได้รับบิตโดยวันนี้:

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

ในกรณีของเราการทดสอบทิ้งไฟล์ไว้ใน "temp" dir โดยได้รับอนุญาตจากผู้ใช้ที่ทำการทดสอบครั้งแรก เมื่อผู้ใช้รายอื่นพยายามทดสอบบนเครื่องเดียวกัน: boom ในความคิดเห็นในเว็บไซต์ของ James Carr Joakim Ohlrogge เรียกสิ่งนี้ว่า "Sloppy Worker" และมันเป็นส่วนหนึ่งของแรงบันดาลใจสำหรับ "Generous Leftovers" ฉันชอบชื่อของฉันดีกว่า (ดูถูกน้อยกว่าคุ้นเคยมากกว่า)

The Cuckoo - Frank Carver
การทดสอบหน่วยซึ่งอยู่ในกรณีทดสอบกับคนอื่น ๆ และสนุกกับกระบวนการติดตั้ง (อาจยาว) เช่นเดียวกับการทดสอบอื่น ๆ ในกรณีทดสอบ แต่จากนั้นทิ้งสิ่งประดิษฐ์บางส่วนหรือทั้งหมดออกจากการตั้งค่า และสร้างของตัวเอง
อาการขั้นสูงของ: การติดตั้งร่วมกันอย่างไม่เหมาะสม

The Secret Catcher - Frank Carver
การทดสอบที่มองแวบแรกดูเหมือนจะไม่ทำการทดสอบเนื่องจากไม่มีการยืนยัน แต่ "ปีศาจอยู่ในรายละเอียด" .. การทดสอบนั้นขึ้นอยู่กับข้อยกเว้นที่จะถูกโยนทิ้งและคาดว่ากรอบการทดสอบจะจับข้อยกเว้นและรายงานให้ผู้ใช้ทราบว่าเป็นความล้มเหลว

[Test]
public void ShouldNotThrow()
{
   DoSomethingThatShouldNotThrowAnException();
}

ป่าเถื่อนด้านสิ่งแวดล้อม

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

การทดสอบเหล่านี้จะไม่ต่อเนื่องและปล่อยให้นักพัฒนาพูดว่า 'เรียกใช้อีกครั้ง'

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

การทดสอบของทัวริง

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

สวัสดีโง่ - คอมพิวเตอร์ที่ฉลาดที่สุดในโลกไปจนถึงเด็กฝึกงานใหม่ (จากการ์ตูนเอมิกาเล่มเก่า)

การทดสอบเสาเท้าสี่สิบ

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

Doppelgänger

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

รูปแบบนี้ระบุจำนวนการพึ่งพาที่ไม่ดีต่อสุขภาพซึ่งคุณไม่สามารถควบคุมได้จากการทดสอบ

ฉันมองที่ใบหน้าของเขา ... ใบหน้าของฉัน! มันเหมือนกระจก แต่ทำให้เลือดฉันแข็ง

The Mother Hen - Frank Carver
การตั้งค่าทั่วไปซึ่งทำได้มากกว่ากรณีทดสอบจริง ตัวอย่างเช่นการสร้างโครงสร้างข้อมูลที่ซับซ้อนทุกประเภทซึ่งมีค่าที่สำคัญและไม่เหมือนใครเมื่อการทดสอบยืนยันว่ามีหรือไม่มีของบางอย่างเท่านั้น
อาการขั้นสูงของ: การติดตั้งร่วมกันอย่างไม่เหมาะสม

ฉันไม่รู้ว่ามันทำอะไร ... ฉันกำลังเพิ่มอยู่ในกรณี - นักพัฒนานิรนาม

ทดสอบทุกอย่าง

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

ฉันเจอหลายครั้งแล้วที่การทดสอบที่ฝ่าฝืนกฎนี้เป็นฝันร้ายที่ต้องรักษาไว้

สายตี

ในการทดสอบลุคแรกนั้นครอบคลุมทุกอย่างและเครื่องมือการครอบคลุมโค้ดยืนยันด้วย 100% แต่ในการทดสอบความเป็นจริงจะมีเฉพาะโค้ดที่ไม่มีการวิเคราะห์ผลลัพธ์ใด ๆ

ครอบคลุม VS-สามารถเข้าถึงรหัส