单元测试的接口问题

问题描述

现实中经常会在类中拆分为一些小方法为private,这些方法是不在interface上暴露给外部的现在想在细粒度上对这些private方法做单元测试,可是继承TestCase的类无法找到这些方法,除非把这些方法标记为publicpublic class AlarmQueryDAOTest extends TestCase{ private IAlarmQueryDAO dao; protected void setUp() throws Exception { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); dao = (IAlarmQueryDAO)context.getBean("alarmQueryDao"); } public void testGet() { ReporterStatus rs = dao.get(123L); }}请问有什么办法,既可以保持这些方法为private,又能在单元测试类中调用呢?

解决方案

1,不对private方法进行测试,因为他们不会被外界所调用,只要确保所有的public和protected方法是正常运行的就达到目的了。2,如果private中含有必须要测试的东西,那么就应该独立为一个Class,再对Class进行单元测试。3,如果一定要在本类中进行测试private方法,那就把private改成protected,然后再不同的源文件夹中组织相同的包结构,用其中的UnitTest对这个protected方法进行测试。如:被测程序src-->com.moyan.MyClass 测试程序test-->com.moyan.TestMyClass希望对你有帮助.

时间: 2024-09-16 01:21:58

单元测试的接口问题的相关文章

Java Web技术经验总结(四)

Spring MVC中返回JSON数据的不同方法 Spring 3 MVC ContentNegotiatingViewResolver example,该视图解析器,可以用于将同一份模型数据展现为不同的表现形式,例如JSON.XML和RSS等: 利用@ResponseBody注解修饰控制器方法,并在xxx-servlet.xml中开启spring mvc支持--<mvc: annoation-driven/>,这种机制背后的原理是MessageConverter. 最近用Mockito写单元

设计指导原则

设计指导原则 一. 性能相关: 避免在循环内部new一些没有必要每次都new的对象. 所有与IO相关的操作,都需要考虑性能问题,一般采取的措施是连接池,缓存,减少调用次数,合并请求. 每个业务都要分析整个请求链路,找到瓶颈,通过压测的方式确认问题及验证解决方案. 根据业务情况,使用异步化和最终一致性. CPU,内存,网络IO,磁盘IO这些瓶颈,需要知道在合适的场景牺牲什么换取什么.通俗的讲是空间换时间,还是时间换空间.不同业务场景下,要做合理的取舍.例如多线程并发查询后merge.这个就是利用C

在做自动化测试之前你需要知道的

什么是自动化测?   做测试好几年了,真正学习和实践自动化测试一年,自我感觉这一个年中收获许多.一直想动笔写一篇文章分享自动化测试实践中的一些经验.终于决定花点时间来做这件事儿. 首先理清自动化测试的概念,广义上来讲,自动化包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化,包括性能测试工具(loadrunner.jmeter),或自己所写的一段程序,用于生成1到100个测试数据.狭义上来讲,通工具记录或编写脚本的方式模拟手工测试的过程,通过回放或运行脚本来执行测试用例,从

在做自动化测试之前你需要知道的,转自:http://www.cnblogs.com/fnng/p/3653793.html

什么是自动化测?   做测试好几年了,真正学习和实践自动化测试一年,自我感觉这一个年中收获许多.一直想动笔写一篇文章分享自动化测试实践中的一些经验.终于决定花点时间来做这件事儿. 首先理清自动化测试的概念,广义上来讲,自动化包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化,包括性能测试工具(loadrunner.jmeter),或自己所写的一段程序,用于生成1到100个测试数据.狭义上来讲,通工具记录或编写脚本的方式模拟手工测试的过程,通过回放或运行脚本来执行测试用例,从

无接口.NET代码的单元测试

最近工作上的活就是研究一下如何为一个历史代码工程添加单元测试,已经做完了,就想抛砖引玉和大家分享一下结果,听听大家的反馈. 该工程目前还是VS2010下的C#代码,虽然大量使用了继承,封装和多态,但对接口的应用非常少,所以基本上没办法用常见的Mock框架(如Moq, Rhino Mock,等)来写单元测试. 考虑下来,解决方案无非两种:一是重构现有代码,通过接口(interface)来实现依赖注入(Dependency Injection, DI);二是寻找无需通过接口直接支持虚拟实体类的Moc

Entity Framework 实体框架的形成之旅--为基础类库接口增加单元测试,对基类接口进行正确性校验(10)

本篇介绍Entity Framework 实体框架的文章已经到了第十篇了,对实体框架的各个分层以及基类的封装管理,已经臻于完善,为了方便对基类接口的正确性校验,以及方便对以后完善或扩展接口进行回归测试,那么建立单元测试就有很大的必要,本篇主要介绍如何利用VS创建内置的单元测试项目进行实体框架的基类接口测试. 在采用单元测试这个事情上,很多人可能想到了NUnit单元测试工具和NMock工具进行处理,其实微软VS里面也已经为我们提供了类似的单元测试工具了,可以不需要使用这个第三方的单元测试工具,经试

写有价值的单元测试

这是写给开发同学系列文档中的一篇,主要讲单元测试. 写这个系列的原因是发现开发同学,尤其是偏业务的开发同学对于软件开发中的很多实践和理论理解的不够清楚.比如设计文档,代码评审,单元测试,集成测试和自动化测试,持续集成和持续发布这样一些耳熟能详的概念,说起来每个开发同学都听过,但很多人并没有深入考虑过为什么要引入这些实践,实践需要哪些手段,要达到什么目的,要坚持什么原则?所以这些实践落地的过程也是千差万别,效果往往也不甚理想. 通过这一系列文档,我会把我所了解的每个实践的来源.适用范围和价值用最简

利用J2MEUnit进行单元测试

这样就可以使用了.三.编写测试类 让我们编写一个TestCase来学习如何使用这套工具.编写TestCase类 编写测试的类要继承j2meunit.framework.TestCase.如同JUnit中一样,你可以覆写setUp() 和tearDown()方法,虽然这里没有反射机制,但还是推荐你把测试方法以test开头.这样一但J2ME有了反射机制,你也可以快速的移植.还有一点要注意的是,你需要为子类提供一个构造函数(假设你的类叫做TestOne): public TestOne(String

JUnit和单元测试入门简介

JUnit和单元测试入门简介 1.几个相关的概念 白盒测试--把测试对象看作一个打开的盒子,程序内部的逻辑结构和其他信息对测试人员是公开的. 回归测试--软件或环境的修复或更正后的"再测试",自动测试工具对这类测试尤其有用. 单元测试--是最小粒度的测试,以测试某个功能或代码块.一般由程序员来做,因为它需要知道内部程序设计和编码的细节. JUnit --是一个开发源代码的Java测试框架,用于编写和运行可重复的测试.他是用于单元测试框架体系xUnit的一个实例(用于java语言).主要