mirror of
https://github.com/alibaba/testable-mock.git
synced 2025-03-25 01:00:24 +08:00
update doc to fit version 0.6
This commit is contained in:
金戟
parent
3acf341d1f
commit
df7e641a0c
@ -23,4 +23,4 @@ The functionality of `TestabledMock` is basically the same as that of `PowerMock
|
||||
|
||||
The main disadvantage of the current `TestableMock` is that the IDE cannot promptly prompt whether the method parameters are matched correctly when writing the mock method. If the mocking effect does not meet expectation, it has to be verified during runtime through the method provided in the [self-help troubleshooting](en-us/doc/troubleshooting.md) document. This feature needs to be provided by extending IDE plugins in the future.
|
||||
|
||||
In addition, because `TestableMock` uses the mock mechanism based on a single method in a unique way, it decouples the mock method definition from the unit test cases. Thus, the mock methods are by default reusable, and the unit test cases become cleaner and purer. On the other hand, the mock methods become fragmented, and life cycle management is relatively difficult. Therefore, it may take some time for developers get used to it.
|
||||
In addition, because `TestableMock` uses the mechanism based on "each source class binding to its own mock class" in a unique way, it decouples the mock method definition from the unit test cases. Thus, the mock methods are by default reusable, and the unit test cases become cleaner and purer. On the other hand, the mock methods become fragmented, and life cycle management is relatively difficult. Therefore, it may take some time for developers get used to it.
|
||||
|
||||
@ -5,8 +5,8 @@ Use TestableMock
|
||||
|
||||
- [Quickly mock arbitrary call](en-us/doc/use-mock.md): quickly replace any method invocation in the class under test with a mock method, solve the cumbersome use of traditional mock tools problem
|
||||
- [Access private members of the class under test](en-us/doc/private-accessor.md): enable unit tests directly invoke or access private members of the class under test, solve the problems of private member initialization and private method testing
|
||||
- [Quickly construct complicated parameter object](en-us/doc/omni-constructor.md)：generate arbitrarily nested object instances, simplify their internal member assignment methods, solve the problem of long initialization codes for method parameters
|
||||
- [Auxiliary test void method](en-us/doc/test-void-method.md): use the mock validator to check the internal logic of method, solve the problem that unit testing is difficult to implement to the method with no return value
|
||||
- [Quickly construct complicated parameter object](en-us/doc/parameter-constructor.md)：generate arbitrarily nested object instances, simplify their internal member assignment methods, solve the problem of long initialization codes for method parameters
|
||||
|
||||
## Use in Maven project
|
||||
|
||||
|
||||
@ -1,13 +1,31 @@
|
||||
Upgrade To Version 0.5
|
||||
Upgrade Guide
|
||||
---
|
||||
|
||||
After nearly a month of design and development, the `0.5` version of TestableMock has finally come out. Compared with the `0.4` version, the new version solves the three historical problems left over before:
|
||||
### Upgrade to v0.6
|
||||
|
||||
In version `0.6`，`TestableMock` provided a new [quick complicated class construction](en-us/doc/omni-constructor.md) capability. Meanwhile, it includes a modification that is incompatible with the `0.5` version: class `PrivateAccessor` have been moved from `com.alibaba.testable.core.accessor` package to `com.alibaba.testable.core.tool` package.
|
||||
|
||||
If you are using `PrivateAccessor` and having import statement like this:
|
||||
|
||||
```java
|
||||
import com.alibaba.testable.core.accessor.PrivateAccessor;
|
||||
```
|
||||
|
||||
When upgrade `TestableMock` to `0.6` version, please replace it as：
|
||||
|
||||
```java
|
||||
import com.alibaba.testable.core.tool.PrivateAccessor;
|
||||
```
|
||||
|
||||
### Upgrade to v0.5
|
||||
|
||||
The `0.5` version solves the three historical problems left over before:
|
||||
|
||||
1. <s>**Mock method cannot call other non-static methods**</s>. The mock method in the new version no longer has any difference from the ordinary method, and can access any external method and member variable.
|
||||
2. <s>**Mock method always acts on the entire test life cycle**</s>. From now on, the mock method supports restricting the effective scope to the test cases in the test class of which it belongs, so there is no need to worry about accidentally mocking cross-class test invocations.
|
||||
3. <s>**The MOCK_CONTEXT needs manually cleaned up and only supports class-level parallel testing**</s>. Now each test case has an independent `MOCK_CONTEXT` variable, no need to clean up after used, and you can use unit test with any parallel level.
|
||||
|
||||
In order to better realize the reuse of Mock methods, we have made a clear boundary between the mock class and the test class in the new version. When upgrading from `0.4` to `0.5`, the only change required is to wrap all mock methods in the test class with a `public static class Mock {}`.
|
||||
In order to better realize the reuse of Mock methods, the version `0.5` have made a clear boundary between the mock class and the test class in the new version. When upgrading from `0.4` to `0.5`, the only change required is to wrap all mock methods in the test class with a `public static class Mock {}`.
|
||||
|
||||
For example, the original test class definition was as follows:
|
||||
|
||||
@ -46,4 +64,4 @@ public class DemoMockTest {
|
||||
}
|
||||
```
|
||||
|
||||
Then upgrade the `TestableMock` dependency in the `pom.xml` or `build.gradle` file to `0.5.0` or above.
|
||||
Finally, upgrade the `TestableMock` dependency in `pom.xml` or `build.gradle` file to the new version.
|
||||
@ -9,7 +9,7 @@ Compared with the class-granularity mocking practices of existing mock tools, `T
|
||||
|
||||
The detail mock method definition convention is as follows.
|
||||
|
||||
#### 0. Pre-step, prepare the mock class
|
||||
### 0. Pre-step, prepare the mock class
|
||||
|
||||
First, create a mock class as the container for mock methods associated with the test class. The simplest way is to add a static inner class named `Mock` to the test class. E.g:
|
||||
|
||||
@ -23,7 +23,7 @@ public class DemoTest {
|
||||
}
|
||||
```
|
||||
|
||||
#### 1. Mock method calls of any class
|
||||
### 1.1 Mock method calls of any class
|
||||
|
||||
Define an ordinary method annotated with `@MockMethod` in the mock class with exactly the same signature (name, parameter, and return value type) as the method to be mocked, and then add the type of target object (which the method originally belongs to) as `targetMethod` parameter of `@MockMethod` annotation.
|
||||
|
||||
@ -69,7 +69,7 @@ private String substring(String self, int i, int j) {
|
||||
|
||||
For complete code examples, see the `should_mock_common_method()` test cases in the `java-demo` and `kotlin-demo` sample projects. (Because Kotlin has made magical changes to the String type, the method under test in the Kotlin example adds a layer of encapsulation to the `BlackBox` class)
|
||||
|
||||
#### 2. Mock the member method of the class under test itself
|
||||
### 1.2 Mock the member method of the class under test itself
|
||||
|
||||
Sometimes, when testing certain methods, it is desirable to mock out some other member methods of the class under test itself.
|
||||
|
||||
@ -89,7 +89,7 @@ Similarly, if the method in the above example needs to access the original teste
|
||||
|
||||
For complete code examples, see the `should_mock_member_method()` test case in the `java-demo` and `kotlin-demo` sample projects.
|
||||
|
||||
#### 3. Mock static methods of any class
|
||||
### 1.3 Mock static methods of any class
|
||||
|
||||
Mock for static methods is the same as for any ordinary methods.
|
||||
|
||||
@ -104,7 +104,7 @@ private BlackBox secretBox() {
|
||||
|
||||
For complete code examples, see the `should_mock_static_method()` test case in the `java-demo` and `kotlin-demo` sample projects.
|
||||
|
||||
#### 4. Mock `new` operation of any type
|
||||
### 1.4 Mock `new` operation of any type
|
||||
|
||||
Define an ordinary method annotated with `@MockContructor` in the mock class, make the return value type of the method the type of the object to be created, and the method parameters are exactly the same as the constructor parameters to be mocked, the method name is arbitrary.
|
||||
|
||||
@ -125,7 +125,7 @@ private BlackBox createBlackBox(String text) {
|
||||
|
||||
For complete code examples, see the `should_mock_new_object()` test case in the `java-demo` and `kotlin-demo` sample projects.
|
||||
|
||||
#### 5. Identify different invocation source in mock method
|
||||
### 2. Identify different invocation source in mock method
|
||||
|
||||
In the mock method, you can use the `TestableTool.SOURCE_METHOD` variable to identify **the method name of the class under test before entering the mock method**; in addition, the `TestableTool.MOCK_CONTEXT` variable can **inject additional context parameters into the mock method**, to distinguish and process different calling scenarios.
|
||||
|
||||
@ -159,7 +159,7 @@ private Data mockDemo() {
|
||||
|
||||
For complete code examples, see the `should_get_source_method_name()` and `should_get_test_case_name()` test cases in the `java-demo` and `kotlin-demo` sample projects.
|
||||
|
||||
#### 6. Verify the sequence and parameters of the mock method being invoked
|
||||
### 3. Verify the sequence and parameters of the mock method being invoked
|
||||
|
||||
In test cases, you can use the `TestableTool.verify()` method, and cooperate with `with()`, `withInOrder()`, `without()`, `withTimes()` and other methods to verify the mock call situation.
|
||||
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
- [Use TestableMock](en-us/doc/setup.md)
|
||||
- [Fast Mocking](en-us/doc/use-mock.md)
|
||||
- [Private Accessor](en-us/doc/private-accessor.md)
|
||||
- [Omni Constructor](en-us/doc/omni-constructor.md)
|
||||
- [Test Void Method](en-us/doc/test-void-method.md)
|
||||
- [Parameter constructor](en-us/doc/parameter-constructor.md)
|
||||
|
||||
- Usage Guide
|
||||
- [Verify Mock Invocation](en-us/doc/invoke-matcher.md)
|
||||
@ -16,7 +16,7 @@
|
||||
- [Testable Maven Plugin](en-us/doc/use-maven-plugin.md)
|
||||
|
||||
- Technical Reference
|
||||
- [Upgrade To Version 0.5](en-us/doc/upgrade-to-v05.md)
|
||||
- [Upgrade Guide](en-us/doc/upgrade-guide.md)
|
||||
- [Available Global Arguments](zh-cn/doc/javaagent-args.md)
|
||||
- [Available Annotations](zh-cn/doc/annotations.md)
|
||||
- [How Mock Works](zh-cn/doc/design-and-mechanism.md)
|
||||
|
||||
@ -21,6 +21,6 @@
|
||||
|
||||
相比之下，`TestabledMock`的功能与`PowerMock`基本平齐，且极易上手，只需掌握`@MockMethod`注解就可以完成绝大多数任务。
|
||||
|
||||
当前`TestableMock`的主要不足在于，编写Mock方法时IDE尚无法即时提示方法参数是否正确匹配。若发现匹配效果不符合预期，需要通过[自助问题排查](zh-cn/doc/troubleshooting.md)文档提供的方法在运行期进行校验。这个功能未来需要通过扩展主流IDE插件来提供。
|
||||
当前`TestableMock`的主要不足在于，编写Mock方法时IDE无法即时提示方法参数是否正确匹配。若发现匹配效果不符合预期，需要通过[自助问题排查](zh-cn/doc/troubleshooting.md)文档提供的方法在运行期进行校验。这个功能理论上能够通过扩展主流IDE插件来补充，但目前暂无相关开发计划，参见[Issue-104](https://github.com/alibaba/testable-mock/issues/104)。
|
||||
|
||||
此外，由于`TestableMock`独辟蹊径的采用基于单个方法的Mock机制，将Mock方法定义与单元测试用例解耦，一方面使得Mock方法具有默认可复用性，单元测试用例也因此变得更干净纯粹，另一方面也导致Mock方法定义变得零散，生命周期管理起来相对困难，对现有开发者的Mock编写习惯会带来一定改变。
|
||||
此外，由于`TestableMock`独辟蹊径的采用“每个业务类拥有一个专属Mock容器类”的思维方式，将Mock方法定义与单元测试用例解耦，一方面使得Mock方法具有默认可复用性，单元测试用例也因此变得更干净纯粹，另一方面也导致Mock方法定义变得零散，生命周期管理起来相对困难，对现有开发者的Mock编写习惯会带来一定改变。
|
||||
|
||||
111
docs/zh-cn/doc/omni-constructor.md
Normal file
111
docs/zh-cn/doc/omni-constructor.md
Normal file
@ -0,0 +1,111 @@
|
||||
快速构造复杂的参数对象
|
||||
---
|
||||
|
||||
在单元测试中，测试数据的准备和构造是一件既必须又繁琐的任务，尤其遇到被测函数的入参类型结构复杂、没有合适的构造方法、成员对象使用私有内部类的时候，常规方法往往无处下手。为此`TestableMock`提供了`OmniConstructor`和`OmniAccessor`两个极简的工具类，从此让一切对象构造不再困难。
|
||||
|
||||
### 1. 一行代码构造任何对象
|
||||
|
||||
万能的对象构造器`OmniConstructor`有两个静态方法：
|
||||
|
||||
- `newInstance(任意类型)` ➜ 指定任意类型，返回一个该类型的对象
|
||||
- `newArray(任意类型, 数组大小)` ➜ 指定任意类型，返回一个该类型的数组
|
||||
|
||||
例如：
|
||||
|
||||
```java
|
||||
// 构造一个ComplicatedClass类型的对象
|
||||
ComplicatedClass obj = OmniConstructor.newInstance(ComplicatedClass.class);
|
||||
// 构造一个ComplicatedClass[]类型，容量为5的数组
|
||||
ComplicatedClass[] arr = OmniConstructor.newArray(ComplicatedClass.class, 5);
|
||||
```
|
||||
|
||||
值得一提的是，使用`OmniConstructor`构造出来的并非是一个所有成员值为`null`的简单空对象。该对象的所有成员，以及所有成员的所有子成员，都会在构造时被依次递归赋值。相比直接用`new`构造的对象，使用`OmniConstructor`能够确保对象完全初始化，无需担心测试过程中发生`NullPointerException`问题。
|
||||
|
||||
> **注意**：在`0.6.0`版本中，类型为接口或抽象类的成员字段依然会被初始化为`null`，此问题将在近期版本修复
|
||||
|
||||
```java
|
||||
// 使用构造函数创建对象
|
||||
Parent parent = new Parent();
|
||||
// 内部成员未初始化，直接访问报NullPointerException异常
|
||||
parent.getChild().getGrandChild();
|
||||
|
||||
// 使用OmniConstructor创建对象
|
||||
Parent parent = OmniConstructor.newInstance(Parent.class);
|
||||
// 无需顾虑，安心访问任意子成员
|
||||
parent.getChild().getGrandChild().getContent();
|
||||
```
|
||||
|
||||
除了用于构造方法的入参，`OmniConstructor`也可以用于快速构造Mock方法的返回值，相比将`null`作为Mock方法的返回值，使用完全初始化的对象能够更好保障测试的可靠性。
|
||||
|
||||
详见`java-demo`和`kotlin-demo`示例项目`DemoOmniMethodsTest`测试类中的用例。
|
||||
|
||||
### 2. 一行代码访问任意深度成员
|
||||
|
||||
在单元测试中，有时会遇到一些结构复杂的参数对象，但与特定测试用例有关的仅仅是该对象结构深处的个别几个属性和状态。`OmniAccessor`的灵感来自于`XML`语言中的`xpath`节点选择器，它有`get`、`set`两个主要的静态方法：
|
||||
|
||||
- `get(任意对象, "访问路径")` ➜ 返回根据路径匹配搜索到的所有成员对象
|
||||
- `set(任意对象, "访问路径", 新的值)` ➜ 根据路径匹配为指定位置的对象赋值
|
||||
|
||||
还有一个用于精确路径匹配时直接获取唯一目标对象的`getFirst()`辅助方法，其作用等效于`OmniAccessor.get(...).get(0)`：
|
||||
|
||||
- `getFirst(任意对象, "访问路径")` ➜ 返回根据路径匹配搜索到的第一个成员对象
|
||||
|
||||
只需书写符合规则的访问路径，不论什么类型和深度的成员，都可以一键直达：
|
||||
|
||||
```java
|
||||
// 返回parent对象中，所有符合类型是GrandChild的子对象中叫做content的成员对象
|
||||
OmniAccessor.get(parent, "{GrandChild}/content");
|
||||
// 将parent对象中，符合名称为children的数组第3位的任意子成员的value字段赋值为100
|
||||
OmniAccessor.set(parent, "children[2]/*/value", 100);
|
||||
```
|
||||
|
||||
具体路径规则如下：
|
||||
|
||||
**1. 匹配成员名**
|
||||
|
||||
不带额外修饰的路径名将匹配与之同名的任意成员对象
|
||||
|
||||
- `child`: 匹配任意名字为`child`的子孙成员
|
||||
- `child/grandChild`: 匹配名字为`child`的子孙成员里，名为`grandChild`的子成员
|
||||
|
||||
**2. 匹配成员类型**
|
||||
|
||||
使用花括号匹配类型名称，通常用于批量获取或赋值同类的多个成员对象
|
||||
|
||||
- `{Child}`: 匹配所有类型是`Child`的子孙成员
|
||||
- `{Children[]}`: 匹配所有类型是`Children`数组的子孙成员
|
||||
- `{Child}/{GrandChild}`: 匹配所有类型是`Child`的子孙成员里，所有类型是`GrandChild`子成员
|
||||
|
||||
成员名和类型可以在路径上混用，但暂不支持在同一级路径既指定成员名称又指定类型的写法
|
||||
|
||||
- `child/{GrandChild}`: 匹配名字为`child`的子孙成员里，所有类型是`GrandChild`的子成员
|
||||
- `{Child}/grandChild/content`: 匹配所有类型是`Child`的子孙成员里，名为`grandChild`子成员里的，名为`content`的子成员
|
||||
|
||||
**3. 使用下标访问数组成员**
|
||||
|
||||
使用带数值的方括号表示匹配该位置为数组类型，且取指定下标的对象（不带下标时，当匹配对象为数组类型，默认匹配数组中的所有对象）
|
||||
|
||||
- `children[1]/content`: 匹配名称为`children`的数组类型子孙成员，取其中第`2`个对象中名为`content`的子成员
|
||||
- `parent/children[1]`: 匹配名称为`parent`的子孙成员里，名为`children`的数组类型子成员，取其中第`2`个对象
|
||||
|
||||
**4. 使用通配符**
|
||||
|
||||
通配符可以用于成员名或类型名的匹配
|
||||
|
||||
- `child*`: 匹配名称以`child`开头的所有子孙成员
|
||||
- `{*Child}`: 匹配类型以`Child`结尾的所有子孙成员
|
||||
- `c*ld/{Grand*ld}`: 匹配名称以`c`开头`ld`结尾的子孙成员里，类型以`Grand`开头`ld`结尾的成员
|
||||
- `child/*/content`: 此时`*`将匹配任意成员，即`child`对象任意子成员中，包含的`content`子成员
|
||||
|
||||
详见`java-demo`和`kotlin-demo`示例项目`DemoOmniMethodsTest`测试类中的用例。
|
||||
|
||||
### 3. 特别说明
|
||||
|
||||
> **你真的需要用到`OmniAccessor`吗？**
|
||||
>
|
||||
> `OmniAccessor`具有基于Fail-Fast机制的防代码重构能力，当用户提供的访问路径无法匹配到任何成员时，`OmniAccessor`将立即抛出异常，使单元测试提前终止。然而相比常规的成员访问方式，`OmniAccessor`在IDE重构方面的支持依然偏弱。
|
||||
>
|
||||
> 对于复杂对象的内容赋值，大多数情况下，我们更推荐使用[构造者模式](https://developer.aliyun.com/article/705058)，或者暴露Getter/Setter方法实现。这些常规手段虽然稍显笨拙（尤其在需要为许多相似的成员批量赋值的时候），但对业务逻辑的封装和重构都更加友好。
|
||||
> 仅当原类型不适合改造，且没有其它可访问目标成员的方法时，`OmniAccessor`才是最后的终极工具。
|
||||
>
|
||||
> 出于相同的原因，虽然技术上可行，但我们并不推荐在除单元测试之外的场景使用`OmniAccessor`方式来读写业务类的成员字段。
|
||||
@ -1,6 +0,0 @@
|
||||
快速构造复杂入参
|
||||
---
|
||||
|
||||
不论被测方法所需的参数结构多么错综复杂、甚至没有合适的构造方法、甚至需要私有内部类对象... 呼唤TestableMock，马上递给您~
|
||||
|
||||
计划在`0.6`版本中推出。
|
||||
@ -5,31 +5,9 @@
|
||||
|
||||
此外，在单元测试中时常会需要对被测对象进行特定的成员字段初始化，但有时由于被测类的构造方法限制，使得无法便捷的对这些字段进行赋值。那么，能否在不破坏被测类型封装的情况下，允许单元测试用例内的代码直接访问被测类的私有方法和成员字段呢？`TestableMock`提供了两种简单的解决方案。
|
||||
|
||||
### 方法一：使用`@EnablePrivateAccess`注解
|
||||
### 1.1 使用`PrivateAccessor`工具类
|
||||
|
||||
只需为测试类添加`@EnablePrivateAccess`注解，即可在测试用例中获得以下增强能力：
|
||||
|
||||
- 调用**被测类**的私有方法（包括静态方法）
|
||||
- 读取**被测类**的私有字段（包括静态字段）
|
||||
- 修改**被测类**的私有字段（包括静态字段）
|
||||
- 修改**被测类**的常量字段（使用final修饰的字段，包括静态字段）
|
||||
|
||||
访问和修改私有、常量成员时，IDE可能会提示语法有误，但编译器将能够正常运行测试。（使用编译期代码增强，目前仅实现了Java语言的适配）
|
||||
|
||||
效果见`java-demo`示例项目`DemoPrivateAccessTest`测试类中的用例。
|
||||
|
||||
> 此功能默认假设测试类与被测类同包，且名称为`被测类+Test`。当不符合此约定时，可在测试类的`@EnablePrivateAccess`注解上使用`srcClass`参数指定实际的被测类。例如：
|
||||
>
|
||||
> ```java
|
||||
> @EnablePrivateAccess(srcClass = DemoServiceImpl.class)
|
||||
> class DemoServiceTest() { ... }
|
||||
> ```
|
||||
|
||||
### 方法二：使用`PrivateAccessor`工具类
|
||||
|
||||
若不希望看到IDE的语法错误提醒，或是在非Java语言的JVM工程（譬如Kotlin语言）里，可以借助`PrivateAccessor`工具类来直接访问私有成员。
|
||||
|
||||
这个类提供了7个静态方法：
|
||||
第一种方法是借助`PrivateAccessor`工具类来直接访问私有成员。这个类提供7个静态方法：
|
||||
|
||||
- `PrivateAccessor.get(任意对象, "私有字段名")` ➜ 读取任意类的私有字段
|
||||
- `PrivateAccessor.set(任意对象, "私有字段名", 新的值)` ➜ 修改任意类的私有字段（或常量字段）
|
||||
@ -39,12 +17,38 @@
|
||||
- `PrivateAccessor.invokeStatic(任意类型, "私有静态方法名", 调用参数...)` ➜ 调用任意类的**静态**私有方法
|
||||
- `PrivateAccessor.construct(任意类型, 构造方法参数...)` ➜ 调用任意类的私有构造方法
|
||||
|
||||
> 使用`PrivateAccessor`工具类并不需要测试类具有`@EnablePrivateAccess`注解，但加上此注解将开启被测类私有成员的编译期校验功能。
|
||||
详见`java-demo`和`kotlin-demo`示例项目`DemoPrivateAccessorTest`测试类中的用例。
|
||||
|
||||
详见`java-demo`和`kotlin-demo`示例项目`DemoPrivateAccessTest`测试类中的用例。
|
||||
### 1.2 防代码重构机制
|
||||
|
||||
### 私有成员编译期校验
|
||||
本质上来说，`PrivateAccessor`只是JVM反射机制的“易用型”封装，因此会存在与JVM反射相同的“对代码重构不友好”问题。当被测类中的私有方法名称、参数进行了修改，由于IDE无法自动订正反射访问的代码，往往相关错误要在单元测试运行时才能被发现。
|
||||
|
||||
上述两种私有成员访问功能的本质都是利用了JVM的反射机制，但JVM编译器不会检查反射目标的存在性，当代码重构时，如果对源类型中的私有方法名称、参数进行了修改，就会导致错误要在单元测试运行时才能被发现。为此，`@EnablePrivateAccess`注解的另一项功能是为**被测类**的私有成员访问进行额外的编译期校验。
|
||||
为此，`TestableMock`对`PrivateAccessor`进行了增强，赋予其编译期私有成员校验能力。这项功能默认关闭，需要通过`@EnablePrivateAccess`注解开启。（实际上是通过该注解的`verifyTargetOnCompile`参数控制，由于此参数默认值为`true`，因此只需在被测类上添加该注解即可启用私有成员校验）
|
||||
|
||||
**注意**：当私有成员校验功能开启时，`PrivateAccessor`工具类将只能用于访问**被测类**的私有成员，这会有助于限制将`PrivateAccessor`工具类用于与当前测试无关的“越权”操作。如果确实需要访问其他类的私有成员，可将`@EnablePrivateAccess`注解移除，或将注解的`verifyTargetOnCompile`参数设为`false`，手工关闭校验功能。
|
||||
**注意 1.**：当私有成员校验功能开启时，`PrivateAccessor`工具类将只能用于访问**被测类**的私有成员，从某种角度而言，这也有助于限制将`PrivateAccessor`工具类用于与当前测试无关的“越权”操作。
|
||||
|
||||
**注意 2.**：`TestableMock`默认约定测试类与**被测类**的包路径相同，且名称为`被测类+Test`。若测试类名称不符合此约定时，在使用`@EnablePrivateAccess`注解时，需用`srcClass`参数显式指明实际的**被测类**位置。
|
||||
|
||||
**注意 3**： 此机制目前只针对`Java`语言实现，对于`Kotlin`以及其他JVM方言均无效。
|
||||
|
||||
> 将`DemoPrivateAccessorTest`示例代码稍加修改，添加`@EnablePrivateAccess`注解（注意此时测试类名不符合约定，需加`srcClass`参数）：
|
||||
>
|
||||
> ```java
|
||||
> @EnablePrivateAccess(srcClass = DemoPrivateAccess.class) // <- 添加此行
|
||||
> class DemoPrivateAccessorTest() { ... }
|
||||
> ```
|
||||
>
|
||||
> 然后将任意一处通过`PrivateAccessor`访问的目标名称改为实际不存在的成员名，再次编译时即可发现该行有编译错误，提示信息为访问目标不存在。
|
||||
|
||||
### 2.1 直接访问私有成员
|
||||
|
||||
第二种方法，除了借助`PrivateAccessor`工具类以外，凡是使用了`@EnablePrivateAccess`注解的测试类还会被自动赋予以下“特殊能力”：
|
||||
|
||||
- 调用**被测类**的私有方法（包括静态方法）
|
||||
- 读取**被测类**的私有字段（包括静态字段）
|
||||
- 修改**被测类**的私有字段（包括静态字段）
|
||||
- 修改**被测类**的常量字段（使用`final`修饰的字段，包括静态常量字段）
|
||||
|
||||
访问和修改私有、常量成员时，IDE可能会提示语法有误，但编译器将能够正常运行测试。（使用编译期代码增强，目前仅实现了`Java`语言的适配）
|
||||
|
||||
效果见`java-demo`示例项目`DemoPrivateProcessorTest`测试类中的用例。
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
|
||||
- [快速Mock任意调用](zh-cn/doc/use-mock.md)：使被测类的任意方法调用快速替换为Mock方法，实现"指哪换哪"，解决传统Mock工具使用繁琐的问题
|
||||
- [访问被测类私有成员](zh-cn/doc/private-accessor.md)：使单元测试能直接调用和访问被测类的私有成员，解决私有成员初始化和私有方法测试的问题
|
||||
- [快速构造参数对象](zh-cn/doc/omni-constructor.md)：生成任意复杂嵌套的对象实例，并简化其内部成员赋值方式，解决被测方法参数初始化代码冗长的问题
|
||||
- [辅助测试void方法](zh-cn/doc/test-void-method.md)：利用Mock校验器对方法的内部逻辑进行检查，解决无返回值方法难以实施单元测试的问题
|
||||
- [快速构造参数对象](zh-cn/doc/parameter-constructor.md)：生成任意多层嵌套的对象实例，并简化其内部成员赋值方式，解决被测方法参数初始化代码冗长的问题
|
||||
|
||||
## 在Maven项目中使用
|
||||
|
||||
|
||||
@ -1,13 +1,31 @@
|
||||
升级到0.5版本
|
||||
版本升级说明
|
||||
---
|
||||
|
||||
经过近一个月的设计和开发，TestableMock的`0.5`版本终于和大家见面了。相比`0.4`版本，新版解决了此前遗留的三大历史问题：
|
||||
### 升级到0.6.x版本
|
||||
|
||||
在`0.6`版本中，`TestableMock`提供了[快速构造复杂参数对象](zh-cn/doc/omni-constructor.md)的能力，同时包含一处与`0.5`版本不兼容的修改，`PrivateAccessor`类型的包路径从`com.alibaba.testable.core.accessor`移到了`com.alibaba.testable.core.tool`。
|
||||
|
||||
例如在此前的测试代码中若使用了如下类型引用语句：
|
||||
|
||||
```java
|
||||
import com.alibaba.testable.core.accessor.PrivateAccessor;
|
||||
```
|
||||
|
||||
当升级`TestableMock`为`0.6`版本时，请将其修改为：
|
||||
|
||||
```java
|
||||
import com.alibaba.testable.core.tool.PrivateAccessor;
|
||||
```
|
||||
|
||||
### 升级到0.5.x版本
|
||||
|
||||
在`0.5`版本中，`TestableMock`解决了此前遗留的三大历史问题：
|
||||
|
||||
1. <s>**Mock方法无法调用其他非静态方法**</s>。新版中的Mock方法与普通方法不再有任何差别，可以访问任意外部方法和成员变量。
|
||||
2. <s>**Mock方法总是作用于整个测试生命周期**</s>。从现在开始，Mock方法支持将生效范围限定为**所属测试类里的测试用例**，不用担心跨类测试调用被意外Mock掉了。
|
||||
3. <s>**需手工清理MOCK_CONTEXT且只支持类粒度的并行测试**</s>。现在每个测试用例拥有了独立的`MOCK_CONTEXT`变量，无需清理也不会串号，而且可以放心使用**任意粒度**的并行单元测试啦。
|
||||
|
||||
在使用方式上，`0.5`版本延续`TestableMock`简洁轻量的原则，同时为了更好的实现Mock方法复用，新版本的Mock类与测试类之间有了明确的边界。从`0.4`版本升级到`0.5`时，唯一需要的改变是将测试类中的所有Mock方法使用一个`public static class Mock { }`包裹起来。
|
||||
在使用方式上，`0.5`版本延续了简洁轻量原则，同时为了更好的实现Mock方法复用，新版本的Mock类与测试类之间有了明确的边界。从`0.4`版本升级到`0.5`时，唯一需要的改变是将测试类中的所有Mock方法使用一个`public static class Mock { }`包裹起来。
|
||||
|
||||
例如，原先有如下测试类定义：
|
||||
|
||||
@ -46,4 +64,4 @@ public class DemoMockTest {
|
||||
}
|
||||
```
|
||||
|
||||
然后将`pom.xml`或`build.gradle`文件中的TestableMock依赖升级到`0.5.0`或以上版本即可。
|
||||
然后将`pom.xml`或`build.gradle`文件中的`TestableMock`依赖升级到对应的新版本即可。
|
||||
@ -3,13 +3,13 @@
|
||||
|
||||
相比以往Mock工具以类为粒度的Mock方式，`TestableMock`允许用户直接定义需要Mock的单个方法，并遵循约定优于配置的原则，按照规则自动在测试运行时替换被测方法中的指定方法调用。
|
||||
|
||||
> 归纳起来就两条：
|
||||
> 规则归纳起来就两条：
|
||||
> - Mock非构造方法，拷贝原方法定义到Mock容器类，加`@MockMethod`注解
|
||||
> - Mock构造方法，拷贝原方法定义到Mock容器类，返回值换成构造的类型，方法名随意，加`@MockContructor`注解
|
||||
|
||||
具体的Mock方法定义约定如下。
|
||||
|
||||
#### 0. 前置步骤，准备Mock容器
|
||||
### 0. 前置步骤，准备Mock容器
|
||||
|
||||
首先为测试类添加一个关联的Mock类型，作为承载其Mock方法的容器，最简单的做法是在测试类里添加一个名称为`Mock`的静态内部类。例如：
|
||||
|
||||
@ -23,7 +23,7 @@ public class DemoTest {
|
||||
}
|
||||
```
|
||||
|
||||
#### 1. 覆写任意类的方法调用
|
||||
### 1.1 覆写任意类的方法调用
|
||||
|
||||
在Mock容器类中定义一个有`@MockMethod`注解的普通方法，使它与需覆写的方法名称、参数、返回值类型完全一致，并在注解的`targetClass`参数指定该方法原本所属对象类型。
|
||||
|
||||
@ -69,7 +69,7 @@ private String substring(String self, int i, int j) {
|
||||
|
||||
完整代码示例见`java-demo`和`kotlin-demo`示例项目中的`should_mock_common_method()`测试用例。(由于Kotlin对String类型进行了魔改，故Kotlin示例中将被测方法在`BlackBox`类里加了一层封装)
|
||||
|
||||
#### 2. 覆写被测类自身的成员方法
|
||||
### 1.2 覆写被测类自身的成员方法
|
||||
|
||||
有时候，在对某些方法进行测试时，希望将被测类自身的另外一些成员方法Mock掉（比如这个方法里有许多外部依赖或耗时操作）。
|
||||
|
||||
@ -89,7 +89,7 @@ private String innerFunc(String text) {
|
||||
|
||||
完整代码示例见`java-demo`和`kotlin-demo`示例项目中的`should_mock_member_method()`测试用例。
|
||||
|
||||
#### 3. 覆写任意类的静态方法
|
||||
### 1.3 覆写任意类的静态方法
|
||||
|
||||
对于静态方法的Mock与普通方法相同。
|
||||
|
||||
@ -106,7 +106,7 @@ private BlackBox secretBox() {
|
||||
|
||||
完整代码示例见`java-demo`和`kotlin-demo`示例项目中的`should_mock_static_method()`测试用例。
|
||||
|
||||
#### 4. 覆写任意类的new操作
|
||||
### 1.4 覆写任意类的new操作
|
||||
|
||||
在Mock容器类里定义一个返回值类型为要被创建的对象类型，且方法参数与要Mock的构造函数参数完全一致的方法，名称随意，然后加上`@MockContructor`注解。
|
||||
|
||||
@ -125,7 +125,7 @@ private BlackBox createBlackBox(String text) {
|
||||
|
||||
完整代码示例见`java-demo`和`kotlin-demo`示例项目中的`should_mock_new_object()`测试用例。
|
||||
|
||||
#### 5. 在Mock方法中区分调用来源
|
||||
### 2. 在Mock方法中区分调用来源
|
||||
|
||||
在Mock方法中通过`TestableTool.SOURCE_METHOD`变量可以识别**进入该Mock方法前的被测类方法名称**；此外，还可以借助`TestableTool.MOCK_CONTEXT`变量为Mock方法注入“**额外的上下文参数**”，从而区分处理不同的调用场景。
|
||||
|
||||
@ -159,13 +159,14 @@ private Data mockDemo() {
|
||||
|
||||
完整代码示例见`java-demo`和`kotlin-demo`示例项目中的`should_get_source_method_name()`和`should_get_test_case_name()`测试用例。
|
||||
|
||||
#### 6. 验证Mock方法被调用的顺序和参数
|
||||
### 3. 验证Mock方法被调用的顺序和参数
|
||||
|
||||
在测试用例中可用通过`TestableTool.verify()`方法，配合`with()`、`withInOrder()`、`without()`、`withTimes()`等方法实现对Mock调用情况的验证。
|
||||
|
||||
详见[校验Mock调用](zh-cn/doc/matcher.md)文档。
|
||||
|
||||
#### 特别说明
|
||||
|
||||
### 4. 特别说明
|
||||
|
||||
> **Mock只对被测类的代码有效**
|
||||
>
|
||||
@ -173,7 +174,7 @@ private Data mockDemo() {
|
||||
>
|
||||
> 除去这种情况，若Mock未生效，请参考[自助问题排查](zh-cn/doc/troubleshooting.md)提供的方法对比<u>Mock方法签名</u>和<u>目标位置的调用方法签名</u>。若依然无法定位原因，欢迎提交Issues告诉我们。
|
||||
|
||||
> **测试类和Mock容器的命名约定**：
|
||||
> **测试类和Mock容器的命名约定**
|
||||
>
|
||||
> 默认情况下，`TestableMock`假设测试类与被测类的<u>包路径相同，且名称为`被测类名+Test`</u>（通常采用`Maven`或`Gradle`构建的Java项目均符合这种惯例）。
|
||||
> 同时约定测试类关联的Mock容器为<u>在其内部且名为`Mock`的静态类</u>，或<u>相同包路径下名为`被测类名+Mock`的独立类</u>。
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
- [使用TestableMock](zh-cn/doc/setup.md)
|
||||
- [快速Mock任意方法](zh-cn/doc/use-mock.md)
|
||||
- [直接访问私有成员](zh-cn/doc/private-accessor.md)
|
||||
- [快速构造复杂入参](zh-cn/doc/omni-constructor.md)
|
||||
- [测试无返回值的方法](zh-cn/doc/test-void-method.md)
|
||||
- [快速构造复杂入参](zh-cn/doc/parameter-constructor.md)
|
||||
|
||||
- 使用指南
|
||||
- [校验Mock调用](zh-cn/doc/invoke-matcher.md)
|
||||
@ -16,7 +16,7 @@
|
||||
- [使用Maven插件](zh-cn/doc/use-maven-plugin.md)
|
||||
|
||||
- 技术参考
|
||||
- [升级到0.5版本](zh-cn/doc/upgrade-to-v05.md)
|
||||
- [版本升级说明](zh-cn/doc/upgrade-guide.md)
|
||||
- [全局运行参数](zh-cn/doc/javaagent-args.md)
|
||||
- [注解参数清单](zh-cn/doc/annotations.md)
|
||||
- [Mock的设计和原理](zh-cn/doc/design-and-mechanism.md)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user