相对于UI自动化，单元测试方面的实践还是不够充分的，因此，这里也只是小结一下我们的经验
概述
首先明确一下，此处单元测试概念与经典意义有所不同，泛指所有：
由开发工程师编写的，可以在开发本地一键运行的，运行时间在分钟级别的测试用例，用例执行会依赖不多的，但往往也是稳定可靠的外部环境
测试框架一般使用TestNg而不是JUnit，主要原因在于TestNg的 DataProvider 功能很给力，非常适合用例须要覆盖多分支的场景
用例组织原则：
一个测试类对应一个功能类： funcOneTest.java 对应于 funcOne.java
若干个测试方法对应一个功能方法：test_funcOne_smoke() & test_funcOne_normal() & test_funcOne_error() 对应于 funcOne()
用例分类约定
还是以 超市购物 为背景，写几个Demo用例
Δ冒烟型用例 – 甲
@Test(description = "getNewestItems_冒烟_获取最新商品并检查若干关键属性") public void test_getNewestItems_smoke() { List<ItemVo> itemList = itemBean.getNewestItems(1); Assert.assertTrue(itemList.size() == 16, "size应该是16"); for (ItemVo vo : itemList) { Assert.assertTrue(vo.getName() != null, "name不能为空"); Assert.assertTrue(vo.getPrice() != null, "price不能为空"); } } |
说明：
顾名思义，就是在用例中简单调用一下被测方法（method），主要是为了跑通流程，拒绝Block级别问题
实践中，推荐 伴随着功能开发，随时编写冒烟用例，功能代码与冒烟用例一起提交代码库
对于一些复杂的功能，功能开发的过程也是一个持续重构的过程，编码前期完成的冒烟用例，可以有效起到安全网作用
Δ冒烟型用例 – 乙
@Test(description = "enter_and_leave_market_冒烟_进入与离开超市") public void test_enter_and_leave_market_smoke() { Custom tom = new Custom("Tom"); tom.enterMarket(); Assert.assertTrue(Custom.isAtMarket(tom), "tom应该在超市内"); tom.leaveMarket(); Assert.assertFalse(Custom.isAtMarket(tom), "tom应该不在超市"); } |
说明：
这个用例把进入超市及离开超市这两个（强相关的）接口串起来了，目的在于走通流程
实践中，建议 将新模块（函数）与其强相关的模块（函数）尽早进行简单的集成测试以提前发现一些问题
