JUnit 5 刚出来那时，也就是第一个版本 5.0.0 时，还不能很好的支持 Mockito 的测试，因为 Mockito 没能跟得那么紧密。那时候 JUnit 5 只能试验性的提供了一个极不正式的 com.example.mockito.MockitoExtension, 看那包名就知道不是来真的，所以决定再等。JUnit 5 不再原生支持 JUnit 4 的 Rule，一切都将是 Extension，那也是要求 Mockito 能够与之俱进。现在等来了，JUnit 5 进化到了 5.2.0, Mockito 也早已有了一个单独的模块mockito-junit-jupiter来迎接它。
在 Mockito 2.1.0 的 What's new in Mockito 2 中记述了 JUnit 5 为 Mockito 2 开发了一个 MockitoExtension。追溯到 Mockito 2 的 Release Notes, 我们发现 Mockito 2 官方最早引入 MockitoExtension 的版本是 2.16.3(2018-03023)。我对 Mockito 对 JUnit 5 支持的最新更新是从这个 Pull Request MockitoExtension for JUnit5 得知的。
一句话讲就是现在的 Mockito 2 有原生态的 MockitoExtension 来支援 JUnit 5, 可以非常放心可靠的让 JUnit 5 和 Mockito 2 一起稳定工作。因此前面那个包名带example字样的 MockitoExtension 链接也就无效了。 Read More
初识 Mockito 这个测试框架后，我们要使用 Mock 的属性创建一个被测试类实例时，大概会下面这么纯手工来打造。
假定类
UserService有一个属性UserDao userDao, 需要构造UserService实例时 Mock 内部状态UserDao userDao = Mockito.mock(UserDao.class);
UserService testMe = new UserService(userDao);如此，userDao 的行为就可以自由模拟了，这种纯手工方式都不需要给测试类添加
@RunWith(MockitoJunitRuner.class)
//或
MockitoAnnotations.initMocks(this);因为上面两句是给 Mockito 的注解使用的。
如果所有的 Mock 对象全部通过手工来创建，那就不容易体现出 Mockito 的优越性出来。因此对于被测试对象的创建，Mock 属性的注入应该让
@Mock和@InjectMocks这两个注解大显身手了。标注在实例变量上的
@Mock相当于是Mockito.mock(Class)创建了一个 Mock 对象，而@InjectMock标的实例会寻找到相应 Mock 属性想法构造出被测试类的实例。看下面的例子： Read More
前脚研究完 Mockito 中被 Mocked 的对象属性及方法的默认值, 虽然目今更多的是拥抱着 Mockito, 但总有时对 JMockit 也会挤眉弄眼，谁叫 JMockit 无所不能呢！被 Mockito 的 Mock 对象方法的默认返回值洗脑之后，进而觉察出 JMockit 应该有同样的实现方式。
经过类似的测试，这里不详细列出测试过程，只是在基于前篇的测试中加入 JMockit 的依赖，最新版是 1.36。测试类 MyClassTest 中使用1@Mocked 2private MyClass myClass;
来构造 MyClass 的 mock 对象 myClass, 其余代码是一样的。相关代码请前往上篇 Mockito 中被 Mocked 的对象属性及方法的默认值 中找。 使用 JMockit 后跑出来的效果如下： Read More在 Java 测试中使用 Mockito 有段时日了，以前只是想当然的认为 Mock 的对象属性值和方法返回值都是依据同样的规则。基本类型是 0, 0.0, 或 false, 对象类型都是 null, Mock 对象的默认返回值也应该是一样的。直到最近有一天，有一个返回
Optional<String>类型的方法，由于忘记对该方法打桩，意外的发现它返回的不是 null, 而Optional.empty(), 因此才意识到此处定有蹊跷。着实有必要用代码验证一下 Mockito 是怎么决定属性及方法的各种返回类型的默认值的。此次测试所用的 Mockito 版本是 mockito-core-2.12.0.
于是创建了下面一个类 MyClass 用于生成 Mock 对象，选取了一些典型的数据类型, 包括 int, Double, String, long[], Optional<String>, Collection<String>, Map<String, String>, 同时测试 Mock 对象默认的属性值与方法默认返回值。 Read More
- 上一篇 JUnit 5 快速上手(从 JUnit 4 到 JUnit 5) 介绍了如何在一个项目中同时使用 JUnit 4 和 JUnit 5。现在来开始了解 JUnit 5 的新特性. 我们现在的项目基本是用 Maven 来管理依赖，在 Maven 项目中如何引入 JUnit 5 可以参考官方例子 junit5-maven-consumer. 我们知道 JUnit 5 包括三个模块，不用 JUnit 4 的话只要 Platform 和 Jupiter, 而 Jupiter Maven 模块本身依赖于 JUnit Platform, 因此应用 JUnit 5 的项目 Maven 配置就是
1<dependency> 2 <groupId>org.junit.jupiter</groupId> 3 <artifactId>junit-jupiter-engine</artifactId> 4 <version>5.0.0</version> 5 <scope>test</scope> 6</dependency>
这样在当前的 IntelliJ IDEA(2017.2.4) 可以执行 JUnit 5 的测试用例。但要让 Maven 找到 JUnit 5 的测试用例，还得在pom.xml中加上 Read More 在研究 JUnit 5 新特性的时候，学习到其中有一节 Test Instance Lifecycle, 才意识到对 JUnit 的理解一直存在一个误区，以为 JUnit 是以测试类为一个生命周期的，其实不然。不管是 JUnit 5 还是 JUnit 4 或更早的版本，JUnit 都是以测试方法为一个独立的生命周期。
只是到了 JUnit 5 提供了方法来把生命周期由方法改为测试类，对于单个测试类可以使用注解
@TestInstance(Lifecycle.PER_CLASS)来指定用一个测试实例来跑所有的测试方法，这就意味着测试类中的成员变量只被初始化一次。@TestInstance的 Lifecycle 默认是 PER_METHOD, JUnit 4 就是 PER_METHOD, 而且是不能改的。如果在 JUnit 5 中改变为 PER_CLASS, 恐怕反而会出许多乱子，每个测试方法本就该是完全独立的。比如在同一个类中多个测试方法使用了同一个实例变量的情况下，总会用一个
@After方法来复位该实例变量，现在才知道那是多余的。像下面的代码1public class CalculatorTest { 2 3 private int number = 100; 4 5 @Test 6 public void test1() { 7 System.out.println(number); 8 number = 200; 9 } 10 11 @Test 12 public void test2() { 13 System.out.println(number); 14 number = 300; 15 } 16}一直在关注 JUnit 5 的演进，自两年前首个 ALPHA 版后，经历了 6 的 Milestone, 3 个 RC 终于在 2017/09/10 正式发布了。其实还从未对其深究过，今天算是正式开始体验。
不像以往的版本，JUnit 5 现在是三个模块的合体 JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
- JUnit Platform: 运行测试的基础平台。还定义了开发测试框架的 TestEngine API。并提供了命令行执行测试以及与 Gradle, Maven, JUnit4 Runner 的集成
- JUnit Jupiter: 包含了新的编程和扩展模型。它还提供了一个运行新型测试的 TestEngine 实现
- JUnit Vintage: 提供了一个让 JUnit Platform 运行 JUnit 3 和 JUnit 4 的 TestEngine 实现
以上三个模块分工还是很明确，因此
- 从现有的 JUnit 4 项目步入到 JUnit 5 至少两 JUnit Platform 和 JUnit Vintage 两个
- 建立全新项目可以只引入 JUnit Platform 和 JUnit Jupiter
- 混合型当然是三个全部引入
但是由于 jar 包之间本身存在某种依赖关系，所以实际上 pom.xml 可以比想像的更简单 Read More