logo标签列表

首次使用TDD，简单的两层C#项目 - 我需要对什么进行单元测试？

unit-testingtddnunit
4
这可能是一个愚蠢的问题，但我的搜索没有找到令人满意的答案。我正在用C#开始一个小项目，只有业务层和数据访问层 - 奇怪的是，UI稍后才会出现，而且我对它的外观几乎没有（读作：没有）概念/控制。
我想尝试在这个项目中使用TDD。我正在使用Visual Studio 2008（即将升级为2010），我有ReSharper 5和nUnit。
再次强调，我想采用测试驱动开发，但不一定是整个XP系统。我的问题是 - 我何时何地编写第一个单元测试？
我只测试逻辑之前还是测试所有内容？测试没有理由失败的事物似乎是低效的（自动属性，空构造函数）...但似乎“没有新代码没有失败的测试”原则要求这样做。
链接或参考资料都可以（但最好是在线资源，而不是书籍 - 我想尽快开始）。
感谢您提前的任何指导！
4个回答
4

测试那些没有失败可能的事情（自动属性、空构造函数）似乎是不划算的...

确实如此...空构造函数或自动属性没有逻辑可言，也就不需要测试。

我应该在什么时候编写第一个单元测试？

在编写可测试代码的第一行之前。先考虑你想让方法执行什么行为，然后根据所需行为编写测试。这个测试（以及随后的所有测试）体现了你程序的规范。

我应该在哪里编写第一个单元测试？

在你创建的第一个测试类中。

这可能是最好的在线资源：

介绍测试驱动设计（TDD）
http://www.agiledata.org/essays/tdd.html

好的。所以这不是编写一个测试来检查我已经计划好的代码...而是编写一个测试，有点像作为我即将要编写的代码的计划？ - Joel
1
是的，基本上是这样。在编写测试后，您编写代码以通过测试，测试仍然作为回归测试来证明该方法仍符合要求，以防重构。此外，可能会有多个测试来指定方法的整体要求。 - Robert Harvey
2
在进行TDD时，需要转变思维方式。如果你不使用TDD，通常会先写一些代码，然后编写单元测试以确保代码符合预期，并处理一些不同的特殊情况。而在TDD中，你实际上是首先编写一个测试，这个测试通常会使用你甚至还没有编写的类和方法。
一旦你编写了测试，并且确认测试是如何使用你的代码的一个好例子，你开始编写实际的类和方法来使测试通过。
一开始可能有点困难，因为你没有智能感知帮助，你的代码在实现生产代码之前都不会构建，但通过先编写测试，你被迫考虑如何使用你的代码，甚至在编写代码之前就开始思考。
2
似乎测试没有失败的原因（自动属性，空构造函数）是一种逆向思维...
这可能看起来是逆向思维的，但如果您的代码依赖于新构造对象的默认状态，则值得测试。有人可以更改字段的默认值，导致您的代码出现故障。
记住，您的测试不仅是为了找到失败的事物，而且还要验证您的代码是否符合其公布的契约。您可以说您不需要担心 - 如果合同破裂，则依赖该合同的代码也将中断。这是正确的，但会产生“远程”问题的测试失败。理想情况下，类的问题应首先在其自己的单元测试中导致失败，而不是在其客户端的单元测试中导致失败。
没有任何需求或设计的TDD很难实现。传统编码中，您坐下来敲出所需的内容，需求随着代码的发展而发展 - 随着您深入挖掘并详细了解所需的内容，需求几乎来自代码。但是，在TDD中，测试是需求的具体体现，因此您必须事先清楚地了解这些需求。如果您从一张空白的纸开始，则必须同时进行需求分析，测试设计和代码设计。
1
一种引导 TDD 的方法是先编写一个集成测试，即在任何单元测试之前。这个集成测试旨在证明您的应用程序在端到端意义上按预期工作。
显然，应用程序尚未编写，因此您的初始集成测试不会检查很多内容。例如，假设您正在编写一个数据处理程序，该程序应分析一个平面文件并生成摘要报告。一个简单的端到端测试将调用程序，然后确认在预期位置生成了一个文件。该测试将失败，因为您的应用程序还没有做任何事情。
然后，您编写一个最小版本的应用程序来满足简单的集成测试。例如，该应用程序将运行并将摘要报告的硬编码标题写入文件。以其当前形式，您的应用程序有时被称为“行走的骨架”——最薄可能的有些现实功能的切片。
从那时起，您可以给骨架添加肉——当然，在编写每个新功能之前编写测试。一旦开始这样做，“首先测试什么”这个问题就变得更加可操作，您的许多新测试将是单元导向的（而不是集成导向的）。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接