在TDD中,在编写空方法之前运行测试有什么好处?

然后通过先写方法名来尝试。我发现,通过先编写测试和方法,它迫使我真正思考API,我可以轻松地更改名称,而不必担心已经编写的代码。我的建议是尽量不遵守规则,并监控发生的情况。如果您发现它会导致问题,请切换回。如果没有,你现在就有了新的工作方式。

1) 写你的测试 议论 好像目标对象和 API已经存在。

2) 编写足够的API代码来

3) 取消对测试代码的注释。

4) 运行测试并查看它是否失败。

5) 编写足够的代码来获得它 通过。

6) 运行测试并查看它是否通过

思考 先测试,而不是先实现。

Eclipse和JUnit中的工作流(与VisualStudio和MSTest相反)是步骤1-3最有意义的地方。第3步只是使用Eclipse的快速修复功能(Ctrl-1)根据您刚刚编写的单元测试生成存根代码。

int result=someObject.newMethod(“123”);

第一行的快速修复程序将自动创建DoesntExistYet类(让您先通过向导进行调整),下一个快速修复程序将为您创建新方法,根据您使用它的方式适当地计算签名。

因此,随着所有这些自动化的规范化使事情变得更容易,您接下来将讨论人们提到的其他优势,即通过您将如何使用API来规范您的API。

在极少数情况下,您可能会发现该方法确实存在(IntelliSense也可能有助于检测),并且您可能会意识到需要更改所需的方法签名。或者,您甚至可能发现根本不需要编写该方法(可能是上周编写的,但忘记了)。

当然,您可以选择跳过前两个步骤,甚至完全不使用TDD,但这些步骤确实是有目的的。不过,我同意一般人的看法,即在任何“最佳做法”中,对这些步骤背后的理由进行更多描述,我们总能从中受益。

编辑:来自贾斯汀标准。。。

你依赖的是什么。我认为对于大多数开发人员来说,这是一个相当常见的场景。

类,我觉得您的继承层次结构太复杂了。我仍然投票 因为我同意我需要更多的时间来验证一个方法是否已经不存在,所以请您停止 如果从单元测试开始,则存在。

@senfo:继承层次结构中肯定会出现太多的复杂性,但这是一个不同的问题,有一个明显的解决方案。即使您现有的代码是完美的,从一个单元测试开始,尝试调用一个可能不存在的方法,只是为了快速向自己证明它不存在,这仍然是有价值的。当然,跳过这一步是可以理解的——我可能会在我的测试出现错误的特定情况下返回到这一步(以验证在特定情况下我没有调用我刚刚编写的内容以外的其他内容)。

编写测试首先迫使您决定接口

但这已经足够了!接口是您必须在其中编码的框;忽略它们,只需开始编码,在使用它之前,您通常必须返工您的工作

编辑:我真的应该更仔细地阅读这个问题,OP正在寻找一个更具体的答案。就是这样:省略VisualStudio中的步骤2,而是存根方法/类。当一个人使用的工具显然不需要遵循这个扩展的食谱时,没有理由学究气。

如果您使用更强大的代码编辑IDE,比如Java中的IDE(Eclipse、Netbeans、IntelliJ),那么前两个步骤更有意义。那里提供的快速修复和代码生成工具,使得针对不存在的类或方法编写测试成为创建特定类或声明特定方法的最快方式;只需按下一个按钮,就会为您生成缺少的类或方法。编写方法调用或对象实例化比先创建类或方法,然后使用它们更快。例如,一旦调用了一个方法,方法名和参数类型就会给出该方法的签名,因此IDE很容易创建它们。这真的是一个很棒的过程,我不会以任何其他方式编程。结合在api存在之前实际使用它的优点,您描述的执行TDD的方法非常有意义。

对于VisualStudio用户,如果要共享此体验,请安装VisualStudio的Resharper插件。这将提供许多与JavaIDE相同的特性。

看到它崩溃可以确保您没有在测试代码中出错,并且从一开始就构建了一个工作测试。

此外,尝试“使用”API会使您从不同的角度(即API的角度)来考虑它 )这几乎总是有益的。这样做很重要 之前 您尝试编写API(始终从API的角度编写) ).很难解释使用自己的API的价值,但行业术语是 dog-fooding

至于VisualStudio对TDD的支持,我同意intellisense有时会成为阻碍,但实际上您可以使用VS进行TDD,尽管它仍然有一定的局限性。如果测试方法引用了被测试类上不存在的方法,则可以通过按Ctrl-K、Ctrl-M让VS为您创建存根。

这里的危险在于,在编写第一个测试时,您预先假定了您的API。其中一个技巧是在开始编写代码之前,先考虑第一个测试——也许是写在纸上,或者至少是在VS之外。一旦知道API需要的方法,就可以继续执行步骤3,然后回溯(关于VS)到步骤1并编写实际测试。

我承认,我通常在脑子里做这件事,并且也从第(3)步开始。

我认为使用像Resharper这样的工具将帮助您更好地感受TDD。对我来说确实如此。

这不是测试驱动的开发 按规则 "official" TDD process

• 快速添加一个测试
• 运行所有测试并查看 新的
• 制造 小的 改变
• 运行测试并查看它们 都成功了
• 重构以消除重复

如果您使用的是立即显示编译错误的语言/IDE组合,则这将被视为失败的编译周期。

我同意其他受访者的看法,我认为这只是那些天真的人,他们试图不经思考就做“正确的事情”。他们听说你应该先写测试再写 任何

this answer to another question ,先动动脑筋!这是最好的做法。