使用JUnit对Web项目进行测试(二) -- 不启动服务器调试Web项目

时间：2021-12-18 05:12:26

~ ~小伙伴们在做 Javaweb 项目的时候,一个功能块敲完,然后提心吊胆的打开 Tomcat , 测试功能的时候发现总有那么一两个功能点炸成串?而且有时候是很简单的 SQL 语句编写错误,或者实体名字写错这种”笔误”“.但是像初学者一样,没完成一个功能点就跑一遍的话,又很累.而且当你的项目初具规模的时候,开启服务器不是那么快就能完成的,这对一些配置不好的电脑简直就是噩梦!敲两个小时的代码,一个半小时在等待中度过…

没关系,看完这篇博客,你就会知道原来 JavaWeb 的调试还可以这么简单!

声明:这篇博客只给出测试类的代码,功能类代码只会简单提及,适合有web项目功底的同学; Junit 单元测试并不能为你解决所有潜在的错误;本文的案例测试代码书写方式在 SSM 框架, SSH 框架可以互换.

一:创建一个测试类,建议将测试类单独放在一个包中(在 maven 项目里有测试类专门的存放位置),新建一个Junit Test Case类,下一步
使用JUnit对Web项目进行测试(二) -- 不启动服务器调试Web项目

测试类的命名建议是你将要测试的类名+Test,然后点 Browse, 你可以选择要进行测试的类(一般选择 Service, 因为 Service 关心的是业务需求),用这种方式创建可以自动生成要测试类的测试类,你只需要进行测试代码的书写.

    @Test
public void testqueryById(){

    }
@Test
public void testQueryAll(){

    }
@Test
public void testReduceNumber(){

    }

如果里面有自动生成的代码,删除或注释即可…

二:配置 spring 和 junit 整合, junit 启动时加载 springIOC 容器,这里你需要 Spring-test jar包

@RunWith(SpringJUnit4ClassRunner.class)
//告诉junitspring配置文件
@ContextConfiguration(locations = {"classpath:spring/spring-dao.xml"})

同样的,在测试类中我们会调用 Service 的逻辑,由于我们使用的是 Spring+SpringMVC+ 持久化框架,所以要注入一个 IService 接口(这里我直接对 DAO 进行测试了)

@Autowired
private SeckillDao seckillDao;

接下来是测试逻辑,在编写测试代码之前建议覆盖实体中的 toString 方法,不然打印会很麻烦.

@Test
public void testqueryById(){
long id = 1000;
        Seckill seckill = seckillDao.queryById(id);
        System.out.println(seckill.getSeckillName());
        System.out.println(seckill);
    }

//JAVA没有保存形参的记录,如果你在 dao 中传了多个参数,那么需要声明它的形参对应的实参,否则 JVM 会显示找不到参数.声明方式稍后奉上
    @Test
public void testQueryAll(){
        List<Seckill> seckills = seckillDao.queryAll(0, 100);
for(Seckill seckill:seckills){
            System.out.println(seckill);
        }
    }

    @Test
public void testReduceNumber(){
        Date killTime = new Date();
//对增加进行测试的时候,只要数据库增加了一条数据,我们就默认这个方法执行成功了
int updateCount = seckillDao.reduceNumber(1000L, killTime);
        System.out.println("updateCount = "+updateCount);
    }

解决JAVA不保存形参的记录

int reduceNumber(@Param("seckillId")long seckillId,@Param("killTime")Date killTime);

    Seckill queryById(long seckillId);

/**
 * mysql的分頁查詢
 * @param offset 告诉它实际的形参
 * @param limit
 * @return 
 */
    List<Seckill> queryAll(@Param("offset")int offset,@Param("limit")int limit);

接下来我们根据他返回的结果和我们想要的结果对应就可以了. 测试类不用部署项目, 测试周期非常短, 而且可以进行专项测试. 测试类代码逻辑十分简单, 几乎不会出错. 如果结果不是预期的, 那么根据你的需求修改!
当然, 它的局限性也很打. 从单元测试不能看出页面传值的错误, 许多项目在服务器中的表现也不能模拟.
那么我们什么时候用junit呢?
当你的数据库操作非常复杂, 你不确定能输出你想要的值的时候, 相比用 debug 调试, 使用 Junit 是更方便的手段.或者新手出错概率非常大, 也不用在服务器中专门测试项目的表现, Junit 是个必备的工具!而且测试类的测试代码重用性很高.
如果你的数据和预期相悖, 那么修改业务逻辑; 否则, 查看页面是否有错! Junit在一定程度上减轻了我们业务代码调试的压力, 让我们关注于一点解决错误.
最后一点 就像上一篇Junit博客说的一样, Junit测试并不能证明你是对的,而是证明你没有错!

标签：

相关文章