在Brownfield应用程序中实现单元测试的第一个任务是什么？

Question

你会先重构你的SQL吗？你的架构？还是你的代码库？你会改变语言吗？你会扔掉所有东西，从头开始吗？不重构

Answer 1

我正在将单元测试添加到一个大型的、遗留的意大利面条代码库。

我的方法是，当被要求解决一个问题时，我会尝试围绕与我当前任务相关的代码库部分创建一个新的包装器。这个新的包装器是使用TTD (先编写测试)开发的。有时会调用非单元测试的遗留代码。在其他时候，我会复制一个现有模块的新副本，并开始对其进行严重的暴力攻击。有时我会从头开始重写功能。

但由于我对它进行了相当好的测试，所以我感觉自己控制得很好。

我发现这个代码库已经开发了太多的复制和粘贴，一旦我理解了一个特定的部分，并从中提取了一些函数(这是先测试完成的)……这些函数经常被证明在许多其他地方都是可用的，因此用我自己的、经过单元测试的库替换遗留代码的速度会增加。

我不会(也没有权限)尝试重写或添加未被当前问题(通常是我试图修复的bug )触及的代码部分的测试，但我确实对被触及并可能相关的任何事情都采取了相当积极主动的立场。

更新: Penguinix问：“你用什么语言工作?你有推荐的特定测试工具吗？”

现在我的工作是...呃..。流行性出血热！但同样的原则在任何地方都适用。

改变我对UT理解的是MinUnit：http://www.jera.com/techinfo/jtns/jtn002.html

当我看到MinUnit的时候，对我来说是一种“禅宗”的启蒙时刻。它消除了我对单元测试是一件复杂的事情，需要复杂的OO框架等的误解。我理解了UT只是编写了一堆测试。你可以在大约3分钟内用你喜欢的任何语言编写自己的“马具”。上车去做吧。

Answer 2

这真的取决于代码库的状态...有大量的课程吗？一个拥有巨型方法的类？这些类是紧密耦合的吗？配置是一种负担吗？

考虑到这一点，我建议阅读Working Effectively with Legacy Code，找出你的问题，并应用这些建议。