测试开发

当前位置:首页 > 测试开发

测试驱动的面向对象软件开发(第二十五章)

第五部分 高级主题

在这个部分将介绍一些主题,它们常常导致应用测试驱动开发的团队陷入痛苦挣扎之中。这些主题的共同之处在于,它们超越了功能级设计和系统级设计的边界。例如,当我们看一段多线程代码时,既需要测试线程内执行的行为,也需要测试不同线程之间的交互方式。

根据经验,如果这种代码没有清楚地表达它们所关注的方面,将很难测试。将所有东西堆在一起会得到令人困惑、容易损坏、容易误导的测试。当我们花时间来寻找这些“测试坏味道”时,常常会得到更好的设计,实现更清楚的职责分离。


第25章 测试持久性

我们总是在思维转变的状态中做出长久的决定。

-Marcel Proust

25.1简介

正如第8章中所看到的,如果我们根据第三方API定义了一个抽象,那么在集成这个API时,必须测试这个抽象的行为是否符合我们的预期,但却不能利用测试作为API设计的反馈。

常见的例子是利用持久机制来实现的抽象,如对象/关系映射(ORM)。ORM在简单的API后面隐藏了大量的功能。当我们基于ORM创建一个抽象时,需要测试我们的实现发出了正确的查询,正确配置了对象与关系数据库schema之间的映射,使用了与数据库匹配的SQL语言,执行更新和删除时满足数据库的完整性约束,与事务管理器正确交互,及时释放了外部资源,避开了数据库驱动的缺陷等。

在测试持久代码时也需要关心测试代码的品质。有-些组件运行在后台,测试必须正确地准备好这些组件。这些组件具有持久的状态,可能让测试之间相互干扰。我们的测试代码需要处理所有这些额外的复杂性。我们需要花更多的精力来确保测试可读,生成合理的诊断信息,精确地指出失败的原因一指出失败出现在哪个组件,以及失败的原因。

这一章介绍了处理这种复杂性的一些技术。示例代码使用了标准Java持久API (JPA),但这些技术也适用于其他持久机制,如Java数据对象(JDO)、像Hibernate这样的开源ORM技术,甚至是利用數据映射技术来转储出对象的一些机制,如XStream或标准的Java API for XML Binding(JAXB)。

示例场景

本章中的这些例子将使用相同的场景。我们现在利用一个Web服务来代表客户进行拍卖狙击。

客户可以登最不同的拍卖站点,并通过多种支付方式为他们竞拍的物品和我们提供的服务支付费用。系统支持两种支付方法:信用卡和一种名为PayMate的在线支付服务。客户有一个联系地址,如果他们有信用卡,客户还有一个账单地址。

我们系统中的领城模型由持久实体来表示,如图25-1所示(只包含了说明实体用途的那些字段)。


文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~