使用单元测试进行实际重构 [英] Practical refactoring using unit tests

问题描述

刚刚阅读了重构:改进现有代码的设计，我开始了我的第一次重构，几乎立即遇到了障碍.它源于这样一个要求，即在开始重构之前，您应该围绕遗留代码进行单元测试.这让您可以确保重构不会改变原始代码所做的事情(只是如何做到了).

Having just read the first four chapters of Refactoring: Improving the Design of Existing Code, I embarked on my first refactoring and almost immediately came to a roadblock. It stems from the requirement that before you begin refactoring, you should put unit tests around the legacy code. That allows you to be sure your refactoring didn't change what the original code did (only how it did it).

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

So my first question is this: how do I unit-test a method in legacy code? How can I put a unit test around a 500 line (if I'm lucky) method that doesn't do just one task? It seems to me that I would have to refactor my legacy code just to make it unit-testable.

有人有使用单元测试重构的经验吗?而且，如果是这样，您有什么实际例子可以与我分享吗?

Does anyone have any experience refactoring using unit tests? And, if so, do you have any practical examples you can share with me?

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

My second question is somewhat hard to explain. Here's an example: I want to refactor a legacy method that populates an object from a database record. Wouldn't I have to write a unit test that compares an object retrieved using the old method, with an object retrieved using my refactored method? Otherwise, how would I know that my refactored method produces the same results as the old method? If that is true, then how long do I leave the old deprecated method in the source code? Do I just whack it after I test a few different records? Or, do I need to keep it around for a while in case I encounter a bug in my refactored code?

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

Lastly, since a couple people have asked...the legacy code was originally written in VB6 and then ported to VB.NET with minimal architecture changes.

推荐答案

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

Good example of theory meeting reality. Unit tests are meant to test a single operation and many pattern purists insist on Single Responsibilty, so we have lovely clean code and tests to go with it. However, in the real (messy) world, code (especially legacy code) does lots of things and has no tests. What this needs is dose of refactoring to clean the mess.

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

My approach is to build tests, using the Unit Test tools, that test lots of things in a single test. In one test, I may be checking the DB connection is open, changing lots of data, and doing a before/after check on the DB. I inevitably find myself writing helper classes to do the checking, and more often than not those helpers can then be added into the code base, as they have encapsulated emergent behaviour/logic/requirements. I don't mean I have a single huge test, what I do mean is mnay tests are doing work which a purist would call an integration test - does such a thing still exist? Also I've found it useful to create a test template and then create many tests from that, to check boundary conditions, complex processing etc.

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

BTW which language environment are we talking about? Some languages lend themselves to refactoring better than others.

这篇关于使用单元测试进行实际重构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！