我对TDD非常新鲜，首先想到的问题是是否应该将单元测试应用于每个开发组件。我之所以问这个问题是因为我观察到单元测试需要很多时间，特别是在提供一些需求变更时。那么，您能否就TDD中有关单元测试的最佳实践提出建议？
4个回答
4
只是一个观察 - 你说过：
我注意到单元测试需要很多时间，这在短期内是真的。但对于将要存在一段时间的代码来说，额外的工作可以节省时间。我曾经在参与的一个项目上强调了单元测试的价值，告诉每个人都要听，“我们没有时间跳过这一步。”这是真的。有许多地方可以节省时间 - 测试人员会花费更少的时间来测试应用程序，通过您使用的任何bug跟踪流程将错误退回，您将花费更少的时间记住几周或几个月后你可以修复错误，用户将看到更少的错误，这意味着他们将花费更少的时间因应用程序出现故障而向您抱怨。在下班后的2点，您将花费更少的时间在电话中希望您能在第二天用户到来之前修复应用程序。
这在某种程度上归结为经济学。对于任何要投入生产的代码，请相信我，您没有时间跳过这一步。这将花费您更多的时间和公司更多的现金。
如果代码不会进入生产环境，也就是说，它是您编写的用于帮助某些任务或查看网络层实际工作情况的实用程序，您需要调整所需的测试量。经验将帮助您了解正确的测试量。
我注意到单元测试需要很多时间，这在短期内是真的。但对于将要存在一段时间的代码来说，额外的工作可以节省时间。我曾经在参与的一个项目上强调了单元测试的价值，告诉每个人都要听，“我们没有时间跳过这一步。”这是真的。有许多地方可以节省时间 - 测试人员会花费更少的时间来测试应用程序，通过您使用的任何bug跟踪流程将错误退回，您将花费更少的时间记住几周或几个月后你可以修复错误，用户将看到更少的错误，这意味着他们将花费更少的时间因应用程序出现故障而向您抱怨。在下班后的2点，您将花费更少的时间在电话中希望您能在第二天用户到来之前修复应用程序。
这在某种程度上归结为经济学。对于任何要投入生产的代码，请相信我，您没有时间跳过这一步。这将花费您更多的时间和公司更多的现金。
如果代码不会进入生产环境，也就是说，它是您编写的用于帮助某些任务或查看网络层实际工作情况的实用程序，您需要调整所需的测试量。经验将帮助您了解正确的测试量。
- Don Branson
1
2所有的测试都需要很多时间。TDD让它变得明显。在编写后进行测试会使其不太明显。 - S.Lott
1
TDD意味着测试驱动组件的开发。您首先编写一个单元测试，指定组件的行为，然后实现该组件。因此，回答您的问题：
“应该对每个开发的组件应用单元测试吗？”
不需要，因为在开发组件之前应该已经编写好了单元测试。
“应该对每个开发的组件应用单元测试吗？”
不需要，因为在开发组件之前应该已经编写好了单元测试。
- Darin Dimitrov
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接