史上最高性能!穆萨新式程序代码Mock辅助工具开放源码_chan_

TestableMock是如前所述源标识符和二进制码进一步增强的Java程序标识符辅助基本操作，包涵下列机能：

出访被测类专有核心成员：使程序标识符能间接调用和出访被测类的专有核心成员，化解专有核心成员调用和专有方式试验的难题加速Mock任一调用：使被测类的任一方式调用加速代替为Mock方式，实现"指哪换哪"，化解传统Mock基本操作采用繁琐的难题辅助试验void方式：利用Mock奇偶校验器对方式的内部逻辑展开检查，化解无codice方式无法实施程序标识符的难题

出访专有核心成员表头和方式

如今关于专有方式是否应该做程序标识符的争论正逐渐停息，开发人员的普遍实践已经给出事实答案。通过公有方式间接测专有方式在很多情况下无法展开，开发人员们更愿意通过修正方式可见性的办法来让原先专有的方式在试验示例中变得可测。

此外，在程序标识符中时常会需要对被测第一类展开特定的核心成员表头调用，但有时由于被测类的构造方式限制，使得无法便捷的对这些表头展开赋值。那么，能否在不破坏被测类别PCB的情况下，容许程序标识符示例内的标识符间接出访被测类的专有方式和核心成员表头呢？TestableMock提供了两种简单的化解方案。

方式一：采用@EnablePrivateAccess注释

只需为试验类添加@EnablePrivateAccess注释，即可在试验示例中赢得下列进一步增强能力：

调用被测类的专有方式（主要包括动态方式）加载被测类的专有表头（主要包括动态表头）修正被测类的专有表头（主要包括动态表头）修正被测类的自变量表头（采用final修饰的表头，主要包括动态表头）

出访和修正专有、自变量核心成员时，IDE可能会提示语法有误，但C++将能够正常运转试验。（采用编译期标识符进一步增强，目前仅实现了Java词汇的网络连接）

效果见java-demo实例项目DemoPrivateAccessTest试验类中的示例。

方式二：采用PrivateAccessor基本操作类

若不期望看到IDE的错别字提醒，或是在非Java词汇的JVM工程（譬如Kotlin词汇）里，也能借助PrivateAccessor基本操作Canillac间接出访专有核心成员。

这个类提供了6个动态方式：

PrivateAccessor.get(被测第一类, "专有表头名")➜ 加载被测类的专有表头PrivateAccessor.set(被测第一类, "专有表头名", 捷伊值)➜ 修正被测类的专有表头（或自变量表头）PrivateAccessor.invoke(被测第一类, "专有方式名", 调用模块..)➜ 调用被测类的专有方式PrivateAccessor.getStatic(被测类别, "专有动态表头名")➜ 加载被测类的动态专有表头PrivateAccessor.setStatic(被测类别, "专有动态表头名", 捷伊值)➜ 修正被测类的动态专有表头（或动态自变量表头）PrivateAccessor.invokeStatic(被测类别, "专有动态方式名", 调用模块..)➜ 调用被测类的动态专有方式

加速Mock被测类的任一方式调用

相比以往Mock基本操作以类为发射率的Mock方式，TestableMock容许用户间接表述需要Mock的单个方式，并遵循签订合同优于配置的原则，按照规则手动在试验运转时代替被测方式中的指定方式调用。

简而言之就两条：
Mock非构造方式，复本原方式表述到试验类，减少两个与调用者类别相同的模块，加@MockMethod注释Mock构造方式，复本原方式表述到试验类，codice改成构造的类别，方式名随便，加@MockContructor注释

具体的Mock方式表述签订合同如下表所示：

1.抹除任一类的方式调用

在试验类里表述两个有@MockMethod注释的普通方式，使它与需抹除的方式名称、模块、codice类别完全一致，然后在其模块条目第一位再减少两个类别为该方式原先所属第一类类别的模块。

此时被测类中所有对该需抹除方式的调用，将在程序标识符运转时，将手动被代替为对上述自表述Mock方式的调用。

注意：当遇到待抹除方式有下文时，能将需抹除的方式名写到@MockMethod注释的targetMethod模块里，这样Mock方式自身就能随便命名了。

例如，被测类中有一处"anything".substring(1, 2)调用，我们期望在运转试验的时候将它改成两个固定字符串，则只需在试验类表述如下表所示方式：

// 原方式亲笔签名为`String substring(int, int)` // 调用此方式的第一类`"anything"`类别为`String` // 则Mock方式亲笔签名在其模块条目第一位减少两个类别为`String`的模块（名字随便） // 此模块可用于赢得当时的实际调用者的值和语句 @MockMethod private String substring(String self, int i, int j) { return "sub_string"; }

下面这个例子展示了targetMethod模块的用法，其效果与上述实例相同：

// 采用`targetMethod`指定需Mock的方式名 // 此方式本身现在能随便命名，但方式模块依然需要遵循相同的匹配规则 @MockMethod(targetMethod = "substring") private String use_any_mock_method_name(String self, int i, int j) { return "sub_string"; }

