Loading...

JUnit4/JUnit5 注解

Created2019-12-30|Updated2026-06-25|Java

|Word Count:99|Reading Time:1mins|Post Views:

junit4	junit5	特点
@BeforeClass	@BeforeAll	在当前类的所有测试方法之前执行。注解在【静态方法】上。
@AfterClass	@AfterAll	在当前类中的所有测试方法之后执行。注解在【静态方法】上。
@Before	@BeforeEach	在每个测试方法之前执行。注解在【非静态方法】上。
@After	@AfterEach	在每个测试方法之后执行。注解在【非静态方法】上。

Author: magicliang

Link: https://magicliang.github.io/2019/12/30/JUnit4-JUnit5-%E6%B3%A8%E8%A7%A3/

Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.

Java JUnit 测试

Related Articles

如何做性能测试的问题下的答案

试着回答一下这个问题。首先要划分系统类型：有状态还是无状态，业务系统还是存储系统。根据不同的业务场景，设立性能测试的目标：是要测 QPS，还是 TPS 还是 TPS，还是任何其他【性能】-从广义来讲，一个存储系统到底能够以多高的平均时延来管理大多的存储空间，可能也是性能的一种。有了性能测试的目标，接下来就是拆解用例。如果把性能测试归为测试的话，测试就需要测试用例，测试用例只是用例的形式化表达。把用户的使用场景勾勒出来，把每一步拆解成的流程图或者时序图–我们已经得到了一个纸上的集成测试计划，只是没有跟性能挂上钩。接下来就进入真正写测试用例的环节了。我们的测试报告如果要涵盖足够立体的信息，则既要了解每一个环节/接口/API 的性能指标，又要了解整体的性能指标。这个时候测试工具的覆盖面就很重要了。如果我们选择偏黑盒的测试工具，apache ab /JMeter，则我们的测试用例就要围绕着对外交互的 API写，也只能测到外围接口的性能。这样的测试用例写起来最简单，无需侵入任何内部代码中。如果我们使用了 JMH 一类的工具，则可以自由编写对任何方法的测试用例。但需要对系统有非常...

现代垃圾收集器

所有的垃圾收集器，都基于弱分代假设。实际的垃圾回收效率取决于堆内对象的分布状况。垃圾回收并不能解决内存泄漏或者应用程序逻辑的不良分配习惯问题，要处理 JVM 内存回收问题的根本方法是对程序进行调优。有几个常用原则：减少临时对象，尽量复用内存。使用对象池。主动提前释放对象。主动 gc。好的代码比 tuning 更重要。选 gc 算法比 tuning 参数重要，tuning 参数是最后一步。其他情况，可以通过 tuning garbage collector 来解决。操作系统的影响 SWAP 可能会显著增加 GC 时间，因为被换出的堆还要被换入。美团的实践参考：《从实际案例聊聊Java应用的GC优化》《Java中9种常见的CMS GC问题分析与解决》 Minor GC Major GC Full GC 垃圾收集器分类可以看到一个现象：在大部分时候，g1 比 CMS 快，但极端的百分位里，CMS 比 g1 快。出处见这里。常用工具命令行终端标准终端类：jps、jinfo、jstat、jstack、jmap 功能整合类：jcm...

形式化方法的局限与工程取舍

第 10 篇展示了 CompCert、seL4、Four Color、Mathlib4、Feit-Thompson 五个把形式化推到极致的项目。它们也共同暴露了一件事：形式化的代价非常高，证明/代码比常在 2-25:1，时间跨度通常以年计，依赖少数 deep expert。本篇接着这条线，回答"什么时候不该上形式化"。判断的边界与判断的成本本身同等重要：错用形式化的项目要么半途而废，要么变成一份维护负担巨大的"科研作品"。本篇分四部分：形式化能给的与不能给的、与传统验证手段的关系、典型决策维度、几条可操作的判断准则。形式化能给的与不能给的能给的：对被建模部分的深层正确性保证。证完后该部分的实现错误被排除到内核 + 模型外。一致的接口：能用同一种语言（Lean / Coq）同时写程序、写规约、写证明、写元理论。跨变更的稳健性：每次修改 Lean 都重新检查全部依赖；不存在"改完忘补测试导致 regression"这种事。公开的信任面：通过 #print axioms 与代码评审可精确审计相信了什么。 ...

Java中的幽灵类型

什么是幽灵类型先上结论：幽灵类型（Phantom Type）顾名思义，就是幽灵般的类型，这种类型往往在运行时可以消失，因为在运行时没有任何作用，它们最大的特点就是没有任何实例（Java 的 Void 就是一个不可实例化类型的例子，常被用作幽灵类型的类型参数，如 Future<Void>）。幽灵类型是一种可以把有些运行时才能检测到的错误，在编译时检测出来的技巧。按照有些老外的观点，就是"Making Wrong Code Look Wrong"。在面向对象的编程语言之中，幽灵类型的实现，往往与状态模式较为接近，但比状态模式提供了更强的纠错功能。在 Java 5 以后的版本里，程序员可以使用泛型。通过泛型的类型参数，Java 中也拥有了幽灵类型的能力。上面的阐述是不是很难看懂？直接进入具体的例子。假设有一个飞机控制程序，操作飞机起飞或者落地。这个程序有一个非常强的业务约束，就是必须保证飞机一开始必须出现在地上，只有在地上的飞机可以起飞，只有起飞的飞机可以落地，那么应该怎样设计程序（主要是类型关系），来保证这个约束必然成立呢？定义状态接口先来定义...

Spring MVC 把 httprequest 放入线程的过程 1234567891011public class ServletRequestAttributes extends AbstractRequestAttributes { /** * Create a new ServletRequestAttributes instance for the given request. * @param request current HTTP request */ public ServletRequestAttributes(HttpServletRequest request) { Assert.notNull(request, "Request must not be null"); this.request = request; }} 在 RequestContextFilter 的子类 OrderedRequestContextFilter： 123456789101112131415161718...

Maven 完全指南

本文整合了 Maven 构建生命周期、插件配置、依赖管理、全局配置 settings.xml、FatJar 打包、测试与覆盖率等全部知识点，是一份系统性的 Maven 参考指南。 maven-生命周期.xmind 构建生命周期构建生命周期的基础知识 Maven 基于一个"构建生命周期"的中心概念，也就意味着构建和发布一个特定的工件（也就是工程）的过程已经被清晰地定义了。有三种内置的生命周期：default，clean 和 site。default 生命周期处理项目部署，clean 生命周期处理项目清理，site 生命周期处理项目的站点（site）文档的创建。 graph TD subgraph Clean生命周期 A1[pre-clean] --> A2[clean] A2 --> A3[post-clean] end subgraph Default生命周期 B1[validate] --> B2[initialize] B2 -->...

Loading Database