ServiceClass
类的 if...else
逻辑分支保持不变(为了清晰起见)。同时,无参数构造函数仍然适用。注,并不总是需要有创造性逻辑,例如 while...do
子句或 for
循环来正确地测试类的方法。只要有针对类使用的对象的方法执行,简单的模拟期望就足以测试那些执行。
您还必须更改 ServiceClassTest
类以匹配场景,如下所示:
清单 5. 经过编辑的场景 2 的 ServiceClassTest 类
... private ServiceClass serviceClass; private Mock mockCollaborator; private Collaborator collaborator; public void setUp(){ serviceClass = new ServiceClass(); mockCollaborator = mock(Collaborator.class, "mockCollaborator"); } public void testRunServiceAndReturnFalse(){ mockCollaborator.expects(once()).method("executeJob").will(returnValue("failure")); collaborator = (Collaborator)mockCollaborator.proxy(); boolean result = serviceClass.runService(collaborator); assertFalse(result); } } |
这里有几点需要注意。第一,runService()
方法签名已经不同于以往。它现在不接受 ICollaborator
接口,而接受具体类实现(Collaborator
类)。就测试框架而言,此更改非常重大(注,虽然在本质上反对多态,但是我们将使用传递具体类的示例(仅供举例之用)。在实际的面向对象的场景中绝对不能这样做)。
第二,模拟 Collaborator
类的方式已经更改。使用 jMock CGLIB 库可以模拟具体类实现。提供给 jMock CGLIB 的 mock()
方法的附加 String
参数被用作创建的模拟对象的标识符。使用 jMock(当然,还有 RMock)时,在单一测试用例内每个模拟对象设置都要求有惟一标识符。这对于在公共的 setUp()
方法中或在实际测试方法内定义的模拟对象来说是正确的。
第三,测试方法的原始期望并未更改。仍然要求有 false 证明才能使测试通过。这是十分重要的,因为通过展示使用的测试框架足够灵活、可以适应各种输入带来的更改、同时仍然允许获得不变的测试结果,使它们在无法调节输入生成同样的结果时展示了其实际限制。
现在,重新运行作为 JUnit 测试的测试。测试将通过,如下所示:
文章来源于领测软件测试网 https://www.ltesting.net/