JMockit 如何 Mock 部分方法/属性

2016-05-17 | 阅读(2,708)

现在的 JMockit 已经偷偷升级到了 1.23 版了，在 JVM 上的 Mock 工具中就数它最无敌了，因为它抢夺了最佳控制点  --javaagent，可以说它是无所不能的。一般我们使用 JMockit 是通过两种方式，new MockUp 和 new Expectations. JMock 不仅能够 Mock 类的所有方法，还能部分 Mock -- 这个是 new Expectations 的默认行为。所以这里我们来看下在使用 new Expectations 的情况下如何对类的部份静态方法或部分实例方法进行 Mock。

大致表述一下，共分为三种情况

  1. 针对类进行 Mock, 只有录制的静态方法被 Mock 住，其他的静态方法或实例方法都会调用实际实现
  2. 针对某一实例进行 Mock，只在调用该实例已录制的方法才被 Mock 住，静态方法或新建实例调用任何方法都是实际实现
  3. 针对类进行 Mock，但录制的是一个实例方法，那么该实例或任何新建实例在调用该录制方法时都会被 Mock 住

不知道上面在说什么，本来就是空洞无凭，所以还是下实例，假定要测试下面这个类，或者说是测试使用到下面类的其他类 阅读全文 >>

sbt 最简单的带输入任务 inputTask

2016-05-17 | 阅读(373)

在 sbt 中我们可以定义 settingKey, taskKey 和 inputKey. inputKey 接收输入的任务更具灵活性，虽然在 sbt 中 taskKey 和  inputKey 数量比例为 25:1，但仍然不可忽视了 inputKey 的贡献。

起初在阅读 sbt 关于 inputKey 的资料时，一不小心就被带入到 Parser 上去了。其实还不如开门见山，先跳过 Parser 部份，示范 inputKey 任务中直接处理用户的原生输入。

这里有两个最简单的 sbt inputKey 的示例

一. 命令后非空格起全部输入当作一个字符串

trimmed() 方法能去除了两边的空格，如果是 token(any.* map(_.mkString)).parse 则两边空格都会算上，在 demo1 abc  的 abc 两边的空格也都会算在输入参数里

> demo1 abc "abc"
abc "abc"

sbt  的  input task  参数居然默认是紧接着命令开始的，如上面如果输入是 demo1xxx, demo1 任务接收到的参数是 xxx. 如果同时也定义了另一个任务是 demo1x, 那么输入 demo1xx 就会执行 demo1x 任务，参数是 xx. 从后往前进行匹配任务名。这个还有点奇怪，因为我以前任何时候都是自然的把命令与参数用空格分开，它却可以把命令与参数写在一起。

 

二. 像调用 main 方法一样传入参数

阅读全文 >>

Scala 和 Java 的集合类型相互转换

2016-05-08 | 阅读(4,399)

在 Scala 和 Java 混合编程时免不了需要进行集合类型在两种语言间相互转换，更多的是在 Scala 调用 Java 的方法时把 Scala 的集合转型为 Java 的集合。典型场景是：

public void process(java.util.List<String> orderIds) {
  ......
}

上面定义的 Java 方法，如果要在 Scala 中调用它，不考虑两种语言的集体类型转换的话，可以直接传入 Java 代码要求的类型，像这样

val orderIds = new java.util.ArrayList[String]
orderIds.add("SJ001")
process(orderIds)

