Test

javascript unit test http://blog.sina.com.cn/s/blog_6768f2290100ubw5.html 最近由于工作和个人兴趣的关系，有幸研究了一下javascript的unit test，市面上常见且比较易用的javascript的unit test的framework有三个: jsunit, qunit和yuitest，虽然出处不同，但是本质上，使用方法都大同小异。 jsunit: http://www.jsunit.net/ 最早开发自2001年，是第一个实用的javascript的unit test framework (那时候TDD还远未流行) ，其完全遵循junit的xunit pattern, 有setup, teardown, 有testsuit概念，还有若干种assert方法，不过因为其诞生早，对非同步的ajax测试支持不够，因而有市场占有率渐低的趋势。 qunit: http://docs.jquery.com/Qunit 个人极其欣赏的一个framework，隶属于大名鼎鼎的jquery，但是又无需依赖于jquery的库可单独运行, 方法轻量易学，且具有异步测试的功能。可惜在公司没有被官方支持，只能自己玩。 yui test: http://developer.yahoo.com/yui/yuitest/ 著名的yahoo web js toolkit library中的ut子项目，使用方法和qunit极其相似，也具有异步测试功能，在本人公司被官方支持，最大的缺点是使用时要调用其他诸多的yui模块用来显示结果，不够独立。 以下以qunit为例子，介绍这些unit test framework的使用方法: 1 ) 下载qunit的测试驱动程序js文件和对应显示结果用的css文件 (分别为qunit.js 和qunit.css ) 2 ) 将这两个文件保存在某个目录，并在同一目录建立一个简单的html文件，包含该两个文件以及jquery.js 3 ) 将我们需要测试的js代码的文件也包含入该简单html中(该例中为mycode.js)。 4 ) 将我们要测试的js代码的依赖库也加入该html中(如ExtJS或者其他库) 5 ) 在html中添加script的测试代码 (test suit和assert部分) 6 ) 在浏览器中载入该html文件，页面会自动显示运行结果。 值得一提的是，网上有qunit-CLI的项目，其用rhino解释器来代替浏览器做unit test js的运行环境，提高了测试的效率，有兴趣的朋友可以去google搜索看看。 代码如下: mycode.js function (a, b) { return a + b; } test.html <html> <head> <script src="http://code.jquery.com/jquery-latest.js"></script> <script type="text/javascript" src="qunit.js"></script> <!-- js to be tested --> <script type="text/javascript" src="mycode.js"></script> <!-- unit test part --> <script> $(document).ready(function(){ test("a basic test example", function() { var sum = add (1 + 1); equal( sum, "2", "We expect value to be 2" ); }); }); </script> </head> <body> QUnit example test markup, will be hidden </ 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

Mockito 部分mock (partial mock) 部分mock是说一个类的方法有些是实际调用，有些是使用mockito的stubbing (桩实现) 。 为什么需要部分mock 当需要测试一个组合方法 (一个方法需要其它多个方法协作) 的时候，某个叶子方法 (只供别人调用，自己不依赖其它反复) 已经被测试过，我们其实不需要再次测试这个叶子方法，so，让叶子打桩实现返回结果，上层方法实际调用并测试。 mockito实现部分mock的两种方式: spy和 callRealMethod() spy的原理是，如果不打桩默认都会执行真实的方法，如果打桩则返回桩实现。可以看出spy.size()通过桩实现返回了值100，而spy.get(0)则返回了实际值 List<String> list = new LinkedList<String>(); List<String> spy = spy(list); when(spy.size()).thenReturn(100); spy.add("one"); spy.add("two"); assertEquals(spy.get(0), "one"); assertEquals(100, spy.size()); Channel channel = mock(Channel.class); when(channel.writeAndFlush(obj)).thenReturn(null); // 重置 spy 对象，让 add(1,2) 调用真实方法，返回 3 when(exampleService.add(1, 2)).thenCallRealMethod(); Assert.assertEquals(3, exampleService.add(1, 2)); 一、什么是mock测试，什么是mock对象？ 一种替代方案就是使用mocks 从图中可以清晰的看出 mock对象就是在调试期间用来作为真实对象的替代品。 mock测试就是在测试过程中，对那些不容易构建的对象用一个虚拟对象来代替测试的方法就叫mock测试。 知道什么是mock测试后，那么我们就来认识一下mock框架—Mockito 二、什么是Mockito 除了有一个好记的名字外，Mockito尝试用不一样的方法做mocking测试，是简单轻量级能够替代EasyMock的框架。使用简单，测试代码可读性高，丰富的文档包含在javadoc中，直接在IDE中可查看文档，实例，说明。更多信息: http://code.google.com/p/mockito/ ...

