在项目开始很久之后开始进行单元测试？

Question

我已经开展了一个已经进行了数月的项目。我还没有做单元测试，并认为这将是一个体面的时间开始。但是，通常单元测试是在您开始时编写的，并且在开始项目时计划它们。我现在开始合理吗？是否有适当的资源来设置单元测试而无需启动全新的解决方案（该项目已在进行中）。将vb.net与VS2005一起使用

提前致谢：）

Answer 1

任何时候都是开始单元测试的好时机，虽然它越来越难以进入项目，因为你会发现事情变得紧密耦合而不考虑可测试性。

最好的起点是你想要开发的新东西或目前存在很多问题的关键部分。如果您发现有空闲时间，请尝试重构代码并为其添加测试。

您应该在解决方案中使用单独的项目进行单元测试，这样您就不必将其与应用程序一起分发。

Answer 2

为您正在触摸的代码编写测试。当你有时间（是的，正确）时，你可以覆盖该计划的其他部分。

另外，在重构前编写测试;这样，您可以确保旧版本与新版本的功能相同。

Answer 3

将单元测试添加到现有的大型代码库比从头开始更难。无论如何，我会鼓励你这样做，因为从长远来看，它会付出代价。

我已经完成了相同的练习，我的看法是：每当您想要更改现有功能时，至少创建单元测试，以验证更改的代码是否按预期工作。您还应该努力测试直接依赖于您更改的代码的其他代码。这样你就有了一些保险，你的改变不会破坏很多。

当然，无论何时创建新代码，都应该完全由单元测试支持。

通过这种方式，您将逐步建立一个坚实的单元测试基地。

单元测试项目只是您添加到解决方案中的库项目。

Answer 4

你面临的基本问题是Michael Feathers在Working Effectively with Legacy Code中提到的遗留代码困境，a.k.a。重构困境：

• 当我们重构时，我们应该进行测试。
• 为了进行测试，我们经常需要重构。

作为摆脱困境的一种方法，本书描述了一套依赖性破坏技术。这些是相对安全的方法来撬开依赖关系，以便隔离代码并将其置于单元测试之下。本书的例子是Java，C ++，C和C＃。关于vb.net，我不太了解有多少技术适用。

在c2 wiki上还有一些一般的讨论/鼓励here。

Answer 5

我将要做的是：

1. 为我实施的功能编写测试。
2. 为我修复的任何错误编写测试。
3. 在任何重构工作之前编写测试。

这样可以让你获得一些测试覆盖率的公平方式，而无需将整个团队转换为只为一两个冲刺编写测试。

Answer 6

只要你能完全覆盖某一特定区域，那就值得。

如果你不能，那么单元测试开始失去它们的价值，因为它们给人一种错误的印象，即某个特定区域已被正确测试。

如果写得正确，我仍然会说它们是有益的。 但是，您确实需要注意它们最初会降低开发速度，理想情况下需要由团队中其他成员保持更新，这些成员正在处理相同的代码区域。

Answer 7

我会说应该进行单元测试的功能需要很小，这样就不会发生太多的状态变化。实际上，如果您在开发之前编写单元测试，那么您将始终将您的功能设计为模块化。

请查看http://msdn.microsoft.com/en-us/library/ms364064.aspx

欢呼声

Answer 8

在编写单元测试时开始这么做意味着你现在还需要做更多的事情。值得IMO花时间，但不幸的是，有时时间/预算不允许它。