这样当然可以，但不能享受到 Scala 语言中集合使用的便利性，如快捷的构造，丰富的怪异的方法(++, ::, ## 等)。所以希望此时 Scala 中调用 process()  能接近这种方法

process(List("SJ001", "SJ002"))

特别是当 Java 接受一个 java.util.Map 时，能在 Scala 里直接传入 Map("key1" -> "value1",  "key2" -> "value2") 就方便许多。

用方法来完成 Scala 和 Java 间对应集合类型的转换当然没问题，但别忘了 Scala 还支持隐式转换，那就是只要在 Scala 代码中引入 collection.JavaConversions._ 对于上面的方法在 Scala 中就可以直接传入 Scala 的 List() 了。也就是 阅读全文 >>

让 Scala 测试方法名中的空格不再显示为 $u0020

2016-05-07 | 阅读(186)

在 Scala 中借助于斜撇号我们可以使用关键字或任何字符为作为变量或方法名，例如下面的方法都是合法的：

scala> def if: Unit = {}
if: Unit

scala> def 我是谁?: Unit = {}
我是谁$qmark: Unit

scala> def just do it: Unit = {}
just$u0020do$u0020it: Unit

对了，Scala 2.11.6 在显示有些字符时会进行编码，像上面的 ? 和 空格。而用 2.11.7 的 Scala  控制台下居然原样显示，不编码(这是在进一步试难时发现的)。

我们在用 Scala 写 JUnit 风格的单元测试, 由于 JUnit 不支持像 TestNG 那样在方法名上加描述，所以方法名必须完成自我描述。依照严格的方法命名的话，势必要用驼峰方式或下划线把单词分开，如

def getOneHunderIfSixtyPlusFouty: Unit = { ... }
def get_one_hunder_if_sixty_plus_forty: Unit = { ... }

注：如果用 Scala 写 Spec 测试代码另当别论，因为有些情况下必须用 JUnit 风格(就用 JMockit 时) 阅读全文 >>

Google Guice 轻装上阵

2016-04-26 | 阅读(536)

PlayFramework 已全面向 Google Guice 演进, 由于我们的项目是从 Play 2.0 开始搭建, 现虽已升级到了 2.4.6, 但对 Guice 的还没抱得那么的紧, 有点积重而慢步前挪. Google Guice 也是一个依赖注入(DI) 容器, 据说它比 Spring 快了很多很多, 是轻量级项目或框架首选, Google 出品俱是精品.

既然它是轻量级的 DI, 那么必须呈上一个最轻量级的入门, 官方的 Get Started 文档其实啰嗦了点, 对于 BillingService 依赖的 CreditCardProcess, TransactionLog, 和 Receipt 都未有交待, 算不上一个完整项目. 所以我这里尽量简化, 又不偏离一个最简单的项目模型. 那就是下面那个例子, 它实现了在不同时间发出不同的问候.

项目需要依赖 Guice 及它的子依赖, 这得看你是用什么来管理依赖的, 依照 http://mvnrepository.com/artifact/com.google.inject/guice/4.0 根据实际情况加上依赖配置, 前面这个链接默认为 sbt 的, 我还真偏爱了 sbt, 若是 Maven 就配置 Maven 的 pom.xml 吧. Guice 的引入带上以下几个依赖包

   +-com.google.inject:guice:4.0
     +-aopalliance:aopalliance:1.0
     +-com.google.guava:guava:16.0.1
     +-javax.inject:javax.inject:1

Guice 目前是 4.0. 阅读全文 >>

sbt 任务间的依赖

2016-04-23 | 阅读(256)

项目中的 build.sbt 中发现定义任务时有 task2 <<= task1 map {...} 这样任务依赖的写法, 这个  <<= 方法有点晦涩难懂, 读过 sbt in action 之后才知道这是 sbt 0.12 或之前的做法, sbt 0.13 之后不这么用了, 直接访问下 task1.value 就行, 因此前面可改写为 task2 := {task1.value; ...}, 这也使得定义任务依赖时与普通任务一致风格了. 新的写法得益于 Scala 2.10 的宏特性, 后面还会讲到.

对于依赖于多个任务的情况, 在 sbt 0.13 前面分别是这样的, 假定有三个 Task(task1, task2, 和 task3)

val task1 = taskKey[Int]("task 1")
val task2 = taskKey[Int]("task 2")
val task3 = taskKey[Int]("task 3")

如果 task3 依赖于 task1 和 task 2

sbt 0.13 前后版本中的写法分别是

像任务的 .value 属性其实是一个宏定义, 源码 阅读全文 >>

ScalaTest + Selenium 集成测试

2016-04-20 | 阅读(561)

在 Play 1 和 Play 2 中都内置了 Selenium 集成测试工具, 这里自己尝试自己单独测试用 ScalaTest + Selenium 来做简单的集成测试. Selenium 可以支持内置的无界面 Java 实现的浏览器, 也可以用外部浏览器, 如 Safari, Firefox, Chrome, IE, Opera 或移动设备的浏览器. 使用不同外部浏览的方式或用插件(Safari/Firefox 等) 或是像借助于 Chromium 来驾驭 Chrome 浏览器.

而我们这里要用的 ScalaTest 2.2.6 在包 org.scalatest.selenium 有以下几个特质 Chrome, Driver, Firefox, HtmlUnit, InternetExplorer, Page, Safari 和  WebBrowser. 由此可以看出 ScalaTest 默认支持的浏览器. 若单论 Selenium 本身, 它可强大的暂时超乎我的想像, 可以自建服务器, 选择浏览器分发测试任务. 我们知道使用 Selenium 的好处是不光可以像通常那样断言页面静态文本, 还能执行 Javascript 脚本, 所以可断言动态内容.

本人开发环境为 Mac OS, 可以成功让 Selenium 测试跑在内置 Java 浏览器, 和外置的  Safari, Chrome 浏览器中, Firefox 的插件未安装成功.

让事实说话, 仍然让一个最简单的例子自己说话, 创建的是一个 sbt 项目, 尽量把目录最简化, 只有 build.sbt 文件和 test/IntegrationTest.scala 测试代码, 内容分别为 阅读全文 >>

建立 Play 2 框架一样的目录布局

2016-04-15 | 阅读(384)

sbt 项目继承并扩展了 Maven 的默认项目布局, 加入了 Scala 代码的支持, 所以目录如 Shell 命令 mkdir -p src/{main,test}/{java,scala,resources} 生成的目录结构, 即

.
└── src
    ├── main
    │   ├── java
    │   ├── resources
    │   └── scala
    └── test
        ├── java
        ├── resources
        └── scala

这个目录目录虽然很清晰, 但把 Java 和 Scala 代码拆在两处没多大必要, 其次是层次多了点. 因使用 Play Framework 时日有点久了, 比较习惯于 Play 2 改造后的项目布局. 我们启动到 Play 2 的 activator(其实就是加入了定制的 sbt) 控制台, 用命令看它的目录布局 阅读全文 >>

sbt 中单元测试并发执行

2016-04-13 | 阅读(985)

此次研究的目的原本是要使得 Play Framwork 2 中单元测试能够并发执行, 包括 JUnit 和 Spec 的测试用例, Play 2 的 activator 就是一个 sbt 的包装. 开发中发现我们 Play 2 中的单元测试是按序执行的, 实际上 sbt 下测试用例默认是并发执行的. 之所以 Play 2 的单元测试是按序的, 是因为 activator 设置了把 sbt 的两个属性 fork in Test := true 和 parallelExecution in Test := false, 见 PlaySettings.scala, 它们默认分别为 false 和 true. 这使得默认设置下 Play 2 中的所有测试无法并发执行.

sbt 默认的 fork 是 false, Play 2 改为 true 之后便可以使用 javaOptions in Test := "-Dkey1=value1" (注: 如果 fork 为 false 的话, javaOptions 将无效.) 往单元测试中参数了, 这也是为什么在 Play 2 的单元测试中无法获得启动 sbt 时(像 sbt -Dkey1=value) 的参数, 不同一个 JVM 啊.

那是不把 Play 2 的 fork in Test 和 parallelExecution in Test 分别改回成 false 和 true 就可以让测试用例并发执行了呢? 答案是 Yes. 但我们得相信 Play 2 把它们预设为 true 和 false 是有它的用意的, 比如集成测试的每个用例都会开启本地的 3333 端口, 如果让两个集成测试同时执行将会造成端口冲突. 细致说来, Play 2 其实是懒政, 只管一刀切而让所有测试按序执行而影响了效率, 如能利用好 sbt 的测试分组机制是可以达到测试的并发执行的.

这里引出 sbt 执行测试的几个机制:

1) sbt 总是对测试进行分组, 默认时所有的测试都包含在 <default> 组中, 可用 show testGrouping 查看, 如

阅读全文 >>

查看 sbt 项目的依赖关系树

2016-04-05 | 阅读(3,543)

sbt 是借助于 ivy 来管理项目依赖, 像 Maven 项目中可以用 dependency:tree 来显示依赖树, 那么对于 sbt 项目该如何查看项目依赖关系呢? 本文提及了三种方式来显示项目依赖, 它们是 Shell 脚本, 自定义 sbt 任务, 和 sbt-dependency-plugin 方式. 最后一个办法使得我们也能用 dependencyTree 显示出 Maven 的  dependency:tree 效果来, 还有更酷的的.

> dependencyTree
[info] default:test_2.10:0.1-SNAPSHOT [S]
[info]   +-ch.qos.logback:logback-classic:1.0.13
[info]     +-ch.qos.logback:logback-core:1.0.13
[info]     +-org.slf4j:slf4j-api:1.7.5
[info]
[success] Total time: 0 s, completed Apr 5, 2016 12:29:53 AM

下面是探索的全部过程.

通过 sbt 控制台的 tab  自动完成或用 help .*[Dd]ependenc.* 命令再进一步过滤出与依赖比较接近 sbt 控制台任务 阅读全文 >>