【发布时间】：2015-08-10 13:53:55
【问题描述】：
我正在和一个朋友讨论这个问题，虽然直觉上这似乎没有什么区别，但我想知道这里是否有人会想出一个很好的理由在单元测试之前或之后编写存根。
【问题讨论】：
标签： unit-testing testing tdd
【发布时间】：2015-08-10 13:53:55
【问题描述】：
我认为这并不重要，只要最终你拥有两者以便代码编译（或者，在解释语言的情况下，不会引发 找不到方法错误）。
但是，由于这是测试驱动开发，因此有必要先关注这些并先编写它们。有时，即使我清楚地知道我想如何构建我的代码，但只有在编写测试时我才意识到 API 是无用的并最终改变了它。在编写完测试后编写存根会使这更容易。
【讨论】：
-
“有时，即使我清楚地知道我想如何构建我的代码，但只有在编写测试时，我才意识到 API 是无用的，并最终改变了它。”这不是意味着先写存根更有意义吗？因为与编写或更改测试相比，编写或更改测试几乎不需要时间？
-
不，因为我只有在写完测试之后才能真正知道函数的接口，因为在写测试的时候我可能会意识到做事情可能更容易不同。编写存根实际上并没有那么难，所以最好推迟这样做，直到你确切知道你的函数被调用了什么以及它们做了什么，并且那是在你编写测试之后。
-
但是不知道函数的接口怎么写测试呢？我认为 TDD 的第一步是弄清楚这一点。
-
是的，当然。但是正如我所说，在实现测试时，您可能会意识到您提出的接口使用起来有点尴尬（尤其是在像 C 这样的语言中，如果您将它作为指针传递，您必须担心谁将拥有什么或整个事情，以及如何发出错误信号）您可能最终会改变主意，然后如果您已经编写了一个由于接口更改而不再工作的存根，这会很烦人，这样做更有用最后一步。
如果您正在执行 TDD，您将首先编写测试并同时实现任何所需的测试基础架构，例如存根，以便在您练习测试主题（也称为被测系统或 SUT）。
我很难想象在需要它们的测试之前编写存根，但也许这对你更有效——无论如何，很难将 TDD 作为一种工作方式，所以我的建议是坚持并找出最适合您的方法。
就我个人而言，无论如何我几乎都不会想到存根，因为使用模拟进行测试是我喜欢的工作方式（基于行为的验证而不是基于状态的验证）。你没有提到你正在使用什么工具；也许您的工具不容易获得用于模拟对象的好的工具包（尽管我怀疑您现在很难找到适用于大多数语言的东西）。尽管如此，我还是可以想到很多模拟对象库，比如 Java 工作，实际上我对其中的一两个有耐心，所以再次尝试并发现你最喜欢什么是有意义的。
【讨论】：