DbUnit http://yangzb.iteye.com/blog/947292 博客分类: QC 单元测试XML数据结构OraclePostgreSQL 相信做过单元测试的人都会对JUnit 非常的熟悉了,今天要介绍的DbUnit(http://dbunit.sourceforge.net/ ) 则是专门针对数据库测试的对JUnit 的一个扩展,它可以将测试对象数据库置于一个测试轮回之间的状态。鉴于目前国内介绍DbUnit 的系统教程比较少见,本文将分从理论和实例两个方面带你领略DbUnit 的精彩世界。 DbUnit 设计理念 熟悉单元测试的开发人员都知道,在对数据库进行单元测试时候,通常采用的方案有运用模拟对象(mock objects)和stubs 两种。通过隔离关联的数据库访问类,比如JDBC 的相关操作类,来达到对数据库操作的模拟测试。然而某些特殊的系统,比如利用了EJB 的CMP(container-managed persistence) 的系统,数据库的访问对象是在最底层而且很隐蔽的,那么这两种解决方案对这些系统就显得力不从心了。 DBUnit 的设计理念就是在测试之前,备份数据库,然后给对象数据库植入我们需要的准备数据,最后,在测试完毕后,读入备份数据库,回溯到测试前的状态； 而且又因为DBUnit 是对JUnit 的一种扩展,开发人员可以通过创建测试用例代码,在这些测试用例的生命周期内来对数据库的操作结果进行比较。 DbUnit 测试基本概念和流程 基于DbUnit 的测试的主要接口是IDataSet 。IDataSet 代表一个或多个表的数据。 可以将数据库模式的全部内容表示为单个IDataSet 实例。这些表本身由Itable 实例来表示。 IDataSet 的实现有很多,每一个都对应一个不同的数据源或加载机制。最常用的几种 IDataSet 实现为: FlatXmlDataSet : 数据的简单平面文件 XML 表示 QueryDataSet : 用 SQL 查询获得的数据 DatabaseDataSet : 数据库表本身内容的一种表示 XlsDataSet : 数据的excel 表示 一般而言,使用DbUnit 进行单元测试的流程如下: 1 根据业务,做好测试用的准备数据和预想结果数据,通常准备成xml 格式文件。 2 在setUp() 方法里边备份数据库中的关联表。 3 在setUp() 方法里边读入准备数据。 4 对测试类的对应测试方法进行实装: 执行对象方法,把数据库的实际执行结果和预想结果进行比较。 ...

Go unit test, 单体测试 执行某一个测试文档 go test foo_test.go go test -v foo_test.go // 强制 go test 运行一次，不使用缓存, 在配置了 -count 参数的情况下，go test 会忽略缓存 // -count, 执行测试的次数 go test -count=1 foo_test.go # 执行某一个文件中的某一个或几个函数 go test path/to/foo_test.go -run "^TestFunc0$" go test 会默认缓存测试运行的结果（Test Cache），缓存判断的依据是： 测试本身的代码（如 *_test.go 文件） 测试依赖的源文件是否发生变更 测试的相关环境参数是否发生变化（环境变量、命令参数等） Go 语言推荐测试文件和源代码文件放在一块，测试文件以 _test.go 结尾。比如，当前 package 有 calc.go 一个文件，我们想测试 calc.go 中的 Add 和 Mul 函数，那么应该新建 calc_test.go 作为测试文件。 calc_test.go package main import "testing" func TestAdd(t *testing.T) { t.Log("test foo") if ans := Add(1, 2); ans != 3 { t.Errorf("1 + 2 expected be 3, but %d got", ans) } if ans := Add(-10, -20); ans != -30 { t.Errorf("-10 + -20 expected be -30, but %d got", ans) } } 测试用例名称一般命名为 Test 加上待测试的方法名。 测试用的参数有且只有一个, 在这里是 t *testing.T ...

测试覆盖 传统的测试覆盖方法常见的有以下几种: 函数覆盖 (Function Coverage) 语句覆盖 (Statement Coverage) 决策覆盖 (Decision Coverage) 条件覆盖 (Condition Coverage) 还有一些其他覆盖方法,如Modified Condition/Decision Coverage,就不在这里讨论了。 函数覆盖: 顾名思义,就是指这个函数是否被测试代码调用了。以下面的代码为例,对函数foo要做到覆盖,只要一个测试——如assertEquals(2, foo(2, 2))——就可以了。如果连函数覆盖都达不到,那应该想想这个函数是否真的需要了。如果需要的话,那又为什么写不了一个测试呢？ 语句覆盖: (也称行覆盖) ,指的是某一行代码是否被测试覆盖了。同样的代码要达到语句覆盖也只需要一个测试就够了,如assertEquals(2, foo(2, 2))。但是,如果把测试换成assertEquals(0, foo(2, -1)),那就无法达到所有行覆盖的效果了。通常这种情况是由于一些分支语句导致的,因为相应的问题就是"那行代码 (以及它所对应的分支) 需要吗？",或者"用什么测试可以覆盖那行代码所代表的分支呢？"。 **决策覆盖: **指的是某一个逻辑分支是否被测试覆盖了。如我上面所说,语句覆盖通常和决策覆盖有关系。还是以上面的代码为例,要达到所有的决策覆盖 (即那个if语句为真和假的情况至少出现一次) ,我们需要至少两个测试,如assertEquals(2, foo(2, 2))和assertEquals(0, foo(-1, 2))。如果有一个逻辑分支没有被覆盖 (比如只有测试assertEquals(2, foo(2, 2))) ,那么我们应该问和上面"语句覆盖"小节中相似的问题。 条件覆盖:指的是分支中的每个条件 (即与,或,非逻辑运算中的每一个条件判断) 是否被测试覆盖了。之前的代码要达到全部的条件覆盖 (也就是x>0和y>0这两个条件为真和假的情况均至少出现一次) 需要更多的测试,如assertEquals(2, foo(2, 2)),assertEquals(2, foo(2, -1))和assertEquals(2, foo(-1, -1))。如果有一个条件分支没有被覆盖 (比如缺少测试assertEquals(2, foo(-1, -1))) ,那么大家应该想想"那个条件判断是否还需要呢？",或者"用什么测试可以覆盖那个条件所对应的逻辑呢？"。 通过上面对几种传统的测试覆盖方法的介绍,大家不难发现,这些方法的确可以帮我们找到一些显而易见的代码冗余或者测试遗漏的问题。不过,实践证明,这些传统的方法只能产生非常有限的"学习"代码和测试中问题的机会。很多代码和测试的问题即使在达到100%覆盖的情况下也无法发现。然而,我接下来要介绍的"代码变异测试"这种方法则,它可以很好的弥补传统方法的缺点,产生更加有效的"学习"机会。 http://www.infoq.com/cn/articles/test-coverage-rate-role