前脚研究完 Mockito 中被 Mocked 的对象属性及方法的默认值, 虽然目今更多的是拥抱着 Mockito, 但总有时对 JMockit 也会挤眉弄眼，谁叫 JMockit 无所不能呢！被 Mockito 的 Mock 对象方法的默认返回值洗脑之后，进而觉察出 JMockit 应该有同样的实现方式。
经过类似的测试，这里不详细列出测试过程，只是在基于前篇的测试中加入 JMockit 的依赖，最新版是 1.36。测试类 MyClassTest 中使用
|
1 2 |
@Mocked private MyClass myClass; |
来构造 MyClass 的 mock 对象 myClass, 其余代码是一样的。相关代码请前往上篇 Mockito 中被 Mocked 的对象属性及方法的默认值 中找。 使用 JMockit 后跑出来的效果如下： 阅读全文 >>
在 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 对象默认的属性值与方法默认返回值。 阅读全文 >>
本文通过对 Spring 的源代码来理解它是如何扫描 Bean 与资源的，因为自己有一个类似的需求，想把一堆的配置文件丢到 resources 下某个目录中，在程序启动的时候能加载它们。因为文件名是不一定的，所以不能直接指定文件名来加载，通过对 Spring 扫描资源的理解后，可以在自己的代码中手工扫描那些配置文件，以后有任何新的配置文件只需要扔到相应的配置目录即可。
下面以一个最简单的 Spring Boot 项目为例，调试并观察源代码
|
1 2 3 4 5 6 7 |
@SpringBootApplication @ComponentScan(basePackages = "cc.unmi") public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } } |
还是直奔主题吧，不一步一步的去探寻到底是哪个实现类去扫描资源的，用 Google 找到的是 ClassPathScanningCandidateComponentProvider, 因此直接在这个类的敏感位置上打上断点，比如它的构造函数 阅读全文 >>
昨天刚刚侍弄完 Spring 下基于自定义注解拦截方法调用，现在试下纯 AspectJ 的方式来打造，因为不是每一个项目都是 Spring。这次要推到 5 年前试验过用 javac 命令行编译的方式织入方面，见 AspectJ 基于自定义的方法注解来拦截方法，这次着重在用 aspectj-maven-plugin 插件的方法来织入 AspectJ 方面。
基本上代码还是昨天的，需求还是一样的:
被 @LogStartTime 注解的方法在进入该方法时记录当前时间在 ThreadLocal 中，并能根据 @LogStartTime 的属性值决定处理逻辑
因为 Java5+ 之后 AspectJ 可以写成 Java 类加注解的方式，*.aj 文件一般都没太大必要了，所以可以和 Spring AOP 共用一个 @Aspect 注解的方面代码 MethodStartAspect。
我们将采用编译器织入，因此项目依赖只需要一个 org.aspectj:aspectjrt:1.8.0, 它也不会引入别的组件。同样我们从 Main 方法和测试用例两方面来验证实现的效果，下面是整个测试项目的布局，以及依赖，除掉单元测试的其时就只需要一个 jar 包。 阅读全文 >>
其实很多年前就做过如此的实验，一翻开自己的日志有关于 aspectj site:yanbin.blog, 可以找到 2008 年写的日志。真是流光容易把人抛，红了樱桃，绿了巴蕉。只是那时候 Spring 刚步入 2.0, 才翻开强大 AOP 的篇章，还记得彼时只要是直接使用 AspectJ 就要写 *.aj 文件。而如今 Spring 都到 5.0 了，也就是一年前才重拾起 Spring, 这期间 AspectJ 早就可以不用 *.aj 文件，只需普通 Java 文件，加上 @Aspect 和 @Pointcut 之类的注解就行。
本文内容与几年前写过的日志大体相差不大，再缀上一篇纯粹是个人笔记。这里不以 Spring 5.0 为例，仍然是最新的 4.3.11.RELEASE, 并且直接用 Spring, 而非选择 Spring Boot, 因为用了 Spring Boot 常常搞不清楚哪些是自动配置了的。原生的 Spring 可以使自己掌握一个 Spring AOP 的基本要素。
需求：@LogStartTime 注解的方法，在每次进入该方法时把当前时间写入 ThreadLocal 中去，被 @LogStartTime 注解的方法中随时可以获得进入方法的时间 阅读全文 >>
上一篇 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 2 3 4 5 6 |
<dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.0.0</version> <scope>test</scope> </dependency> |
这样在当前的 IntelliJ IDEA(2017.2.4) 可以执行 JUnit 5 的测试用例。但要让 Maven 找到 JUnit 5 的测试用例，还得在 pom.xml 中加上 阅读全文 >>
在研究 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 方法来复位该实例变量，现在才知道那是多余的。像下面的代码
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
public class CalculatorTest { private int number = 100; @Test public void test1() { System.out.println(number); number = 200; } @Test public void test2() { System.out.println(number); number = 300; } } |
一直在关注 JUnit 5 的演进，自两年前首个 ALPHA 版后，经历了 6 的 Milestone, 3 个 RC 终于在 2017/09/10 正式发布了。其实还从未对其深究过，今天算是正式开始体验。
不像以往的版本，JUnit 5 现在是三个模块的合体 JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
以上三个模块分工还是很明确，因此
但是由于 jar 包之间本身存在某种依赖关系，所以实际上 pom.xml 可以比想像的更简单 阅读全文 >>
用过 Spring 的 @EnableScheduling 的都知道，我们用三种形式来部署计划任务，即 @Scheduled 注解的 fixedRate(fixedRateString), fixedDelay(fixedDelayString), 以及 cron. cron 不在这里讨论的范畴。我们着重在如何理解 fixedRate 和 fixedDelay 的区别。
在 Spring 的 Scheduled 注解的 JavaDoc 对此的解释很简单
public abstract long fixedRate
Execute the annotated method with a fixed period in milliseconds between invocations.public abstract long fixedDelay
Execute the annotated method with a fixed period in milliseconds between the end of the last invocation and the start of the next.
只是说是 fixedRate 任务两次执行时间间隔是任务的开始点，而 fixedDelay 的间隔是前次任务的结束与下次任务的开始。
大致用示意字符串来表示如下(每个 T1, 或 T2 代表任务执行秒数(每次任务执行时间不定)，假定 fixedRate 或 fixedDelay 的值是 5 秒，用 W 表示等待的数)
fixedRate: T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6........
fixedDelay: T1.T1.WWWWW.T2.T2.T2WWWWW.T3.T3.T3.T3.T3.WWWWW.T4.T4.T4.T4.T4.T4.T4.WWWWWT6.T6......
一般来说能理解到上面两个场景已经差不多了，相比而言 fixedDelay 简单些，盯着上一次任务的屁股就行。 阅读全文 >>
两年前写过一篇 Java 反射修改 final 属性值, 在这里重新温习一下，假设有个类
class Person {
public final String name = "Mike";
}
这里声明 name 为非静态的属性只是为了说明反射修改 final 属性无关乎静态不静态，静态只是表现在它是一个类属性，在一个类加载器空间只会有一份拷贝，仅此而已。
创建一个通用方法进行反射修改属性值
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public static void modify(Object object, String fieldName, Object newFieldValue) throws Exception { Field field = object.getClass().getDeclaredField(fieldName); Field modifiersField = Field.class.getDeclaredField("modifiers"); modifiersField.setAccessible(true); //Field 的 modifiers 是私有的 modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); if(!field.isAccessible()) { field.setAccessible(true); } field.set(object, newFieldValue); } |
调用 modify(...) 方法试图修改 person 的 name 属性 阅读全文 >>