在早期阶段编写测试是否合理？

Question

我曾经在开发我的软件时编写测试，但我停止了它，因为我注意到，几乎总是，第一个api和我认为很棒的结构在经过一些进展后变得笨拙。我需要每次都重写整个主程序和整个测试。

我相信这种情况在现实中很常见。所以我的问题是：

• 首先编写测试是否真的常见，就像在TDD中所说的那样？我只是一个业余程序员，所以我不知道真正的开发世界。
• 如果是这样，人们在修改软件api /结构时会再次（又一次）重写测试吗？ （除非他们足够聪明，一开始能想出最好的一个，不像我。）

Answer 1

当你不知道你正在建造什么时，我不知道有谁推荐TDD。除非您之前创建过非常类似的系统，否则您首先进行原型设计，而不使用TDD。然而，最终将原型投入生产却没有使TDD过程发挥作用，这是非常危险的。

正确的做法是......

一个。抛弃原型，然后重新使用TDD（仍然可以从原型中逐字逐句地借用一些代码，只需在实际的TDD循环后重新实现）。

B中。改造单元测试到原型，然后从那里进行红色，绿色，重构。

Answer 2

  

但是我停止了因为我注意到，几乎总是，我认为很好的第一个api和结构在经过一些进展后变得笨拙

测试驱动开发应该可以帮助您进行设计。当你为它编写测试时，一个“笨拙”的API会变得笨拙。

  

首先编写测试是否真的很常见，就像在TDD中所说的那样？

取决于开发人员。我使用测试驱动开发占我写的99％。它有助于我编写的API和应用程序的设计。

  

如果是这样，人们在重新修改软件API /结构时会再次重写测试吗？

取决于测试的级别。希望在一个大型重构（也就是你重写一大块代码的时候）中，你可以通过一些测试来覆盖你将要完成的工作。一些单元测试将被丢弃，但集成和功能测试将非常重要。他们告诉你什么都没有被打破。

你可能已经注意到我已经写了一个编写测试驱动开发而不是“TDD”的观点。测试驱动开发不仅仅是“首先编写测试”，而是允许测试推动开发周期。您编写的测试将极大地影响您的API设计（例如，单例或服务定位器将替换为IoC）。编写好的API需要练习和学习，以聆听您可以使用的工具。

Answer 3

纯粹主义者说是的，但在实践中它有点不同。有时我会编写六个测试然后编写传递它们的代码。其他时候我会在编写测试之前编写几个函数，因为这些函数不能单独使用或者测试很难。

是的，您可能会发现需要将测试重写为API更改。

对于纯粹主义者来说，他们甚至会承认有些测试比没有测试更好。

Answer 4

  

在早期阶段编写测试是否合理？

• 否，如果您正在编写top-down-design高级别integrationtests，需要真正的数据库或互联网连接到其他网站才能工作
• 是，如果您使用bottom-up实现unittesting（=单独测试模块）

＆＃34;等级越高＆＃34;单元测试变得越困难，因为你必须引入更多的模拟/抽象。

在我看来，tdd的架构优势仅适用于与单元测试相结合，因为这会驱动Separation_of_concerns

当我开始使用tdd时，我必须在更改api / architecture时重写许多测试。随着今天经验的增长，只有少数情况需要这样做。

Answer 5

您应该拥有第一层测试，以验证API的外部可见行为，无论其内部是什么。

当出现新的功能需求时更新此类测试不是问题。在你提到的例子中，很容易适应被删除的新网站 - 你只需要在测试中添加新的断言来解释所获取的新数据。

＆＃34;抓取代码必须完全修改＆＃34; 这一事实不会影响这些更高级别测试的结构，因为从外部来看，API应该和以前完全一样消费。

如果这样的低级别技术细节确实会影响您的高级别测试，那么您可能错过了描述 数据的抽象概念，但隐藏了如何<的详细信息/ strong>检索它。

Answer 6

在编写实际代码之前编写测试意味着您知道应用程序的设计方式。这种情况很少发生。

事实上，我开始在一个文件中编写所有内容。它可能有一些徘徊或更多的线。通过这种方式，我可以轻松快速地重新设计api。后来，当我决定喜欢它并且它很好时，我开始通过将所有内容放入有意义的命名空间和单独的文件来重构它。

完成此操作后，我开始编写测试以验证一切正常并找到错误。

TDD只是一个神话。如果您刚开始，则无法先编写测试，然后再编写代码。

你总是要记住KISS规则。如果你需要一些疯狂的东西来测试你自己的代码，如假货或嘲笑你已经失败了。