完整标识符实例见java-demo和kotlin-demo实例项目中的should_able_to_mock_common_method()试验示例。(由于Kotlin对String类别展开了魔改，故Kotlin实例中将被测方式在BlackBox类里加了一层PCB)

2.抹除被测类自身的核心成员方式

有时候，在对某些方式展开试验时，期望将被测类自身的另外一些核心成员方式Mock掉。

操作方式与前一种情况相同，Mock方式的第两个模块类别需与被测类相同，即可实现对被测类自身（不论是公有或专有）核心成员方式的抹除。

例如，被测类中有两个亲笔签名为String innerFunc(String)的专有方式，我们期望在试验的时候将它代替掉，则只需在试验类表述如下表所示方式：

// 被测类别是`DemoMock` // 因此在表述Mock方式时，在目标方式模块第一位加两个类别为`DemoMock`的模块（名字随便） @MockMethod private String innerFunc(DemoMock self, String text) { return "mock_" + text; }

3. 抹除任一类的动态方式

对于动态方式的Mock与普通方式相同。但需要注意的是，动态方式的Mock方式被调用时，传入的第两个模块实际值始终是null。

例如，在被测类中调用了BlackBox类别中的动态方式secretBox()，改方式亲笔签名为BlackBox secretBox()，则Mock方式如下表所示：

// 目标动态方式表述在`BlackBox`类别中 // 在表述Mock方式时，在目标方式模块第一位加两个类别为`BlackBox`的模块（名字随便） // 此模块仅用于标识目标类别，实际传入值将始终为`null` @MockMethod private BlackBox secretBox(BlackBox ignore) { return new BlackBox("not_secret_box"); }

完整标识符实例见java-demo和kotlin-demo实例项目中的should_able_to_mock_static_method()试验示例。

试验无codice的方式

如何对void类别的方式展开试验一直是许多程序标识符框架在悄悄回避的话题，由于以往的程序标识符手段主要是对被测单元的返回结果展开奇偶校验，当遇到方式没有codice时就会变得无从下手。

从机能的角度来说，虽然void方式不返回任何值，但它的执行一定会对外界产生某些潜在影响，我们将其称为方式的"副作用"，比如：

调用某些外部变量（专有核心成员变量或者全局动态变量）在方式体内对外部第一类实例展开赋值输出了日志调用了其他外部方式… …不返回任何值也不产生任何"副作用"的方式没有存在的意义。

这些"副作用"的本质归纳来说可分为两类：修正外部变量和调用外部方式。

通过TestableMock的专有表头出访和Mock奇偶校验器能很方便的实现对"副作用"的结果检查。

1. 修正外部变量的void方式

例如，下面这个方式会根据输入修正专有核心成员变量hashCache：

class Demo { private Map<String, Integer> hashCache = mapOf(); public void updateCache(String domain, String key) { String cacheKey = domain + "::" + key; Integer num = hashCache.get(cacheKey); hashCache.put(cacheKey, count == null ? initHash(key) : nextHash(num, key)); } ... // 其他方式省略 }

若要试验此方式，能利用TestableMock间接加载专有核心成员变量的值，对结果展开奇偶校验：

@EnablePrivateAccess// 启用TestableMock的专有核心成员出访机能 class DemoTest { private Demo demo = new Demo(); @Test public void testSaveToCache() { Integer firstVal = demo.initHash("hello"); // 出访专有方式 Integer nextVal = demo.nextHash(firstVal, "hello"); // 出访专有方式 demo.saveToCache("demo", "hello"); assertEquals(firstVal, demo.hashCache.get("demo::hello")); // 加载专有变量 demo.saveToCache("demo", "hello"); assertEquals(nextVal, demo.hashCache.get("demo::hello")); // 加载专有变量 } }

2. 调用外部方式的void方式

例如，下面这个方式会根据输入打印信息到控制台：

class Demo { public void recordAction(Action action) { SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss "); String timeStamp = df.format(new Date()); System.out.println(timeStamp + "[" + action.getType() + "] " + action.getTarget()); } }

若要试验此方式，能利用TestableMock加速Mock掉System.out.println方式。在Mock方式体里能继续执行原调用（相当于并不影响本来方式机能，仅用于做调用记录），也能间接留空（相当于去除了原方式的副作用）。

在执行完被测的void类别方式以后，用InvokeVerifier.verify()奇偶校验传入的打印内容是否符合预期：

class DemoTest { private Demo demo = new Demo(); // 拦截`System.out.println`调用 @MockMethod public void println(PrintStream ps, String msg) { // 执行原调用 ps.println(msg); } @Test public void testRecordAction() { Action action = new Action("click", ":download"); demo.recordAction(); // 验证Mock方式`println`被调用，且传入模块符合预期 verify("println").with(matches("\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} \[click\] :download")); } }