您的位置:知识库 » 软件工程

讨论: TDD in HTML & JavaScript 之可行性和最佳实践

作者: Teddy's Knowledge Base  来源: 博客园  发布时间: 2010-08-09 20:50  阅读: 1128 次  推荐: 0   原文链接   [收藏]  

  TDD的背景

  自从03年Beck正式提出(事实上在00年,Beck提出eXtreme Programming时,就已经提出了这个词)Test-driven design/development这样一个基于测试优先、重构和迭代的革命性的开发方法以来,无数的实践已经证明,对于适合进行TDD的领域,TDD能够极大地提高代码的可维护性和开发效率。

  在这样一个迭代的流程中,在写任何的production code之前,先写test,再写production code,并且不断地对代码进行清理和重构,并且每次迭代都要进行回归测试,保证新增的test和production code不会break任何已有的test和production代码。

  一般来讲,支持自动化的回归测试的工具相对比较容易实现。整个流程中的难点在于:当先行写test代码的时候,必然要求先定义被测试的production code的外部接口,对于第一次迭代,自然没有问题;但是,由于需求的变更,或者整体设计的变更,在后续的迭代过程中,经常会发生,已有的已经实现并且包含完整测试的production code的外部接口需要变更或者说重构;尽管从理论上,绝大多数的重构需求,都有规律甚至是模式可循,但是,如果完全依赖于人工操作,则不仅效率不高,且极易出错。所以,但凡成功的TDD实践,其中都不乏很多支持重构的工具。比如,现行绝大多数的集成开发环境,都有很多自动化的代码重构工具,大大的降低了代码重构的成本。

  但是还有一些领域,TDD还略微有些力不从心,或者说,至少,至今没有看到太多比较好的实践案例。比如:对于Database和UI。

  对于数据库开发的TDD,到目前为止面临的主要挑战是工具的支持。无论是自动化的回归测试工具,还是重构工具都还远远不够成熟。

  而对于UI的TDD,则是本文的主题。

  TDD in HTML & JavaScript 概述

  谈到应用程序的UI,其实包括两个方面的内容:一方面是纯图形的look & feel;另一方面,则是用户和应用程序的交互。用户和应用程序的交互往往同时导致图形界面的变化,并且,转换到新的交互行为。

  由于工作实践中主要是基于WEB的HTML和JavaScript的项目,这里对TDD in UI的讨论,将focus在基于HTML和JavaScript的UI。

  同时,一般来讲,WEB程序的表现层主要有客户端代码和服务端代码,而服务端代码,相对来说,更容易被测试。所以,本文讨论的重点,主要focus在客户端代码。换句话说,这里讨论的TDD in HTML & JavaScript指的是对于客户端的HTML和JavaScript的TDD。

  TDD in HTML & JavaScript 之可行性

  说到可行性,其实可以分两个层面:理论上的可行性,和实际应用的可行性。

  第一个问题是:纯图形的look & feel理论上可以进行自动化的测试吗?答案几乎是否定的。因此,主要用于呈现纯图形的HTML及CSS,也几乎是很难自动化测试的。

  那么,用户和应用程序的交互理论上是否可以进行自动化测试呢?答案毫无疑问是肯定的。

  WEB交互的测试其实可以根据WEB程序的架构,分为两种类型:

  1. 传统的WEB程序主要基于服务端来呈现内容,用户和页面的交互,主要是get,post数据和页面跳转。因此,对应的测试方式,主要也是由测试工具模拟需要get或post的数据,并且跟踪期望的页面跳转情况。这种情况下的测试其实相对简单,因此本文不想过多讨论。
  2. 当前的基于AJAX的WEB程序则很大程度上丰富了用户和页面交互的方式,用户和页面的交互,除了传统的get,post数据和页面跳转,在页面不刷新的情况下,还通过触发各种DOM事件,甚至直接触发JavaScript方法的执行,由JavaScript来改变和呈现内容。此时,传统的只能模拟需要get或post的数据的测试工具就无能为力了。此时由于所有的逻辑代码都在JavaScript中,所以,本质上其实是需要对大量的JavaScript代码进行测试。此正是本文希望讨论的重点。

  首先,针对JavaScript的自动化测试工具其实已经有不少了,如:

  Mock工具也有:

  支持直接重构JavaScript代码的工具相对比较少,提供的功能也都还非常弱:

  从支持工具的现状,可以说,影响TDD in JavaScript的实际可行性的因素之一是重构工具的缺乏。不过,最近的情况有了一些改变,现在也出现了一些支持JavaScript重构的变通的解决方案,如:

  • Script# - Write C# code,compile C# source code directly to JavaScript code
  • jsc – Write any .NET code, convert .NET assembly to JavaScript, ActionScript, java or PHP code

  这些方案的特点是,利用现有的IDE对流行的编程语言如C#源代码的完善的coding,尤其是强类型,重构和测试的支持,让开发人员写C#,由工具转换为可直接执行的,格式化的JavaScript代码。除了充分利用IDE对流行语言的coding支持之外,这类方案的另一个好处是,相对于高薪聘请Senior的JavaScript开发人员,Junior的C#的开发人员要便宜得多,也易招得多,但得益于Script#,已经足够能用他们熟悉的C#,写出逻辑复杂和OO的JavaScript代码,因此,开发成本被大大降低。

  综上所述,TDD in JavaScript不仅理论上是可行,实际应用上,也是有足够的工具支持的。尤其是如Script#这样的工具的出现,极大地提高了JavaScript代码的开发效率。

  TDD in JavaScript 之最佳实践

  谁都希望能有最佳实践。什么是最佳实践呢?有很多人见不得“best”,“最”这样的词,认为,这个世界上没有“最”的东西。有吗?当然有!我们首先要略为上升到哲学的高度,对于包含“最”这样的词汇的命题,如果想要为“真命题”,则必然是需要加上一个适当的前提条件的。

  比如说:我说“我是这世界上最NB的人”。这毫无疑问是个假命题。因为,缺乏适当的前提条件。你可以自己做个练习,如果觉得这个命题假,想办法给它加上更多的前提条件,一定能让它变真。

  所以,所谓最佳实践,指的是,对一个或者一类特定的问题,在一个相对确定的背景下,所能采取的实际处理的方案典范。加上前提条件,则“最佳实践”当然是存在的,也是值得讨论的。

  通过前面的章节,我们已经把本文重点讨论的主题,限制到一个相对小的范围,那就是对基于AJAX的WEB应用程序中的大量的JavaScript代码,如何进行TDD?

  并且,我们也收集了足够的支持TDD需要的各种工具,包括自动化测试工具,Mock工具和重构工具。在这些工具的支持下,很大程度上,WEB程序客户端JavaScript代码的TDD和服务端代码的TDD,不应该有很大的区别。但同时,由于客户端代码的特殊性,自然也应该有一些客户端脚本代码所特有的实践模式。

  以下首先列出本人推荐的一些实践模式,希望大家能一起修正和补缺。

  最佳实践一:应用MVC模式

  在传统的非AJAX的WEB程序中,JavaScript往往处于非常辅助性的地位。除了实现一些特效和数据验证等辅助功能之外,一个页面的JavaScript代码,恐怕屈指可数,自然无所谓测试,甚至是TDD了。

  但是在现在的复杂的AJAX应用中,以往必须由多个独立页面的get,post和页面跳转才能组合实现的功能,通过JavaScript,可以在一个无需刷新浏览器的页面中,轻易实现,不但用户体验更佳,速度更快,对服务器的负担也更小。

  此时,原本传统WEB程序的服务端需要处理的问题,如数据绑定,事件绑定,逻辑控制等,需要在客户端进行处理。也因此,原本为了解决WEB程序服务端代码可测试性问题MVC模式,也就一样可以良好的应用于客户端。清晰的将JavaScript代码分割成M,V,C,将能够把相同的逻辑职责尽可能集中到一起来管理,从而极大地增加客户端代码的可维护性和可测试性。

  下表简单对比服务端和客户端MVC下M,V,C的对应职责:

 

