Question

我一直在学习TDD是什么，想到的一个问题是“测试”究竟是什么。例如，您是否调用Web服务，然后构建代码以使其工作？还是更多的单元测试导向？

Answer 1

一般情况下，测试可能是......

unit test测试软件的单个子组件，而不与其他类有任何外部依赖关系
integration test是测试两个独立系统之间连接的测试，即。他们的整合能力
acceptance test用于验证系统的功能

......以及其他一些我现在很可能暂时忘记的事情。

然而，在TDD中，您在创建软件时主要关注单元测试。

Answer 2

完全由单位测试驱动。

基本思想是首先编写单元测试，然后完成通过测试所需的绝对最小工作量。

然后编写更多测试以涵盖更多需求，并实现更多功能以使其通过。

这是一个迭代过程，包括测试编写循环，然后编写代码。

Answer 3

以下是Unclebob的几篇好文章

Three rules of TDD

TDD with Acceptance and Unit tests

Answer 4

我建议你不要强调测试，因为TDD实际上是一种软件开发方法，而不是测试方法。

Answer 5

我想说的是单元测试和代码覆盖。它是关于运送无bug代码并且能够在将来轻松进行更改。

参见鲍勃叔叔的words of wisdom。

Answer 6

我如何使用它，它以单元测试为导向。假设我想要一个方形的方法我写这个方法：

int square(int x) { return null; }

然后写一些测试，如：

[Test]
TestSquare() 
{
Assert.AreEqual(square(0),0);
Assert.AreEqual(square(1),1);
Assert.AreEqual(square(10),100);
Assert.AreEqual(square(-1),1);
Assert.AreEqual(square(-10),100);
....
}

好吧，也许正方形是一个不好的例子:-)

在每种情况下，我测试预期的行为和所有边界值，如maxint和零和null值（记住你也可以测试错误）并看到测试失败（这不难:-)）然后我继续工作，直到它工作。

所以：首先是一个单元测试，它无法覆盖你想要覆盖的内容，然后是方法。

Answer 7

通常，“TDD”中的单元测试不应涉及任何IO。

事实上，如果您编写的对象不会产生副作用（I / O几乎总是，如果不是总是，副作用！），那么您将获得更高的效果，并定义您的类的行为无论是在方法的返回值方面，还是对已经传递给对象的接口的调用。

Answer 8

我只是想就这个主题发表看法，这可能有助于以不同的方式理解TDD。

TDD是一种先依赖测试的设计方法。因为你问过测试是怎么回事，生病了：

如果你想构建一个应用程序，你知道你想要构建什么的目的，并且你通常知道当你完成或者你需要测试它的方式时，例如检查你通过代码创建的变量的值检查，快速放下一个可以点击的按钮，执行部分代码并弹出一个对话框，显示操作结果等。

另一方面，TDD会改变你的心态，我会指出其中一种方式。通常，您只需依靠像visual studio这样的开发环境来检测代码和编译时的错误，并在您脑海中的某个地方，您知道需求，只需通过按钮和弹出窗口或代码检查进行编码和测试。我将这种风格称为SDDD（语法调试驱动开发）。但是当你做TDD时，是一个语义调试驱动的开发＆＃34;因为你首先通过使用测试（以及更加动态和可重复的白板版本）来记录你的应用程序的想法/目标，测试应用程序的逻辑（或＃34;语义＆＃34;）并且每当失败即使您的应用程序通过语法错误（编译时），您也会出现语义错误。

Answer 9

顺便说一句，即使我说“你知道你想要建立什么目的......”，在实践中你可能不知道或拥有构建应用程序所需的所有信息，因为TDD有点迫使你写首先进行测试，你不得不在开发的早期阶段提出更多关于应用程序运行的问题而不是建立很多问题只是为了发现你所写的很多东西都不是必需的（或者不要在时刻）。你真的可以避免浪费宝贵的TDD时间（尽管最初可能不会这样）

测试驱动开发 - 测试究竟是什么？

9 个答案: