1. 项目概述为什么我们需要全局默认超时在软件开发的日常里测试超时是个既基础又容易让人头疼的问题。想象一下你刚提交了一个构建CI/CD流水线开始运行然后你发现某个测试用例卡住了整个构建队列因此停滞了十几分钟甚至更久。这不仅仅是浪费了宝贵的计算资源和时间更重要的是它打断了团队的快速反馈循环让问题排查变得像大海捞针。JUnit 5作为现代Java测试的事实标准提供了强大的超时控制能力但很多团队和个人开发者往往只在单个测试方法上零散地使用Timeout注解。这种“哪里需要点哪里”的方式在小型项目或测试数量不多时或许可行但随着项目规模扩大、测试套件膨胀缺乏统一、全局的超时策略就会暴露出管理混乱、标准不一、资源泄漏风险高等一系列问题。“全局默认超时设置”这个主题正是为了解决这个痛点。它的核心价值在于通过一套集中、统一的配置为整个测试套件设定一个安全基线。这就像为你的测试执行环境安装了一个“熔断器”任何超出预期执行时间的测试都会被自动终止并给出明确的失败报告而不是无限期地挂起消耗资源。这不仅提升了测试套件的稳定性和可预测性更是工程效能和代码质量保障体系中不可或缺的一环。无论你是维护一个庞大的微服务系统还是在开发一个高并发的中间件一个合理的全局超时策略都能帮你及早发现性能退化、死锁、无限循环等潜在缺陷。接下来我将结合多年的一线实践从设计思路到具体实现再到避坑指南为你完整拆解如何在JUnit 5中高效、优雅地配置全局默认超时。2. 全局超时的核心设计思路与方案选型在动手写代码之前我们必须先理清思路JUnit 5中实现全局超时有哪些路径各自适合什么场景为什么我们最终会选择某一种方案这是避免后续反复折腾的关键。2.1 JUnit 5超时控制的三种层级JUnit 5的超时控制大致可以分为三个层级理解它们的区别是设计全局策略的基础方法级超时 (Timeout注解)这是最精细的粒度。你可以直接在单个测试方法或测试类上使用Timeout注解例如Timeout(5)表示该方法必须在5秒内完成。它的优先级最高可以覆盖全局设置。适用于那些执行时间特殊、或需要特别严格控制的测试用例。扩展级超时 (通过TestTemplateInvocationContextProvider或InvocationInterceptor)这是实现全局超时的核心机制之一。通过编写自定义的JUnit 5扩展Extension在测试方法执行的“拦截器”层面注入超时逻辑。这种方式非常灵活可以基于类、标签、包等维度进行差异化配置是构建复杂超时策略的利器。配置参数级超时 (junit-platform.properties)JUnit 5平台本身提供了一些配置参数但原生并不直接支持一个“全局默认超时值”。不过我们可以通过配置参数来影响某些行为例如配置并行执行策略来间接管理资源占用时间但这并非直接的超时控制。2.2 主流全局超时方案对比与选型理由基于以上层级实现全局默认超时主要有两种主流方案方案一基于自定义扩展 (Custom Extension)这是最推荐、也是最灵活的方案。其核心是实现InvocationInterceptor接口。这个接口允许你在测试方法执行前后插入逻辑。我们可以在interceptTestMethod方法中使用CompletableFuture或类似的机制来包装原始测试调用并设置一个未来任务Future在指定时间后取消它。优点灵活性极高不仅可以设置一个简单的全局超时还可以轻松实现基于Tag、类名、包名的差异化超时规则。功能强大可以整合重试、日志、监控上报等逻辑。符合JUnit 5哲学充分利用了JUnit 5的扩展模型是“官方推荐”的扩展方式。缺点实现稍复杂需要编写一些“样板代码”对新手有一定门槛。需要显式注册需要通过ExtendWith注解或Java的ServiceLoader机制注册扩展。方案二封装基类与AOP创建一个所有测试类继承的抽象基类在基类的BeforeEach或AfterEach方法中通过线程或ExecutorService来管理超时。或者使用AOP框架如AspectJ在测试方法周围织入超时切面。优点简单直观对于已经使用基类模式的项目改造成本低。缺点侵入性强强制要求测试类继承特定基类破坏了测试类的灵活性。可靠性存疑自己管理线程中断和资源清理容易出错尤其是在处理ThreadLocal、数据库连接等资源时。与JUnit 5集成度低可能无法完美处理JUnit 5的生命周期和报告机制。方案三使用第三方库有些第三方测试工具库可能提供了现成的超时扩展。优点开箱即用。缺点引入了额外的依赖其实现可能黑盒遇到问题时调试困难且可能与项目其他库或未来JUnit版本存在兼容性风险。实操心得为什么我强烈推荐方案一自定义扩展在我经历过的多个中大型项目中方案一被证明是最稳健、最可持续的选择。初期多写的几十行“样板代码”在后期维护和功能扩展时会带来巨大的收益。例如我们曾有一个需求对“集成测试”标签设置30秒超时对“单元测试”标签设置2秒超时对某些访问外部缓存的测试设置10秒超时。使用自定义扩展我们只需在一个配置类里定义这些规则即可所有测试类无需任何修改。这种声明式的配置方式极大地降低了管理成本。而基类方案在面对这种复杂规则时会迅速变得难以维护。3. 核心细节解析实现一个生产级全局超时扩展理解了为什么选自定义扩展后我们来深入其实现细节。一个健壮的全局超时扩展绝不仅仅是调用Future.get(timeout)那么简单它需要妥善处理中断、资源清理、错误报告等多个方面。3.1InvocationInterceptor的工作原理与拦截点InvocationInterceptor是JUnit 5提供的强大接口用于拦截测试方法的调用。它有多个方法我们需要重点关注的是interceptTestMethod。当JUnit平台执行一个测试方法时会调用这个方法并传入一个Invocation对象和ReflectiveInvocationContext上下文。Invocation对象封装了实际执行测试方法的逻辑其proceed()方法就是触发执行的开关。我们的任务就是在调用invocation.proceed()时将其包装在一个带有超时控制的执行环境中。JUnit 5的Invocation在设计上已经考虑了可中断性这为我们提供了便利。3.2 超时执行的线程模型与资源安全这是实现中最容易踩坑的部分。通常的做法是使用ExecutorService提交一个任务来执行invocation.proceed()然后通过Future.get(long timeout, TimeUnit unit)来等待结果。ExecutorService executor Executors.newSingleThreadExecutor(); Future? future executor.submit(() - invocation.proceed()); try { future.get(timeoutDuration.toMillis(), TimeUnit.MILLISECONDS); } catch (TimeoutException e) { future.cancel(true); // 尝试中断执行线程 throw new AssertionError(Test execution timed out after timeoutDuration, e); } catch (ExecutionException e) { throw e.getCause(); // 重新抛出测试中的原始异常 } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 throw new RuntimeException(Test interceptor was interrupted, e); } finally { executor.shutdownNow(); // 强制关闭执行器回收资源 }关键点解析future.cancel(true)中的true参数这个参数意味着“如果任务正在运行则中断它”。这对于响应中断的代码如sleep、wait、某些IO操作是有效的。但并非所有代码都能正确响应中断如果测试方法内部是一个死循环或者调用了不响应中断的阻塞方法那么即使调用了cancel(true)线程也可能无法停止造成资源泄漏。ExecutorService的生命周期管理必须在finally块中调用shutdownNow()。shutdownNow()会尝试中断所有正在执行的任务并丢弃等待中的任务。对于每个测试方法都新建一个ExecutorService的场景务必确保关闭否则会导致线程数缓慢增长线程泄漏。异常处理ExecutionException包装了测试方法中抛出的实际异常我们需要将其解包并重新抛出这样JUnit才能正确地将测试标记为失败并显示相应的错误信息。如果直接抛出ExecutionException错误报告会不清晰。注意事项线程池的选用使用newSingleThreadExecutor()为每个测试方法创建一个独立的线程和执行器是最安全的选择因为它确保了测试之间的隔离性。虽然创建线程有一定开销但对于测试执行来说通常是可接受的。切勿为了“优化”而使用一个全局共享的线程池这会导致测试之间不可预测的相互干扰违反了测试独立性的基本原则。3.3 超时时间的读取与优先级策略一个灵活的全局扩展应该允许从多种来源读取超时配置并定义清晰的优先级。一个常见的策略是最高优先级方法上的Timeout注解。如果测试方法或类上明确标注了Timeout则使用该值。次优先级类或方法上的自定义注解如CategoryTimeout。你可以定义自己的注解为某一类测试如“慢速集成测试”指定超时。默认优先级全局配置。从系统属性、环境变量或配置文件如application-test.yml中读取一个默认超时值。在扩展中我们可以通过ReflectiveInvocationContext参数获取测试方法及其所在类的注解信息从而决定最终使用的超时时间。private Duration resolveTimeout(ReflectiveInvocationContextMethod context) { // 1. 检查方法上的 Timeout Method testMethod context.getExecutable(); Timeout methodTimeout testMethod.getAnnotation(Timeout.class); if (methodTimeout ! null) { return Duration.of(methodTimeout.value(), methodTimeout.unit().toChronoUnit()); } // 2. 检查类上的 Timeout Class? testClass context.getTargetClass(); Timeout classTimeout testClass.getAnnotation(Timeout.class); if (classTimeout ! null) { return Duration.of(classTimeout.value(), classTimeout.unit().toChronoUnit()); } // 3. 检查自定义注解示例 CategoryTimeout customTimeout testMethod.getAnnotation(CategoryTimeout.class); if (customTimeout null) { customTimeout testClass.getAnnotation(CategoryTimeout.class); } if (customTimeout ! null) { return Duration.ofSeconds(customTimeout.seconds()); } // 4. 返回全局默认值 return this.globalDefaultTimeout; }4. 实操过程从零构建并集成全局超时扩展理论说得再多不如一行代码。让我们一步步实现并集成这个扩展。4.1 第一步创建全局超时扩展类我们创建一个名为GlobalTimeoutExtension的类实现InvocationInterceptor接口。import org.junit.jupiter.api.extension.*; import java.lang.reflect.Method; import java.time.Duration; import java.util.concurrent.*; import java.util.concurrent.atomic.AtomicReference; public class GlobalTimeoutExtension implements InvocationInterceptor { private final Duration globalTimeout; private final ExecutorService executor; // 通常不在这里初始化见下文说明 public GlobalTimeoutExtension() { // 从配置源读取全局超时这里简化为例硬编码为10秒。 // 实际应从配置文件读取例如 // String timeoutStr System.getProperty(junit.global.timeout, 10s); this.globalTimeout Duration.ofSeconds(10); // 注意ExecutorService 不应在扩展实例中创建原因见4.2节 } Override public void interceptTestMethod(InvocationVoid invocation, ReflectiveInvocationContextMethod context, ExtensionContext extensionContext) throws Throwable { Duration timeout resolveTimeout(context); // 调用前面定义的解析方法 // 使用一个单线程执行器来运行测试 ExecutorService executor Executors.newSingleThreadExecutor(); // 用于捕获测试执行过程中抛出的异常 AtomicReferenceThrowable throwableRef new AtomicReference(); Future? future executor.submit(() - { try { invocation.proceed(); } catch (Throwable t) { throwableRef.set(t); } }); try { future.get(timeout.toMillis(), TimeUnit.MILLISECONDS); // 如果future成功返回检查是否有异常被捕获 Throwable thrown throwableRef.get(); if (thrown ! null) { throw thrown; // 重新抛出测试本身的异常 } } catch (TimeoutException e) { future.cancel(true); // 尝试中断 // 创建一个清晰的超时失败异常 throw new AssertionFailedError(buildTimeoutMessage(context, timeout), e); } catch (ExecutionException e) { // 正常情况下由于我们在Runnable内捕获了异常不会进入这个分支。 // 但为了代码健壮性保留此处理。 throw e.getCause(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); future.cancel(true); throw new RuntimeException(Test execution interrupted, e); } finally { executor.shutdownNow(); } } private String buildTimeoutMessage(ReflectiveInvocationContextMethod context, Duration timeout) { return String.format(Test [%s.%s] timed out after %d seconds, context.getTargetClass().getSimpleName(), context.getExecutable().getName(), timeout.getSeconds()); } // ... resolveTimeout 方法同上 ... }4.2 第二步优化扩展——处理线程局部变量与资源隔离上面的代码有一个潜在问题测试方法可能在主线程JUnit线程中初始化了一些资源例如通过BeforeEach初始化的ThreadLocal变量然后在我们的ExecutorService线程中执行。如果测试代码依赖ThreadLocal这会导致NullPointerException。解决方案使用Invocation.proceed()的默认行为。实际上Invocation.proceed()方法本身就会在调用它的线程上执行测试逻辑。我们不需要自己创建新线程来执行它。更优雅的方式是我们创建一个监督线程让主线程执行测试监督线程负责计时和超时中断。Override public void interceptTestMethod(InvocationVoid invocation, ReflectiveInvocationContextMethod context, ExtensionContext extensionContext) throws Throwable { Duration timeout resolveTimeout(context); final Thread testThread Thread.currentThread(); ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); // 安排一个任务在超时后中断测试线程 ScheduledFuture? timeoutFuture scheduler.schedule(() - { testThread.interrupt(); // 中断主测试线程 }, timeout.toMillis(), TimeUnit.MILLISECONDS); try { invocation.proceed(); // 在主线程当前线程执行测试 } finally { timeoutFuture.cancel(true); // 如果测试正常完成取消超时任务 scheduler.shutdownNow(); // 重要清除中断状态避免影响后续测试或框架本身 Thread.interrupted(); // 清除中断标志 } // 注意如果是因为超时中断而退出invocation.proceed()可能会抛出InterruptedException等异常。 // 我们需要在catch块中将其转换为超时断言错误。 }但这种简单的线程中断方案同样面临测试代码不响应中断的问题。一个更生产级的做法是结合两种方案用单独的线程执行测试但通过Future和精心设计的ThreadFactory来更好地控制线程上下文。对于大多数Spring Boot或类似框架的项目其测试上下文通常不严重依赖执行线程第一种方案单独线程问题不大。如果遇到ThreadLocal问题可以考虑使用ContextPropagatingExecutorService这类工具来传递上下文。4.3 第三步注册并使用扩展有几种方式注册扩展方式一在测试类上使用ExtendWith适用于特定类ExtendWith(GlobalTimeoutExtension.class) class MyServiceTest { // ... 测试方法 ... }方式二通过Java的ServiceLoader机制自动注册实现真正的全局在src/test/resources目录下创建文件META-INF/services/org.junit.jupiter.api.extension.Extension。在该文件中写入你的扩展类的全限定名例如com.yourcompany.junit.GlobalTimeoutExtension。这样无需在任何测试类上添加注解该扩展会对所有测试生效。这是实现“全局默认”最彻底的方式。方式三通过JUnit平台配置参数有限支持JUnit 5.4 引入了对扩展自动注册的配置支持。你可以在junit-platform.properties文件中设置# 启用自动检测扩展需要扩展在classpath中且有无参构造 junit.jupiter.extensions.autodetection.enabledtrue但这依赖于扩展被正确打包和加载。实操心得ServiceLoader vs 配置文件对于“全局默认”这个目标方式二ServiceLoader是最佳实践。它完全非侵入测试作者无需知晓超时扩展的存在。而ExtendWith更适合需要针对某个模块或某些特殊测试类应用不同超时策略的场景。在实际项目中我通常会建立一个test-utils模块将GlobalTimeoutExtension和META-INF/services配置打包其中其他所有测试模块依赖此模块即可无感接入全局超时。4.4 第四步与构建工具和IDE集成配置好后你需要在IDE和构建工具中确保测试运行器能识别这个扩展。Maven Surefire / Failsafe插件无需特殊配置只要扩展在classpath中ServiceLoader机制就会生效。Gradle同样只要依赖了包含扩展的jar包即可。IntelliJ IDEA默认会使用JUnit Platform运行测试通常能自动识别ServiceLoader注册的扩展。如果不行检查运行配置确保使用的是“JUnit 5”而不是“JUnit 4”或“Gradle”。Eclipse可能需要安装JUnit 5插件并确保启动配置正确。一个常见的验证方法是写一个包含Thread.sleep(15000)的测试方法将全局超时设为5秒运行该测试观察它是否在5秒左右失败并报告超时而不是睡眠15秒。5. 高级配置与差异化超时策略全局默认超时只是一个开始。真实的项目测试套件是分层的不同层次的测试对执行时间的期望截然不同。5.1 基于测试分类Tag的差异化超时我们可以扩展我们的GlobalTimeoutExtension使其支持根据JUnit 5的Tag注解应用不同的超时。首先定义一个配置映射可以从YAML或Properties文件加载public class TimeoutConfig { private MapString, Duration tagTimeouts new HashMap(); private Duration defaultTimeout Duration.ofSeconds(10); // 例如 tagTimeouts.put(slow-integration, Duration.ofMinutes(2)); // tagTimeouts.put(fast-unit, Duration.ofSeconds(2)); // getters and setters ... }然后在resolveTimeout方法中加入Tag的判断逻辑private Duration resolveTimeout(ReflectiveInvocationContextMethod context, ExtensionContext extensionContext) { // ... 先检查 Timeout 和自定义注解 ... // 检查Tag SetString tags extensionContext.getTags(); for (Map.EntryString, Duration entry : timeoutConfig.getTagTimeouts().entrySet()) { if (tags.contains(entry.getKey())) { return entry.getValue(); // 返回该Tag对应的超时 } } // 返回全局默认值 return timeoutConfig.getDefaultTimeout(); }这样你就可以在配置中声明junit: timeout: default: 10s tags: slow-integration: 120s fast-unit: 2s external-service-call: 30s测试类上只需要打上对应的Tag即可Tag(slow-integration) class DatabaseIntegrationTest { Test void testMassiveDataMigration() { // 这个测试将享有2分钟的超时 } }5.2 动态超时与上下文感知更高级的场景下超时可能依赖于测试的上下文信息。例如在CI环境中由于资源共享你可能希望设置更长的超时在本地开发环境中则可以设置得更短。这可以通过在扩展中访问ExtensionContext来实现。ExtensionContext提供了存储Store机制允许你在扩展之间传递数据。你也可以通过它获取当前测试的显示名称、唯一ID等。Override public void interceptTestMethod(...) throws Throwable { ExtensionContext.Store store extensionContext.getStore(ExtensionContext.Namespace.GLOBAL); String environment System.getenv(CI) ! null ? CI : LOCAL; Duration dynamicTimeout CI.equals(environment) ? globalTimeout.plusSeconds(30) : globalTimeout; // 使用 dynamicTimeout 进行后续逻辑 }5.3 超时行为的精细化控制仅告警 vs 强制失败有时你希望超时发生时不是直接让测试失败而是记录一个警告或者尝试重试或者将其标记为“不稳定测试”。这需要更复杂的扩展设计。你可以定义自己的注解例如TimeoutPolicypublic interface TimeoutPolicy { Action onTimeout() default Action.FAIL; int retryCount() default 0; enum Action { FAIL, WARN, RETRY_THEN_FAIL } }在扩展中读取这个注解并根据Action执行不同的逻辑。对于WARN你可以使用extensionContext.publishReportEntry(TIMEOUT_WARNING, ...)来发布一个报告条目而不抛出异常。对于RETRY你可以在捕获TimeoutException后在一个循环中重新执行invocation.proceed()。6. 常见问题排查与实战避坑指南即使配置正确在实际运行中也可能遇到各种问题。以下是我在实践中总结的典型问题及其解决方案。6.1 问题一超时扩展不生效症状设置了全局超时但测试仍然无限期挂起或者没有超时错误。排查步骤检查扩展注册确认META-INF/services文件路径和内容完全正确没有拼写错误。可以临时在扩展类的构造函数中添加一行System.out.println来验证扩展是否被加载。检查依赖冲突确保项目中JUnit Jupiterjunit-jupiter-api, junit-jupiter-engine的版本一致且没有老版本的JUnit 4的Test注解被误用。检查测试运行器在IDE中右键点击测试类运行时确认运行配置使用的是“JUnit 5”。在Maven中检查surefire-plugin的版本建议3.0.0和配置。检查超时值确认你解析到的超时Duration不是null或零值。添加日志输出最终的timeout值。6.2 问题二测试被中断但资源未正确清理症状测试因超时失败后数据库连接未关闭文件句柄未释放导致后续测试或整个套件不稳定。原因与解决future.cancel(true)或thread.interrupt()只是发送一个中断信号。如果测试代码在finally块或AfterEach/AfterAll方法中进行资源清理而清理代码也被阻塞或不响应中断那么资源泄漏就会发生。解决方案编写可中断的清理代码确保资源清理逻辑如关闭连接、回滚事务能够响应InterruptedException或检查Thread.currentThread().isInterrupted()状态并快速退出。使用超时安全的工具对于数据库操作使用带有查询超时设置的DataSource或JdbcTemplate。对于网络调用使用带有超时参数的HTTP客户端。在扩展中强制清理最后手段这不是推荐做法但作为兜底可以在扩展的afterTestExecution回调中尝试强制清理已知的全局资源如静态连接池。这通常与具体的应用框架紧密耦合。6.3 问题三误报——正常测试被超时机制误杀症状一些原本能在规定时间内完成的测试在启用全局超时后随机性失败。排查检查系统负载CI机器或本地机器是否在测试运行时负载过高CPU、内存、IO这会导致测试执行变慢。考虑为集成测试设置更宽松的超时。检查测试隔离性测试之间是否共享了状态例如一个测试修改了静态变量导致另一个测试变慢。确保测试是独立的。分析慢测试使用JUnit 5的Execution(SAME_THREAD)或测试执行监听器找出具体是哪些测试方法执行慢。可能它们本身就存在性能问题需要优化而不是简单地增加超时。区分“慢”和“不稳定”有些测试因为依赖外部服务如第三方API而偶尔变慢。对于这类测试应该使用Tag将其标记出来并赋予更长的、独立的超时或者考虑使用Mock代替真实调用。6.4 问题四与并行测试执行的冲突症状当启用junit.jupiter.execution.parallel.enabled true时超时行为变得不稳定或不可预测。原因并行执行时线程池和资源竞争加剧。你的超时扩展和JUnit的并行执行器可能都在管理线程容易产生冲突。建议谨慎并行对于有复杂全局扩展尤其是涉及线程操作的扩展的测试套件建议先关闭并行执行确保超时功能稳定后再尝试开启。线程安全确保你的扩展实现是线程安全的。避免使用可变的实例变量。resolveTimeout等方法应是无副作用的纯函数。使用Execution对于需要严格时序或资源隔离的测试类使用Execution(ExecutionMode.SAME_THREAD)强制它们在同一线程顺序执行。6.5 问题排查速查表问题现象可能原因排查与解决方向超时完全不生效1. 扩展未正确注册2. 测试使用JUnit 4运行器3. 超时值解析为0或极大值1. 检查META-INF/services文件。2. 确保使用org.junit.jupiter.api.Test。3. 在扩展中打印解析后的超时值。超时后线程不停止1. 测试代码包含不响应中断的阻塞调用如某些NIO锁、synchronized。2. 测试陷入无限循环且未检查中断状态。1. 审查测试代码替换为可中断的API。2. 在循环体中添加if (Thread.currentThread().isInterrupted()) break;。3. 考虑将此类测试标记为特殊类别使用不同的超时策略。超时导致后续测试失败1. 测试资源如静态变量、数据库连接未清理。2. 中断污染了共享状态。1. 强化AfterEach/AfterAll中的清理逻辑确保其健壮性。2. 为每个测试使用独立的、隔离的测试上下文如Spring的DirtiesContext。在IDE中生效在Maven中不生效1. Maven Surefire插件配置了不同的类路径或扩展加载机制。2. 多模块项目中扩展未正确传递依赖。1. 检查surefire-plugin的dependencies配置。2. 确保包含扩展的模块被声明为test依赖。超时时间波动大1. 测试依赖的外部服务数据库、HTTP响应时间不稳定。2. 机器资源争抢。1. 对外部依赖进行Mock或使用测试替身Test Double。2. 为集成测试设置更宽容的超时并监控其稳定性。配置JUnit 5的全局默认超时远不止是加一个参数那么简单。它是一项需要综合考虑测试架构、资源管理和工程实践的细致工作。从选择一个灵活可扩展的实现方案自定义扩展到处理棘手的线程与资源隔离问题再到设计差异化的超时策略以适应不同测试类型每一步都需要结合项目的实际情况进行权衡和调整。核心在于超时机制的目标是成为一个“安全网”和“预警系统”而不是束缚测试的枷锁。通过合理的配置它能够显著提升测试套件的可靠性和执行效率让团队更早、更自信地发现代码中的性能瓶颈和潜在缺陷。我个人的习惯是在新项目初期就引入一个基础的全局超时扩展并随着测试套件的增长逐步完善其标签化和策略化的配置这为项目的长期健康发展奠定了良好的自动化测试基础。
