将单元测试添加到不是为它设计的代码中

Question

在工作中，我们有一个三层产品。用户使用一个客户端应用程序，它从服务器查询数据，该服务器将这些请求转发到SQL数据库。我们不允许客户端直接访问SQL服务器。

客户端产品是我想要进行单元测试的，但它有超过120万行C＃代码，是一款非常古老的产品。它的设计并未考虑单元测试，并且该产品的主要开发人员通常反对单元测试，主要是因为风险与奖励问题，以及如何重新设计以减少需要完成的模拟量。重新设计这些核心的低级客户端库和对象也让他们感到担忧。

我的理念是绝对不会忽视单元测试（因为我们总是总是太忙而且总是看起来很危险，因此永远不会永远完成）并采取迭代的方法来实现单元测试。

我有兴趣听取这种情况的解决方案。我相信很多人都遇到过必须在现有基础设施中添加单元测试的情况。如何在不妨碍生产力和发布周期的情况下迭代地将单元测试添加到代码库中？

Answer 1

在这样的情况下（我们实际上已经经历了与旧的webforms到MVC转换的相同过程）只是开始测试新代码。随着时间的推移，最终旧代码将被重写或重构。

在“新”代码被视为有效之前，必须对其进行单元测试并进行代码审查。随着时间的推移，最终您会发现越来越多的解决方案正在测试中，并且调用的代码越来越少。

Answer 2

我在研究这个主题时发现Michael Feathers'Working Effectively with Legacy Code很有用。

Answer 3

我的经历：

1. 实施系统（端到端）测试的方式
2. 添加新功能时，编写系统测试并使用单元测试设计新功能
3. 当您更改现有功能时，请事先编写系统测试
4. 请勿尝试使用单元测试重写现有模块以进行测试

通过这种方式，您可以获得新功能的单元测试，并为旧功能创建（尽管广泛的）安全网。随着时间的推移，越来越多的系统部件进行系统测试，并且（以百分比表示）您可以获得更多的单元测试覆盖率。重新设计旧代码只是为了获得单元测试覆盖率是昂贵的。

Answer 4

我和你的首席开发人员在一起。这是120万行代码，这意味着这意味着在测试和重新设计时存在大量的错误空间。它不是为UT设计的，因此可能需要花费很多精力来重写代码以便对其进行测试。我相信单元测试会非常耗时。此外，它是一个旧产品，可能意味着已经找到并修复了许多错误。 如果它没有破坏，就不要修复它。你是不是更愿意继续研究项目中更有趣的方面，而不是测试和重构旧代码？

那就是说，如果我绝对认为它需要发生，我可能只是为我触摸的部分编写测试，因为我触摸它们。如果我不接触它们，我就不会测试它们。