相应的SystemTimeSynchronizer#syncTime()也做了修改,不再直接调用NtpClock。
package shannon.demo;
import thirdparty.any.NtpClock;
public class SystemTimeSynchronizer {
public int syncTime() {
//long currentTime = new NtpClock().getTime();
long currentTime = UnitTestFirewall.getClock().getTime();
long interval = System.currentTimeMillis()-currentTime;
if(interval == 0) {
return 0;
} else if(interval > 0) {
return 1;
} else {
return -1;
}
}
}
在正常运行时,debugging为false,SystemTimeSynchronizer调用的是NtpClockWrapper实例。在单元测试时,可以在测试代码里将debugging设为true,这样SystemTimeSynchronizer实际调用的是SystemClock实例。
/**shannon.demo.unittest is the unit test codes
* package for the demonstration.
*/
package shannon.demo.unittest;
import shannon.demo.SystemTimeSynchronizer;
import shannon.demo.UnitTestFirewall;
import junit.framework.TestCase;
/**<code>SystemTimeSynchronizerTest</code> is the
* unit test class for SystemTimeSynchronizer
* @author Shannon Qian
*/
public class SystemTimeSynchronizerTest extends TestCase {
protected void setUp() throws Exception {
super.setUp();
UnitTestFirewall.setDebugging(true);
}
protected void tearDown() throws Exception {
super.tearDown();
}
public void testSyncTime() {
int result = new SystemTimeSynchronizer().syncTime();
assertTrue(result==0||result==1||result==-1);
}
}
另一方面,其实我们也看到了,如果NtpClock对象后面连着真正的NTP服务器,那么它永远只能返回正确的时间,而SystemTimeSynchronizer#syncTime()实际上提供了系统时间快于、慢于和恰好等于标准时间三种情况的处理逻辑。如果要测全三种场景,修改NTP服务器会是件麻烦的事情。或者为此等很长时间,还要看运气。所以目前为止,我们只能在SystemTimeSynchronizerTest#testSyncTime()里验证SystemTimeSynchronizer #syncTime()的返回值是{0, 1, -1}中的任何一个。
要方便的测试所有的处理逻辑分支,关键就是要能够随心所欲的控制Clock#getTime()的返回值。在此定义一个DebugClock替换原来的SystemClock类。
package shannon.demo;
/**
* <code>DebugClock</code> is a Clock for debugging.
* It accepts arbitrary value as candidate time for
* the next return of {@link #getTime()}
* @author Shannon Qian
*/
public class DebugClock implements Clock {
private long time=-1L;
/**Sets candidate time for debugging.
* @param t - the candidate time value in millisecond
* @see #getTime()
*/
public void setTime(long t) {
this.time=t;
}
/** Returns the time in millisecond.
* By default, it returns system time if the
* candidate time is not preset. else it will
* return the candidate time after reseting it.
* @return - time in millisecond
* @see #setTime(long)
*/
public long getTime() {
if(time<0L)
return System.currentTimeMillis();
long t=this.time;
this.time=-1L;
return t;
}
}
(未完待续)
分享到:
相关推荐
总结来说,驱动程序和桩程序是单元测试中不可或缺的组成部分,它们帮助我们创建可重复、可控的测试环境,确保代码的质量和稳定性。在Java软件测试中,熟练运用这些工具和策略,可以大大提高开发效率和软件的可靠性。
测试桩的作用是在实际服务不可用时,模拟其行为,以便进行单元测试或集成测试。Java Socket服务器测试桩应具备以下特性: 1. 可配置性:允许设置不同的响应策略,如返回固定数据、模拟延迟等。 2. 可扩展性:方便...
在V模型开发中,Tessy主要应用在单元测试和集成测试阶段。单元测试通过运行代码检测出函数中错误,比如算法错误、接口问题等;集成测试则在单元测试的基础上验证单元之间接口的正确性。基于越早发现bug开发成本越低...
标题中的"jetty测试桩"指的是使用Jetty服务器作为测试环境中的模拟服务,它能够帮助开发者在实际接口未开发或不可用时进行测试。Jetty是一个轻量级、高性能的开源HTTP服务器和Servlet容器,常用于快速搭建测试环境...
测试桩HTTP测试桩HTTP 测试桩HTTP 测试桩HTTP
在IT领域,测试桩(Test Stub)是一种软件组件,它模拟了系统中的某个部分,通常是为了在孤立环境下测试其他组件。在这个场景中,"SMGP测试桩"是专为SMGP协议设计的测试工具,用于接收消息并实现实时跟踪功能。SMGP...
go语言测试桩,用于模拟接口测试,也可做性能测试桩,哈哈
**单元测试**是在软件开发过程中的一项基础性测试活动,它的主要目的是确保软件中的各个最小可测试单元(通常指一个单独的功能模块)能够按照预期正确运行。这种测试方式有助于尽早发现并修复软件缺陷,提高软件质量...
3. 常见问题及处理:本部分详细介绍了Testbed单元测试中常见的问题及其解决方法,帮助开发者更好地解决单元测试中的问题。 Testbed单元测试指导书(补充版).docx 是一份详细的单元测试指导书,旨在帮助开发者更好...
然而,在实践中,单元测试常常遇到各种难题,以下是十大难题及解决思路: 一、代码的可测性 单元测试的难题之一是代码的可测性问题。代码通常各部分都是互相关联的,但单元测试却是需要把代码单元跟别的代码分开...
在进行单元测试时,需要将桩函数返回值映射到测试用例中,以便于Testbed工具正确地执行测试用例。桩函数返回值是指软件中的桩函数返回值,需要正确地映射,以便于软件正确地执行。 #### 3.3.7 运行测试用例 在进行...
单元测试是一种软件开发过程中的重要环节,用于验证代码的各个独立单元是否按预期工作。它主要关注单个函数、方法或类的行为,确保它们在独立环境中正确执行其职责。以下是对单元测试流程的详细说明: 1. **理解...
第1章 单元测试的基本知识 3 第2章 第一个单元测试 21 第ii部分 核 心 技 术 第3章 使用桩对象解除依赖 49 第4章 用模拟对象做交互测试 83 第5章 隔离(模拟对象)框架 101 第iii部分 测试的代码 第6章 测试...