Model

View

Controller

Server Side 返回用于呈现页面内容的数据的 Domain Objects 代表了一个页面的抽象,包括页面的内容呈现,数据,事件定义 处理View上触发的事件,获取数据,更新View上的数据,触发View的内容呈现
Client Side 返回 JSON 数据的 Restful Services 同上 同上

  最佳实践二:应用依赖注入和IoC容器

  应用MVC模式,本质上是抽象的逻辑职责上的解耦。而依赖注入和IoC容器则是代码的物理依赖性上的解耦。尽可能的利用构造器注入,设值注入,接口注入或IoC容器来解除具体的实现类之间的直接依赖,自然就能极大的大提高每个具体的实现类的可测试性。

  最佳实践三:应用模板引擎呈现主体内容

  AJAX应用中的一个需要客户端呈现的View,必然需要呈现一些HTML,这些HTML往往需要根据Model返回的JSON数据动态构造。一般来讲,我们会有三种方式来构造和呈现这些HTML:

  • 在JavaScript中遍历JSON数据,拼接HTML字符串,呈现到页面上;
  • 在JavaScript中遍历JSON数据,动态实例化DOM对象,通过DOM对象的方法,呈现HTML的DOM;
  • 通过如JTemplate这样的JavaScript模板引擎,将JSON数据绑定到一个HTML模板,由模板引擎呈现最终的HTML;

  本最佳实践的建议内容就是,对于一个View的主体内容,应该尽可能的通过模板引擎来呈现。为什么呢?因为,对于一个WEB程序来说,最不稳定的,会经常变化的部分,无疑是纯图形的HTML和CSS,使用模板引擎,将能够使得这些HTML尽可能的集中,并且易于修改,也更易于HTML和JavaScript的整合。

  最佳实践四:应用Script#

  应用Script#好处前面已经提过了,这里再简单列举一下:

  • 充分利用现有的IDE对流行的编程语言如C#源代码的完善的coding,尤其是强类型,重构和测试的支持;
  • 相对于高薪聘请Senior的JavaScript开发人员,Junior的 C#的开发人员要便宜得多;

  如反对,请列举我不该用它的理由?

  对于以上几个最佳实践的应用实例,请参见我之前的文章:This is jqMVC# – CNBLOGS Google Tracer Sample

0
0

软件工程热门文章

    软件工程最新文章

      最新新闻

        热门新闻