Loading...

JUnit4/JUnit5 注解

Created2019-12-30|Updated2026-01-24

|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

G1/ZGC/Shenandoah 垃圾收集器对比

垃圾收集的核心挑战垃圾收集器的设计始终面临三个核心指标的权衡：吞吐量、延迟和内存占用。这三个指标构成了一个不可能三角，优化其中一个指标往往需要牺牲其他指标。吞吐量指单位时间内完成的工作量，通常用应用程序运行时间占总时间的比例来衡量。对于批处理任务、科学计算等场景，高吞吐量是首要目标。延迟指垃圾收集造成的应用停顿时间。对于交互式应用、金融交易系统等对响应时间敏感的场景，低延迟至关重要。延迟通常关注最大停顿时间和停顿时间分布。内存占用指垃圾收集器为了完成收集工作所需的额外内存空间。内存受限的环境下，收集器自身的内存开销成为关键约束。传统垃圾收集器在三者之间做出明确取舍：Serial 和 Parallel GC 追求高吞吐量，但停顿时间较长；CMS GC 降低停顿时间，但牺牲吞吐量并占用更多内存。现代收集器试图在三者之间找到更优的平衡点。 G1（Garbage First）收集器 G1 收集器在 JDK 7u4 版本正式推出，是 JDK 9 之后的默认垃圾收集器。G1 的核心思想是打破传统分代收集的物理隔离，将堆内存划分为多个大小相等的 Region。 Region 化堆内存...

Spark SQL 原理

Spark SQL的发展历程为了给熟悉的 RDBMS 但又不理解 MapReduce 的技术人员提供快速上手的工具，Hive 应运而生，他是当时唯一运行在 Hadoop 上的SQL-On-Hadoop 工具。但是 MapReduce 计算过程中大量的中间磁盘落地过程消耗了大量的 I/O，降低的运行效率，为了提高 SQL 的执行效率，大量的 SQL-On-Hadoop工具开始产生，而 Shark 是其中一个表现较为突出的项目。 Shark是伯克利实验室 Spark 生态环境的组件之一，它主要修改了内存管理，物理计划和执行三个模块，值得它能运行在 Spark 的引擎上，从而提高 SQL 查询的效率。但是随着 Spark 的发展，Shark 对 Hive 过多的依赖制约了 Spark 的设计理念和各个组件之间的相互继承，所以 Spark 团队停止了对 Shark 的开发，提出了 SparkSQL 项目。因为摆脱了Hive 的过度依赖，Spark SQL在数据兼容性，性能优化和组件扩展等各个方面都得到了极大的方便和发展。提出了 SparkSQL 项目之后，SQL On Spar...

Java 注解和配置

Java 的原生注解 meta annotation @Inherited @Inherited 是一个元注解（annotations applied to other annotations 注解其他注解的注解），也是一个标记注解，@Inherited阐述了某个被标注的类型是被继承的。 **@Inherited annotation类型是被标注过的class的子类所继承。类并不从它所实现的接口继承annotation，方法并不从它所重载的方法继承annotation。**其查找过程是：反射 API 会在查找 @Inherited 标注的注解的时候，自底向上往继承树上方查找。 12345678910111213141516171819202122@Inherited@Retention(RetentionPolicy.RUNTIME)@Target(ElementType.TYPE)public @interface MyAnnotation { String value() default "Default Value";}@MyA...

昂贵的异常

抛出问题 Joshua Bloch 在《Effective Java》的 Item 57 里明确地提到过，不要试图用 Exception 的跳转来代替正常的程序控制流。他列举了很多原因，但特别提到了抛出异常会使得整个程序运行变慢。抛出异常远比普通的 return、break 等操作对控制流、数据流的性能影响要大，它就只适合拿来作异常分支的控制语句，而不能拿来编写正常的逻辑。 Throwing exception is expensive. 这句话在 Java 的程序员世界里面已经成为老生常谈，却很少有人谈及到底抛出异常比正常的程序跳转返回慢在哪里，有多慢。"不要滥用异常"好像一个猴子定律，人们知道不能这么做，却不明白为什么不能这么做。此前读了一位同事写的好文《Java虚拟机是如何处理异常的》，深入地分析了 JVM 对异常跳转的处理过程：JVM 会通过异常表的机制，优化异常抛出和正常返回之间的性能差异。仅从程序计数器的移动上来讲，抛出一个异常对栈帧的弹栈并不比直接返回更昂贵。写在前头的结论是："try-catch 语句块几乎不会影响程序运行性能！...

MESI 协议与 Java 并发可见性——从硬件到 JMM

为什么 volatile 能保证可见性？为什么 synchronized 既保证原子性又保证可见性？答案藏在 CPU 缓存一致性协议和内存屏障中。本文将从硬件层面的 MESI 协议出发，逐步上升到 Java 内存模型（JMM），揭示并发可见性问题的完整因果链。 Part 1: CPU 缓存架构为什么需要 CPU 缓存现代 CPU 的运算速度远超内存访问速度，两者之间存在巨大的速度鸿沟：操作延迟相对速度 CPU 寄存器访问 ~0.3 ns 1x L1 Cache 访问 ~1 ns 3x L2 Cache 访问 ~4 ns 13x L3 Cache 访问 ~12 ns 40x 主内存访问 ~100 ns 333x 如果 CPU 每次都直接访问主内存，大部分时间都在等待数据。缓存利用了时间局部性和空间局部性，将最近和附近的数据保存在更快的存储中。多级缓存架构 12345678910111213141516171819┌──────────────────────────────────────────────────────┐│ ...

日期与时间

JSR 310 Java Date与Time API 新旧 API 的更迭旧的 Java API 主要包括java.util.Date和java.util.Calendar 两个包的内容。这两个包的时间类型是可变的。如 Date 的实例可以通过 setYear 来产生变化。 JSR 310 中包括的日期类型主要有：计算机时间：Instant，对应 java.util.Date，它代表了一个确定的时间点，即相对于标准Java纪元（1970年1月1日）的偏移量；但与java.util.Date类不同的是其精确到了纳秒级别。人类时间：对应于人类自身的观念，比如LocalDate和LocalTime。他们代表了一般的时区概念，要么是日期（不包含时间），要么是时间（不包含日期），类似于java.sql的表示方式。此外，还有一个MonthDay，它可以存储某人的生日（不包含年份）。每个类都在内部存储正确的数据而不是像java.util.Date那样利用午夜12点来区分日期，利用1970-01-01来表示时间。这些类型的实例是 immutable 的，而且只能通过工厂方法创建。时区...