首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

Moco 框架以及其在 Web 集成测试的应用(3)

Moco 框架以及其在 Web 集成测试的应用(3)

Moco 高级用法在 Moco 里您还可以发现一些好玩的,或者说高级用法,比如 Asynchronous、Template。具体用法还是参考 Moco 的文档,这里仅以    Asynchronous 为例。
  • 编写配置文件
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    {
        "request": {
            "uri" : "/event"
        },
        "response": {
            "text": "event"
        },
        "on": {
            "complete": {
                "async" : "true",
                "post" : {
                    "url" : "http://another_site",
                    "content": "content"
                }
            }
        }
    }




  • 那么对于/event 的访问,将会是异步。
也就是说数据并不会立即返回,而是要等到对 http://another_siter 访问结束后,才会将结果放到 Response 里。
Moco 的 API 用法前面的这些用法在 Moco 里被称为"Standalone", 它强调的是 Moco 的简单性和可配置性,而 Moco 的 API 是它的另一个特色,它更加关注如何在测试用例里如何使用 Moco。
我们先看一个基于 Moco 的典型测试用例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import org.junit.Test;
import java.io.IOException;
import com.github.dreamhead.moco.HttpServer;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import com.github.dreamhead.moco.Runnable;

import static com.github.dreamhead.moco.Moco.*;
import static com.github.dreamhead.moco.Runner.*;
import static org.hamcrest.core.Is.is;
import static org.junit.Assert.assertThat;

@Test
public void should_response_as_expected() throws Exception {
    HttpServer server = httpserver(12306);
    server.response("foo");

    running(server, new Runnable() {
        @Override
        public void run() throws IOException {
            Content content = Request.Get("http://localhost:12306").execute().returnContent();
            assertThat(content.asString(), is("foo"));
        }
    });
}




上面的测试用例,描述了如何启动 Moco,以及调用相应的帮助方法来编写测试。
有时我们希望测试用例本身能够控制 Server 的启动和关闭,这里要用到@Before, @After 这些 Junit 里最常用的注释
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
import org.junit.After;
import org.junit.Before;
import org.junit.Test;

import java.io.IOException;

import static com.github.dreamhead.moco.Moco.httpserver;
import static com.github.dreamhead.moco.Runner.runner;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

public class MocoRunnerTest {
    private Runner runner;

    @Before
    public void setup() {
        HttpServer server = httpserver(12306);
        server.response("foo");
        runner = runner(server);
        runner.start();
        helper = new MocoTestHelper();
    }

    @After
    public void tearDown() {
        runner.stop();
    }

    @Test
    public void should_response_as_expected() throws IOException {
        Content content = Request.Get("http://localhost:12306").execute().returnContent();
        assertThat(content.asString(), is("foo"));
    }
}




Moco + Web 集成测试案例了解了 Moco 的具体使用方法,我们来看一个真实的基于 Moco 的案例,从而理解为什么 Moco 对于 Web 开发人员来说是革命性的!
用例:
在 Web 上调用 Ajax 获取服务器端的版本(version)号,并根据返回的值显示不同的提示信息。
分析:
其实面对这样的需求,我们很容易看出这个用例本身,关注的是"显示不同的提示信息"这个功能,至于返回的 version 值,用户根本不必关心或者说这属于系统内部的逻辑。
我们先来看看以前的做法
  • 安装并配置好 Web Server (Tomcat or Apache)
  • 建立必要的 Web 工程文件,导入与项目相关的框架,比如 struts2
  • 如果底层系统是 Java 本身,需要导入或者编译相关的 jar 文件,如果底层用其他的语言开发,就需要步骤 4
  • 搭建底层开发环境或者在编译机器上编译 Lib 或者 so 文件,在确保能够运行的情况下(需要测试脚本)并导入到项目当中
  • 发布 Web 应用并测试,如果底层 API 有变动或者方法调用错误,需要再次运行步骤 4。
  • 编写并测试 Ajax 逻辑。
那么我们看看基于 Moco 的开发步骤会是什么样的:
  • 编写配置文件, 这里要用到刚才说的同步方法
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    [
    {
    "env" : "remote",
    "include": "foo.json",
    },
    {
    "env" : "local",
    "include": "bar.json",
    }
    ]




  • 启动 Moco 服务
    1
    java -jar moco-runner-<version>-standalone.jar start -p 12306 -g env.json -e remote




    在很多时候,我们往往将时间浪费在步骤 3,4 中,即使已经有编译好的 Lib 或者 so,还是存在着测试的必要和风险。Web 的开发人员一方面要完成自己开发任务,另一方面还要扮演底层代码测试员角色。
  • 编写 Web 应用,调用 ajax 请求Moco 让开发人员更关注应用本身,而不必将时间和精力花费在 Lib 或者 so 的可用性上,而且没有复杂的 Web 容器配置,关注的就是切实的功能本身。
同时,它的 API 有利于 Web 开发者编写测试用例,将以前部门之间的无效沟通,建立在可度量的测试用例之上,从而提高了 Web 集成测试的可靠性,并有效地降低了集成测试的风险!
返回列表