11 refactoring unit-testing legacy-code
刚刚阅读了重构:改进现有代码设计的前四章,我开始了我的第一次重构,几乎立即陷入了障碍.它源于要求在开始重构之前,应该对遗留代码进行单元测试.这使您可以确保您的重构没有改变原始代码所做的事情(只是它是如何做到的).
所以我的第一个问题是:如何在遗留代码中对方法进行单元测试？如何在500行(如果我很幸运)的方法中进行单元测试,而不是只执行一项任务？在我看来,我必须重构我的遗留代码只是为了让它可以进行单元测试.
有没有人有使用单元测试重构的经验？如果是这样,你有什么实际的例子可以和我分享吗？
我的第二个问题有点难以解释.这是一个例子:我想重构一个从数据库记录填充对象的遗留方法.我不是必须编写一个单元测试,将使用旧方法检索的对象与使用重构方法检索的对象进行比较吗？否则,我怎么知道我的重构方法产生与旧方法相同的结果？如果这是真的,那么我在源代码中保留旧的弃用方法多长时间？在测试几个不同的记录后,我是否只是打了它？或者,如果我在重构的代码中遇到错误,是否需要保留一段时间？
最后,由于有几个人问过......遗留代码最初是用VB6编写的,然后移植到VB.NET,只需要进行最少的架构更改.
理论与现实结合的好例子。单元测试旨在测试单个操作，许多模式纯粹主义者坚持单一职责，因此我们有可爱的干净代码和测试。然而，在现实（混乱）的世界中，代码（尤其是遗留代码）做了很多事情并且没有测试。这需要大量的重构来清理混乱。
我的方法是使用单元测试工具构建测试，在单个测试中测试很多东西。在一项测试中，我可能会检查数据库连接是否打开，更改大量数据，并对数据库进行前后检查。我不可避免地发现自己编写帮助程序类来进行检查，并且通常可以将这些帮助程序添加到代码库中，因为它们封装了紧急行为/逻辑/需求。我并不是说我有一个巨大的测试，我的意思是许多测试正在做纯粹主义者称之为集成测试的工作 - 这样的事情还存在吗？我还发现创建一个测试模板，然后从中创建许多测试，以检查边界条件、复杂处理等很有用。
顺便说一句，我们谈论的是哪种语言环境？有些语言比其他语言更适合重构。