unit-testing - 使用单元测试进行实际重构

Question

刚看完Refactoring: Improving the Design of Existing Code的前四章，我开始了我的第一次重构，几乎立即遇到了障碍。它源于这样一个要求，即在开始重构之前，您应该围绕遗留代码进行单元测试。这使您可以确保重构不会改变原始代码所做的事情(仅更改它的方式)。

所以我的第一个问题是:如何对遗留代码中的方法进行单元测试？如何在 500 行(如果我幸运的话)方法周围进行单元测试，而该方法不只执行一项任务？在我看来，我必须重构我的遗留代码才能使其可单元测试。

有没有人有使用单元测试重构的经验？而且，如果是这样，您是否有任何实际示例可以与我分享？

我的第二个问题有点难以解释。这是一个示例:我想重构一个从数据库记录填充对象的遗留方法。我不是必须编写一个单元测试来比较使用旧方法检索的对象和使用重构方法检索的对象吗？否则，我怎么知道我的重构方法产生与旧方法相同的结果？如果这是真的，那么我在源代码中保留旧的弃用方法多长时间？在我测试了一些不同的记录后，我是否只是重击它？或者，我是否需要将它保留一段时间以防我在重构的代码中遇到错误？

最后，因为有几个人问过......遗留代码最初是用 VB6 编写的，然后以最小的架构更改移植到 VB.NET。

Answer 1

理论与现实相结合的好例子。单元测试旨在测试单个操作，许多模式纯粹主义者坚持 Single Responsibilty ，所以我们有可爱的干净代码和测试。然而，在真实(困惑)的世界中，代码(尤其是遗留代码)会做很多事情并且没有测试。这需要进行大量重构以清理困惑。

我的方法是使用单元测试工具构建测试，在单个测试中测试很多东西。在一项测试中，我可能会检查数据库连接是否打开，更改了大量数据，并对数据库进行了前后检查。我不可避免地发现自己编写了辅助类来进行检查，而且这些辅助类通常可以添加到代码库中，因为它们已经封装了紧急行为/逻辑/需求。我并不是说我有一个巨大的测试，我的意思是mnay测试正在做纯粹主义者称之为集成测试的工作 - 这样的事情还存在吗？我还发现创建一个测试模板然后从中创建许多测试很有用，以检查边界条件、复杂处理等。

顺便说一句，我们在谈论哪种语言环境？有些语言比其他语言更适合重构。