จะเกิดอะไรขึ้นกับการทดสอบเมธอดเมื่อเมธอดนั้นเป็นไพรเวตหลังจากถูกออกแบบใหม่ใน TDD?

สมมติว่าฉันเริ่มพัฒนาเกมสวมบทบาทกับตัวละครที่โจมตีตัวละครอื่นและสิ่งต่าง ๆ

ใช้ TDD ฉันสร้างกรณีทดสอบเพื่อทดสอบตรรกะภายในCharacter.receiveAttack(Int)วิธี บางสิ่งเช่นนี้

@Test
fun healthIsReducedWhenCharacterIsAttacked() {
    val c = Character(100) //arg is the health
    c.receiveAttack(50) //arg is the suffered attack damage
    assertThat(c.health, is(50));
}

บอกว่าผมมี 10 วิธีการทดสอบreceiveAttackวิธีการ ตอนนี้ผมเพิ่มวิธีการCharacter.attack(Character)(ที่โทรreceiveAttackวิธี) และหลังจากที่บางรอบ TDD ทดสอบนั้นผมตัดสินใจ: ควรจะเป็นCharacter.receiveAttack(Int)private

จะเกิดอะไรขึ้นกับ 10 กรณีทดสอบก่อนหน้า? ฉันควรจะลบมันเหรอ? ฉันควรรักษาวิธีpublic(ฉันไม่คิดอย่างนั้น)?

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

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

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

และหากไม่เป็นเช่นนั้นก็มีฟังก์ชั่นการทำงานreceiveAttackที่ไม่จำเป็นอีกต่อไปและไม่ควรมีอยู่อีกต่อไป!

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

หากวิธีการนั้นซับซ้อนพอที่จะต้องทำการทดสอบมันควรจะเปิดเผยในบางชั้นเรียน ดังนั้นคุณ refactor จาก:

public class X {
  private int complexity(...) {
    ...
  }
  public void somethingElse() {
    int c = complexity(...);
  }
}

ไปที่:

public class Complexity {
  public int calculate(...) {
    ...
  }
}

public class X {
  private Complexity complexity;
  public X(Complexity complexity) { // dependency injection happiness
    this.complexity = complexity;
  }

  public void something() {
    int c = complexity.calculate(...);
  }
}

ย้ายการทดสอบปัจจุบันสำหรับ X.complexity ไปที่ ComplexityTest จากนั้นส่งข้อความ X.something โดยการเยาะเย้ยความซับซ้อน

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

บอกว่าฉันมี 10 วิธีการทดสอบวิธี getAttack ตอนนี้ฉันเพิ่มเมธอด Character.attack (ตัวละคร) (ที่เรียกเมธอด getAttack) และหลังจากที่วงรอบ TDD ทำการทดสอบฉันตัดสินใจ: Character.receiveAttack (Int) ควรเป็นแบบส่วนตัว

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

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

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

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