自动化测试的重要性已被广泛讨论：它们为修改系统组件提供了强有力的保障，能够在开发生命周期的早期阶段及时发现问题，从而防止缺陷流入生产环境。然而，当我们面对测试覆盖率极低（甚至完全没有测试覆盖）的老旧系统时，编写自动化测试会非常困难且令人沮丧。初期搭建自动化测试所需的努力往往超出团队当时的承受能力，导致测试工作被无限期推迟。
这形成了一个滚雪球效应：随着系统复杂度不断增加，改动变得风险更大且更难执行，自动化测试需要覆盖的范围也越拉越大。尽管维护软件的时间变多了，但我们更不愿意花时间去提升代码的可测试性。本文将介绍一些老旧系统自动化测试的最佳实践。
自动化测试的类型
在开始之前，重要的是了解不同类型的自动化测试，以及判断哪种测试更适合我们要解决的问题。自动化测试主要分为单元测试、集成测试、端到端测试和性能测试等，每种测试类型针对不同的系统层级和需求。单元测试关注最小功能单元，适合验证核心业务逻辑的正确性；集成测试则用于确保各模块之间的协作无误，适合检查系统组件的交互；端到端测试模拟用户实际操作，验证整个系统流程是否符合预期；性能测试则关注系统在高负载下的表现。
选择合适的测试类型不仅能提升测试效率，还能更有针对性地发现和解决问题。对于老旧系统，通常优先考虑单元测试和集成测试，因为它们更易于逐步引入，且能在不大幅度修改现有结构的前提下提升代码质量和可维护性。
端到端测试
端到端（E2E）测试通过自动化方式模拟最终用户与系统的完整交互流程。例如，测试用户可以回复评论时，会覆盖用户点击按钮、输入文字、滚动页面等所有步骤，确保整个软件栈协同工作。
其主要优点是能够验证系统整体功能是否正常，确保各个环节无缝衔接。但由于依赖众多组件，E2E 测试运行速度较慢，容易出现不稳定现象，维护成本较高。对于遗留系统，E2E 测试的搭建与新系统类似，测试工具通常独立于系统内部代码运行，仅需适配 UI 标识符等细节。因此，本文后续不再重点讨论端到端测试。
单元测试
单元测试关注于软件中最小的功能单元，如函数或方法。通过为关键逻辑编写测试，可以验证输入输出的正确性，及时发现缺陷。例如，针对购物车总价计算函数进行单元测试，有助于确保业务逻辑准确无误。
单元测试的优势在于易于搭建，能够促进代码变更并及早发现问题。然而，过多或过于细致的单元测试可能导致维护成本上升，持续集成等待时间变长。此外，过分依赖单元测试可能忽略系统层面的整体问题。对于老旧系统，由于紧耦合和缺乏模块化，单元测试的引入往往较为困难，老旧技术栈也可能带来工具兼容性挑战。
集成测试
集成测试用于验证多个组件之间的协作是否正常。例如，测试数据库与服务器的交互，或 API 调用的正确性。通过集成测试，可以发现接口和集成单元之间的潜在问题，提升系统整体稳定性。
集成测试的优点在于能够捕捉到单元测试无法覆盖的交互问题，但由于依赖较多，测试执行速度较慢，稳定性不如单元测试。对于遗留代码，集成测试的实现尤为复杂，常常需要模拟大量依赖，且相关文档不完善，导致测试行为与实际生产环境存在差距，收益有限。
性能测试
性能测试关注系统在不同负载下的响应速度、稳定性和资源消耗，确保软件能够满足预期的性能要求。通过模拟高并发或大流量场景，可以提前发现系统瓶颈，降低上线风险。
性能测试的缺点是资源消耗大、执行耗时，且难以精准复现生产环境，测试结果易受外部因素影响。对于遗留系统，性能测试尤为重要，尤其在与新技术集成或流量激增时。但由于策略依赖系统架构，具体方法需专门讨论，本文不做深入展开。
我们应测试什么
确定采用单元测试或集成测试策略后，下一步是识别代码类型并针对不同代码制定测试策略。代码分类方式多种多样，以下是一种建议：
- 琐碎代码：如 getter/setter 等低复杂度模板代码，对应用功能或性能影响甚微。通常仅因语言或框架要求存在，除非极特殊场景，否则无须测试。
- 核心代码：代码库中最重要部分，包含业务逻辑、数据转换、应用规则和决策。核心代码通常位于后端，但 UI 组件层也可能包含大量逻辑，应视为系统核心代码。大多数情况下，应重点对核心代码编写自动化测试，尤其是单元和集成测试。
- 协调者：连接或桥接其他组件的部分。例如 Web 开发中控制器接收用户输入，调用核心逻辑处理数据并返回响应。作为协调者的组件单独做单元测试价值不大，但通常会作为集成测试的一部分被测试。
- 意大利面条代码：多种类型代码混杂一处的代码，常见于庞大类中，代码行数达千上万。即使没那么严重，也难以编写测试，因为最小组件缺乏明确职责。问题在于这些代码往往包含想要测试的核心代码，但难以入手。解决方案是重构，这将在下一部分详细讲解。
重构
代码重构是指在不改变代码外部行为的前提下，重组现有代码。主要目的是清理简化代码设计，提高可读性和可维护性。为了提升可测试性，最好先将大型函数拆分为更小、更聚焦的函数，使代码更模块化、易懂且易维护。
针对刚才介绍的代码类型，我们的主要目标是将意大利面条代码拆分成更小更易管理的片段，更像琐碎代码、核心代码或协调者代码，然后开始针对更有意义的部分编写测试。
代码示例
考虑以下代码：
public class UserDataProcessor {
public void processUserData(String name, int age, String address) {
if (name == null || name.isEmpty()) {
throw new IllegalArgumentException("Name cannot be empty");
}
if (age < 0 || age > 120) {
throw new IllegalArgumentException("Invalid age");
}
if (address == null || address.isEmpty()) {
throw new IllegalArgumentException("Address cannot be empty");
}
// 执行主要处理逻辑
// ...
Logger.log("Processed data - Name: " + name + ", Age: " + age + ", Address: " + address);
}
}
上述 processUserData 方法将验证、处理和日志记录混合在一起，导致代码难以维护和测试。我们可以通过拆分成更小的函数来优化代码结构，提高可读性和可维护性：
public class UserDataProcessor {
public void processUserData(String name, int age, String address) {
validateUserData(name, age, address); // 验证用户数据
processMainLogic(name, age, address); // 处理主要业务逻辑
logProcessedData(name, age, address); // 记录日志
}
private void validateUserData(String name, int age, String address) {
if (name == null || name.isEmpty()) {
throw new IllegalArgumentException("Name cannot be empty");
}
if (age < 0 || age > 120) {
throw new IllegalArgumentException("Invalid age");
}
if (address == null || address.isEmpty()) {
throw new IllegalArgumentException("Address cannot be empty");
}
}
private void processMainLogic(String name, int age, String address) {
// 执行主要处理逻辑
// ...
}
private void logProcessedData(String name, int age, String address) {
Logger.log("FunTester - Processed data - Name: " + name + ", Age: " + age + ", Address: " + address);
}
}
此时，processUserData 成为协调者函数，分别调用不同函数完成三项主要任务。这样一来，每个子函数都拥有清晰的职责，依赖关系被有效拆分，针对每个任务的测试也变得更加简单。例如，你可以单独为 validateUserData 编写测试用例，验证输入校验逻辑是否健壮；为 processMainLogic 测试核心业务流程是否正确；为 logProcessedData 检查日志记录是否符合预期。每个部分都可以独立测试和维护，极大提升了代码的可测试性和可维护性。
此外，这种拆分还带来额外好处：如果未来业务需求发生变化，只需调整相关子函数，无需大幅修改整个流程。比如，日志格式变更时，只需修改 logProcessedData，而不会影响数据处理和校验逻辑。团队成员也能更快理解和定位问题，协作效率提升。
更重要的是：不必一次性完成全部拆分。可以先拆出最关键或最易变部分，逐步优化代码结构。源码的生命周期与软件相同，改进可以是持续进行的。每次重构和测试覆盖的提升，都会让老旧系统变得更安全、更易维护。即使面对庞大复杂的系统，也能通过渐进式重构和测试，逐步降低技术债务，最终实现高质量、可测试的代码库。
重构原则
讨论重构前，还有一个重要话题：什么是好的重构？在软件工程中，面对同一问题常有不同解决方案，重构也不例外。重构没有唯一方式，受个人喜好和系统限制影响。但有一些编程原则能帮助我们判断重构方向。
在软件工程圈子里，SOLID 原则几乎是代码健身房的标配，想让你的代码更结实、更灵活，这五条原则绝对不能忽视。下面我们来聊聊它们的技术细节和实际应用场景，顺便用点生活化的例子，帮大家把抽象理论落地到日常开发。
-
单一职责原则（Single Responsibility Principle）
就像你不会让洗衣机去做饭，每个类或模块都应该只负责一件事。比如，用户信息处理类只管校验和存储，不要顺便去发邮件。这样一来，代码更容易维护，出问题也能快速定位。 -
开闭原则（Open-Closed Principle）
软件实体要对扩展开放，对修改关闭。什么意思？假如你家电饭煲支持加装煮粥功能，你只需要插个新模块，而不是拆掉整个锅重做一遍。实际开发中，常用接口和抽象类来实现这一点，比如新增支付方式时，只需扩展新类，无需动原有代码。 -
里氏替换原则（Liskov Substitution Principle）
子类能无缝替换父类，且不会引发异常。就像你换了个新电池，遥控器还是能正常工作。举个例子，假如有个动物类，子类狗和猫都能用同样的方法叫，不会突然冒出飞翔这种父类没有的行为。 -
接口隔离原则（Interface Segregation Principle）
接口要小而专注，别让用户实现一堆用不上的方法。比如，打印机接口只需要打印，不必强制实现扫描或传真。这样，开发者用起来更轻松，系统也更灵活。 -
依赖倒置原则（Dependency Inversion Principle）
高层模块不依赖低层模块，两者都依赖抽象。就像你用插座，不关心里面是铜线还是银线，只要标准接口能用就行。实际开发中，常用依赖注入（DI）框架，把具体实现和业务逻辑解耦，方便测试和扩展。
这些原则不仅是理论，更是提升代码可测试性和可维护性的秘籍。在重构老旧系统，遵循 SOLID 原则能让你的测试覆盖更全面，代码结构更清晰，维护起来也不再头疼。