测试驱动开发背后的理念[关闭]

似乎最终编写的测试和实际代码一样多。

是的,有时测试比实际代码多。您似乎缺少的好处是,当您更改一些看似不相关的代码时,对小事情的测试将有助于您以后的工作,而旧的测试将中断。

设计

TDD和生成回归套件一样有价值,或者可能比生成回归套件更有价值 设计

AgileData.org说 this way

一种观点认为TDD的目标是规范而不是验证。换句话说,这是在编写功能代码之前仔细考虑设计的一种方法。

你可能会发现整篇文章都很有趣,尤其是 Myths and Misconceptions

^不 可能的路径可以通过代码。这意味着对于一些实际上可能非常小的方法,可以使用的方法的数量可能比方法本身要多得多。

下面是一个常见的场景:

if (@user.posts.count > @limit.posts)
  # Branch 1
  flash.now[:error] = "You have posted too many times today."
elsif (@user.suspended?)
  # Branch 2
  flash.now[:error] = "Your account is suspended. You cannot post."
else
  if (@post.special? and !@user.can.post_special?)
    # Branch 3
    flash[:warning] = "You cannot create special posts."
    @post.special = false
  # else
    # Branch 4
    # Not branching also has to be tested
  end

  if (@user.recently_created?)
    # Branch 5
    @post.newbie = true
  # else
    # Branch 6
  end

  # Branch 7
end

unless (flash[:error])
  @post.save!
end

如果不使用自动测试来测试这些单独的案例中的每一个,那么由于不经意的改变而导致故障的可能性是很大的。为了确保它的工作,你将不得不手动运行这些路径,往往你会忘记一个,后来这将导致麻烦,可能是尴尬的品种。

例如,减少测试的方法是通过消除不能增加业务价值的业务逻辑来降低代码复杂性。只保留最重要的东西,抛弃多余的东西。

如果你在为一些本应简单的东西编写上千个不同的测试,也许在设计方面还不够简单。

It seems that you end up writing as many tests as actual code

这就是我的想法。

有一套测试,即使设置标题也需要运行,这是TDD背后的想法。这样你就不会强迫别人活下去,说“哦,头衔不在了”。你有一套回归测试,这样当你越来越多地在一个项目上工作时,当你回到一个已经几个月没有接触过的项目时,你就不会把事情搞砸。

在我的团队中,除了UI,我们为所有东西编写了单元测试。 有一些工具可以帮助测试UI,但是我们认为UI(比如title)过于动态,无法进行测试。

这就是为什么在为web编写代码时,很多人更喜欢MVC设计模式,它在ui和代码背后造成了很大的分离,因此它允许您用单元测试覆盖几乎所有的代码。

是的,我们写了很多单元测试!!这是唯一真正知道你的代码真正工作的方法!

设计周期 在项目中,TDD迫使您考虑应用程序的代码接口 之前 Geoff Lanotte mentioned .

在 开发周期 ,只需编写使单元测试通过所需的代码。您不必再为设计细节操心了,这样您就可以专注于实际的实现。

在 生命周期