在编写功能之前或之后编写单元测试吗？

Question

我想知道大多数人在什么时候写单元测试。我通常在编写初始代码后编写测试，以确保它的工作方式符合预期。然后我修复了破碎的东西。

我使用这种方法非常成功，但一直想知道是否可能首先转向编写测试是否有利？

Answer 1

尽可能我尝试遵循纯TDD方法：

1. 为正在开发的功能编写单元测试 ;这迫使我决定公共界面
2. 尽快编写功能（尽可能简单，但不简单）
3. 正确/重构/复检
4. 额外测试如果需要以获得更好的覆盖率，特殊路径等[很少见但值得考虑]
5. 重复下一个功能

很容易激动并首先开始编写该功能，但这通常意味着您不会提前考虑所有公共接口。

编辑：请注意，如果您先编写代码，很容易无意中编写测试以符合代码，而不是相反的方式！

Answer 2

我真的希望首先编写代码，而且经常这样做。但我做真正的TDD越多，我拒绝在测试中编写任何代码，我发现越多，我编写了更多可测试的代码和更好的代码。

所以，是的，先写下测试。它需要意志力和决心，但它确实产生了更好的结果。

作为额外的奖励，TDD确实帮助我将注意力集中在一个有分心的环境中。

Answer 3

我遵循TDD方法，但我并不像某些人那样纯粹主义。通常情况下，我会在类/方法中粗略地使用简单地抛出NotImplementedException的存根。然后我将开始编写测试。一次一个功能，一次一个测试。通常情况下，我会发现我错过了一个测试 - 也许在编写其他测试时或者当我发现错误时 - 然后我会回去编写一个测试（并在必要时修复错误）。

使用TDD有助于保持代码与YAGNI（您不需要它）保持一致，只要您只编写需要开发的功能的测试，并且只编写最符合您测试的代码。

Answer 4

我们尝试先写下它们，但我会完全承认，我们的环境有时很混乱，有时这一步最初会被传递并稍后写出。

Answer 5

我通常在编写代码之前编写一份我将要编写的单元测试列表，然后实际编写单元测试代码，但这是因为我使用程序生成单元测试存根然后修改它们来测试适当的案例。

Answer 6

我倾向于使用单元测试来测试代码，因为我正在编写代码。这样我就可以同时使用我正在编写的内容，因为我在编写代码时使用单元测试来测试代码。就像控制台应用程序一样。

有时我甚至编写了没有断言的测试，只是调试输出，只是为了测试我使用的东西是如何工作的，没有例外。

所以我的答案是，经过一些编码后。

Answer 7

我使用测试驱动开发（TDD）来生成我的大部分生产代码，因此我首先编写单元测试，除非我正在研究不可测试的遗留代码（当编写测试的标准太高时）。

否则，我编写代码应满足的功能级验收测试。

首先编写单元测试让我准确地知道“我在哪里”：我知道到目前为止编码的内容是可操作的，可以集成或发送给测试团队;它不是没有bug但它有效。

Answer 8

我会提议我在编写单元测试时相当新，并且我希望在编写代码之前编写它们。或者，至少更好地理解如何编写更多可测试代码以及​​更好地理解依赖注入这样的概念，这似乎对编写可测试代码至关重要。

Answer 9

通常我会在代码之前编写单元测试。它们非常有用，并且在代码才有意义之前编写它们。依赖注入非常适合单元测试。依赖注入允许模拟部分代码，因此您只测试一个特定的单元，即您的代码是松散耦合的，因此很容易换出不同的（在这种情况下是模拟的）实现。