ฉันควรมีการทดสอบหน่วยสำหรับข้อบกพร่องที่รู้จักหรือไม่?

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

คำตอบคือใช่คุณควรเขียนพวกเขาและคุณควรเรียกใช้พวกเขา

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

อยากรู้อยากเห็นการทดสอบความล้มเหลวที่จู่ ๆ ก็สามารถเป็นที่น่าสนใจเช่นเดียวกับการทดสอบผ่านที่ล้มเหลวโดยไม่คาดคิด

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

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

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

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

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

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

สิ่งนี้มาพร้อมกับการประชุมในทีมของคุณเพื่อลดจำนวน@Ignoreการทดสอบ d เช่นเดียวกับที่คุณทำกับการแนะนำหรือเปลี่ยนแปลงการทดสอบเพื่อสะท้อนข้อผิดพลาดยกเว้นว่าคุณจะไม่สร้างบิลด์หากสิ่งนี้สำคัญสำหรับทีมของคุณเช่น OP กล่าวว่าการแก้ไขข้อผิดพลาดจะไม่รวมอยู่ในรีลีสปัจจุบัน .

ขึ้นอยู่กับเครื่องมือทดสอบที่คุณอาจใช้omitหรือpendฟังก์ชั่น

ตัวอย่างในทับทิม:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

omitคำสั่งข้ามการทดสอบที่omit_ifรวมกับการทดสอบ - ในตัวอย่างของฉันฉันทดสอบหมายเลขรุ่นและดำเนินการทดสอบเท่านั้นสำหรับรุ่นที่ผมคาดว่าข้อผิดพลาดได้รับการแก้ไข

ผลลัพธ์ของตัวอย่างของฉันคือ:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

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

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

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

ในโลกของฉันเราจะมีกรณีทดสอบด้วยตนเองที่ QEs ล้มเหลวจนกว่าข้อผิดพลาดจะได้รับการแก้ไข และเราในฐานะนักพัฒนาจะต้องตระหนักถึงมันด้วยตนเองผ่าน TC ที่ล้มเหลวและผ่านตัวติดตามบั๊ก

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

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

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

คุณมีเวลาเขียนการทดสอบหน่วยที่ล้มเหลวตอนนี้หรือไม่? มีฟีเจอร์หรือข้อผิดพลาดที่เร่งด่วนกว่าที่ต้องเขียน / แก้ไขหรือไม่

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

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

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