诊断Java代码: Liar View错误情势[Java编程]

Liar, liar!

假想一下:您已经为一个分布式系统尽心计划了一个极好的 GUI 程序,它包含了客户机恳求的全部东西及别的一些东西.您已经让它运行通过了一个自动化测试套件的测试 ― 由于不变量的数目是个天文数字,因此,自动化测试是必须的.测试的后果是程序得到了一张“无错误的安康证明书”.

公布这个 GUI 的期限到了,但是,作为一个象您这样严峻的程序员,只是为了发现错误的行为 ― 本该在自动化测试中就被捕捉到的行为,您启动了程序,对它做最后一次手工测试.但愿您可以避免这种情形.真的,您可以.

Liar View 错误情势

好的调试从好的测试开始.由于 GUI 程序中有大量的不变量需求查抄,因此,自动化测试是必须的.但有时固然已经通过了一套测试,在手工查抄时,程序仍会呈现本该由这些测试之一发现的错误行为.

在分布式和多线程系统中,这种行为是常见的.在这些情形下,程序的“不肯定性”本质常常就是缘由所在.但在 GUI 中,却有另一种常见的缘由 ― Liar View 错误情势.

症状

大都 GUI 程序测试,跟普通的程序测试一样,遵守下列步骤:

启动程序

查抄程序状况的一些特点

尝试改正状况

查抄状况能否已经按志愿被改正

但就象我已提到过的,有时对运行时程序行为的手工查抄的后果会与测试得到的成功后果相冲突:屏幕上大概显示一个行列,包含被测试（按假想举行）确认删除了的元素;而对象中大概包含报告显示已被更新了的陈旧数据.

近似这样的错曲解使我们对自己的心智能否健全产生猜疑,大概更糟地陷入到康德的猜疑论哲学,猜疑起缘由本身的有效性.

不要让这些发生在您身上.当精确对待缘由时,它确切是有效的.固然有背面的报告,但很少有程序员会在写代码时永久地丧失心智（ 永久地是一个关键词）.

起因

找到这些错误的一个关键是要熟习到,至少有一部份错误可以在测试套件中找到.

在测试 GUI 程序的历程中,错误最常发生的地方是在最后一步:查抄状况能否已经按志愿被改正.缘由是 GUI 普通是基于模子-视图-掌握器（MVC）体系构造计划的.Swing 类库乃至把这种体系构造建到了 GUI 类自身的构造中.

在 MVC 体系构造中,程序的内部状况保存在模子中.视图呼应改变模子状况的事件并呼应更新屏幕图象.掌握器把这两个组件衔接在一同.

这种体系构造的长处是把视图从模子中别离出来,使得各自的实现可以独立改正.但是它对自动化测试办法倒是一个挑衅:我们很难查验模子中的状况改变能否在视图中得到了得当的反映.当这二者之间存在冲突时,我们就会碰到一个 Liar View 错误情势的实例.

　　以上是“诊断Java代码: Liar View错误情势[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：