26
2013
06

Chutzpah运行前端单元测试超时的解决方案

Chutzpah作为运行前端单元测试的工具很强大,在实践中还是有一些小问题,当然这是对他不熟悉导致的。这不我们就遇到一个问题,还花了不少时间解决它。

我们的前端单元测试越来越多的时候,Chutzpah运行单元测试的压力就会越来越大,特别是在有操作DOM的情况,或则原JavaScript效率不高的情况,或则在用到RequireJS异步调用多的情况,等一系列影响加载测试速度的问题都可能造成Chutzpah运行单元测试的时间增长。这时候使用原来设置的话会出现一个错误:JS Error: Timeout occured when executing test file。看他的图像表现:

25
2013
06

如何将JavaScript单元测试集成到VS2012和Jenkins

前面文章记录了JavaScript单元测试的一些内容,主要从单元测试本身,而本文讲的是我们实际应用中的一些技巧。在实际应用中,我们往往需要在开发工具中运行单元测试,或则在Jenkins中运行单元测试。而我们作为.net项目那么如果能在VS中运行我们的JavaScript单元测试,那是多么得人性的事情,如果我们跑Jenkins中能自动检测我们的JavaScript单元测试那更能提高我们的编码质量了。我们能想到的问题大神们都为我们想到了,一个很好的工具Chutzpah

19
2013
06

Sublime Text 2安装插件方法详解

Sublime Text 2是一款非常好的代码编写工具,类似于Notepad++,精巧美观。为了我们的代码编写更加方便我们可以通过安装一些插件来解决这个问题。下面我们就来看看安装Sublime Text 2插件的方法。


安装Sublime Text 2插件的两种方法:

  1. 直接安装

    安装Sublime text 2插件很方便,可以直接下载安装包解压缩到Packages目录(菜单->preferences->packages)。

18
2013
06

Javascript单元测试现状、难点及解决方案

单元测试在后台开发中非常流行和普及,在前端开发中则使用的非常少;在前端JavaScript单元测试在类库中的应用还是非常普及,但在真实项目中应用还是不太广泛;就算能在项目中应用到,覆盖率也不是特别高。


Javascript单元测试现状

根据一些论坛的调查数据,我们可以看到超过半数以上的开发人员是不写单元测试的,我们下面看看这些数据,以及一些前端测试框架的市场占有额吧。

2011年报告: 58%的人不写测试;Jasmine (44%);QUnit (41%);Vows(13%);Express/Mocha(11%);Nodeunit(8%)。

17
2013
06

Javascript单元测试框架Jasmine的扩展封装

Jasmine是一个很好的前端单元测试框架,之前也用Jasmine和Qunit进行了一个比较。但Jasmine的异步测试虽然比较灵活,但还是多少有些麻烦,如果我们的这类异步测试比较多,那么重复代码也就上升了,为了代码的质量我们选择封装一下,让它拥有和Qunit一样方便的异步测试调用。先看啊可能整个代码需要这样:

14
2013
06

浏览器工作原理 - 浏览器重绘(redraw)和重排(reflow)

一篇很老的文章,搜藏了很久,拿来记录到博客上。对前端工程师是一个很好忠告。


  在项目的交互或视觉评审中,前端同学常常会对一些交互效果质疑,提出这样做不好那样做不好。主要原因是这些效果通常会产生一系列的浏览器重绘(redraw)和重排(reflow),需要付出高昂的性能代价。那么,什么是浏览器的重绘和重排呢?二者何时发生以及如何权衡?如何在具体的开发过程中将重绘和重排引发的性能问题考虑进去?本文期待可以部分解释以上三个问题。

  浏览器从下载文档到显示页面的过程是个复杂的过程,这里包含了重绘和重排。各家浏览器引擎的工作原理略有差别,但也有一定规则。简单讲,通常在文档初次加载时,浏览器引擎会解析HTML文档来构建DOM树,之后根据DOM元素的几何属性构建一棵用于渲染的树。渲染树的每个节点都有大小和边距等属性,类似于盒子模型(由于隐藏元素不需要显示,渲染树中并不包含DOM树中隐藏的元素)。当渲染树构建完成后,浏览器就可以将元素放置到正确的位置了,再根据渲染树节点的样式属性绘制出页面。由于浏览器的流布局,对渲染树的计算通常只需要遍历一次就可以完成。但table及其内部元素除外,它可能需要多次计算才能确定好其在渲染树中节点的属性,通常要花3倍于同等元素的时间。这也是为什么我们要避免使用table做布局的一个原因。

10
2013
06

浏览器工作原理 - CSS2可视模型(CSS2 visual module)

画布The Canvas

  根据CSS2规范,术语canvas用来描述格式化的结构所渲染的空间——浏览器绘制内容的地方。画布对每个维度空间都是无限大的,但浏览器基于viewport的大小选择了一个初始宽度。

  根据http://www.w3.org/TR/CSS2/zindex.html  的定义,画布如果是包含在其他画布内则是透明的,否则浏览器会指定一个颜色。

10
2013
06

浏览器工作原理 - 动态变化和渲染引擎的线程

动态变化

  浏览器总是试着以最小的动作响应一个变化,所以一个元素颜色的变化将只导致该元素的重绘,元素位置的变化将大致元素的布局和重绘,添加一个Dom节点,也会大致这个元素的布局和重绘。一些主要的变化,比如增加html元素的字号,将会导致缓存失效,从而引起整数的布局和重绘。


渲染引擎的线程

  渲染引擎是单线程的,除了网络操作以外,几乎所有的事情都在单一的线程中处理,在Firefox和Safari中,这是浏览器的主线程,Chrome中这是tab的主线程。

10
2013
06

浏览器工作原理 - 绘制(Painting)

  绘制阶段,遍历渲染树并调用渲染对象的paint方法将它们的内容显示在屏幕上,绘制使用UI基础组件,这在UI的章节有更多的介绍。

  

全局和增量

  和布局一样,绘制也可以是全局的——绘制完整的树——或增量的。在增量的绘制过程中,一些渲染对象以不影响整棵树的方式改变,改变的渲染对象使其在屏幕上的矩形区域失效,这将导致操作系统将其看作dirty区域,并产生一个paint事件,操作系统很巧妙的处理这个过程,并将多个区域合并为一个。Chrome中,这个过程更复杂些,因为渲染对象在不同的进程中,而不是在主进程中。Chrome在一定程度上模拟操作系统的行为,表现为监听事件并派发消息给渲染根,在树中查找到相关的渲染对象,重绘这个对象(往往还包括它的children)。

10
2013
06

浏览器工作原理 - 布局(layout或reflow)

       当渲染对象被创建并添加到树中,它们并没有位置和大小,计算这些值的过程称为layout或reflow

  Html使用基于流的布局模型,意味着大部分时间,可以以单一的途径进行几何计算。流中靠后的元素并不会影响前面元素的几何特性,所以布局可以在文档中从右向左、自上而下的进行。也存在一些例外,比如html tables。

  坐标系统相对于根frame,使用top和left坐标。