问题标签 [tdd]

我已经开始使用 TDD。如前一个问题所述，最大的困难是处理界面更改。随着需求的变化，您如何减少对测试用例的影响？

如何在 .NET 中编写单元测试？

特别是 Visual Studio 2005？

人们如何模拟 TcpClient（或 TcpClient 之类的东西）？

我有一个接受 TcpClient 的服务。我应该用其他更可笑的东西来包装它吗？我应该如何处理这个？

大约一年前，我阅读了 Scott Ambler 的重构数据库：进化数据库设计。我被这样的想法所说服，就像您可以使用 TDD 开发代码一样，您可能应该（至少）使用单元测试覆盖您的数据库，甚至在更改架构之前编写数据库测试，以便您进行数据库工作也是 TDD 风格。

我真的很喜欢这个想法，并且我一直在手动执行此操作（好吧，有时我会执行此操作）一段时间，只是编写规则的单元测试，这些测试恰好连接到数据库并根据给定的模式文件检查其结构。但是我还没有找到任何可以帮助自动化这个过程的好的数据库变更管理工具包。有人知道吗？

为什么这个项目不再维护了？我喜欢这个应用程序，但不更新它似乎是对所有 .Net 开发人员的犯罪。考虑到未来发布的机会，我很想添加几个项目。

有人可以分享我不知道的东西吗？

想象一下，您正在实现包含各种新功能并增加代码库复杂性的用户故事。现有代码已经很好地覆盖了，您刚刚决定了接口。您开始实现从测试开始的功能。

现在，您有基于需求的相当复杂的测试用例，但是当您能够提交 SCM 完全工作的代码并且许多测试失败（应该如此）时，实现还远远不够。

假设在持续集成中，如果可能，所有构建都应该是绿色的，因此您不应该提交，因为您会破坏构建。但是你也不应该“变暗”并为自己保留这么多的代码......

在这种情况下建议的程序是什么？

我做 TDD，我在组织单元测试方面相当松散。我倾向于从代表下一个故事或功能块的文件开始，并编写所有单元测试以使其工作。

当然，如果我要引入一个新类，我通常会为该类制作一个单独的单元测试模块或文件，但我不会将测试本身组织成任何更高级别的结构。结果是我快速编写代码，并且我相信我的实际程序结构合理，但是单元测试本身是“混乱的”。特别是，它们的结构倾向于概括发展过程的系统发育。有时我认为自己是在用代码中的懒惰来换取测试中的懒惰。

这是一个多大的问题？谁在这里不断地重构和重组他们的单元测试以试图改进他们的整体结构？对此有什么建议吗？测试的整体结构应该是什么样子。

（请注意，我并不是在问“每个函数有多少断言”问题：我应该为每个函数/方法编写多少单元测试？我说的是更大的图景。）

我发现关于 TDD 的一点是，设置测试需要时间，而且我天生懒惰，我总是希望编写尽可能少的代码。我似乎做的第一件事是测试我的构造函数是否设置了所有属性，但这是否矫枉过正？

我的问题是您编写单元测试的粒度级别是多少？

..是否存在测试过多的情况？

我是一名经验丰富的合同程序员。我习惯于被客户雇佣，自己去做一个或另一种形式的软件项目，通常是白手起家。这意味着几乎每次都是白纸黑字。我可以引入我开发的库来快速入门，但它们始终是可选的。（并且取决于在合同中获得正确的 IP 条款）很多时候我可以指定甚至设计硬件平台......所以我们在这里谈论的是严肃的自由。

我可以看到为某些代码构建自动化测试的用途：具有不仅仅是琐碎功能的库、具有大量引用的核心功能等。基本上，随着一段代码的价值通过大量使用而上升，我可以看到它自动测试该代码会越来越有价值，这样我就知道我不会破坏它。

然而，在我的情况下，我发现很难合理化除此之外的任何事情。我会采用被证明有用的东西，但我不会盲目地遵循任何东西。

我发现我在“维护”中所做的许多事情实际上都是很小的设计更改。在这种情况下，测试不会为我节省任何东西，现在它们也必须改变。高度迭代、存根优先的设计方法对我来说非常有效。我看不到通过更广泛的测试实际上为自己节省了那么多时间。

爱好项目更难证明......它们通常是从周末到一个月的任何东西。边缘情况的错误很少有关系，这都是关于玩一些东西。

阅读诸如this one之类的问题，投票最多的回复似乎是说，在该发布者的经验/意见中，如果您的人数少于5人，TDD实际上会浪费时间（即使假设具有一定水平的TDD能力/经验）。但是，这似乎涵盖了初始开发时间，而不是维护时间。目前尚不清楚 TDD 如何在项目的整个生命周期中叠加。

我认为 TDD 可能是朝着提高整个行业产品质量这一有价值目标迈出的重要一步。不过，理想主义本身不再能有效地激励我。

我确实认为 TDD 在大型团队或包含至少一个不可靠程序员的任何规模的团队中是一种好方法。那不是我的问题。

为什么拥有良好记录的唯一开发人员会采用 TDD？

我很想听听关于 TDD 的任何类型的指标（正式或非正式）......专注于单独的开发人员或非常小的团队。

如果做不到这一点，你个人经历的轶事也会很好。:)

请避免在没有经验的情况下发表意见来支持它。让我们不要把这变成一场意识形态战争。还有跳过更多就业选择的论点。 这只是一个效率问题。

我知道北卡罗来纳州立大学对 TDD 进行了一些研究。他们发表了一篇名为“工业测试驱动开发的初步调查”的论文。可以在此处找到 NCSU 的其他出版物。

有人能指出我关于这个主题的其他好的出版物吗？