tdd - 为什么 TDD 测试方法如此静态？

Question

我看了几个关于测试驱动开发的视频，我基本理解了。但事实上，在我看过的所有视频中，方法都是静态的。所以在我的示例中，怪物必须始终有 100 点生命值，而攻击者有 70 点。那么当您只能涵盖一种情况时，这与测试有什么关系？

示例测试:

monster = Monster.new
monster.hitpoints = 100

hero = Hero.new
hero.strength = 70

hero.attack(monster)
monster.hitpoints.should == 30

代码如下:

class Monster
    attr_accessor :hitpoints
end

class Hero
    attr_accessor :strength
    def attack(monster)
        monster.hitpoints -= strength
    end
end

Answer 1

测试方法是静态的，因为您正在观看视频。它们为您提供了测试框架的概念和语法，不一定是“最佳”或“真实世界”实践。

在您的示例中，您需要检查一些边缘情况，这将导致看起来非常相似的测试。因此，将通用代码分解出来。

def test_post_attack_hitpoints(initial, strength, expected):
  monster = Monster.new
  monster.hitpoints = initial

  hero = Hero.new
  hero.strength = strength

  hero.attack(monster)
  monster.hitpoints.should == expected
end

test_post_attack_hitpoints(100, 70, 30)
test_post_attack_hitpoints(100, 110, -10) # do you actually expect -10?
test_post_attack_hitpoints(100, -10, 110) # can a hero's strength go negative? Should that heal the monster?

一般来说，视频和教程会教你做某事的绝对最低限度。学会把事情做好是一个经验问题。从学习其他人的经验开始。看看单元测试在备受推崇的开源项目中是如何构建的。我不一定能为您指出 Ruby 世界中的好例子，但是 Rails 的测试套件肯定已经被广泛使用并且可能是一个合理的起点。看看他们是如何组织事物的。

然后从自己的经验中学习。写一堆单元测试。什么运作良好，什么看起来愚蠢？找到一种可以解决您自己(或您的团队)需求的风格并照此去做。

我现在要离开我的肥皂盒了。