如何推广前端单元测试

我在这里的理解是你所说的横向分层是业务逻辑（business，通常包含了model和service）、展示部分分别交给不同的人完成，而纵向分层是一个人包干，是不是这个意思？

从我的开发体会来看，横向分层能够把开发人员擅长的一面发挥出来，比如a能力强，业务理解力透，那么a来负责业务部分；b工作时间不长，而且对页面技术比较熟悉，就来负责展示部分。横向分层的分工有个特点就是专一性，所以优点在于可以使做的人专注，效率高，缺点就是容易疲沓，比如一个人不停的做页面部分，简单而繁复，做的时间长了难免有想法，尤其国内程序员心志都比较高，比如一个技术团队没有新的技术吸引他了，工资拿的又不是很满意，长期做这种简单重复的工作会使他觉得没有前途，要么能够换一下岗，要么就是选择跳槽。横向分层模式在外包公司，或者大型项目中经常被采用。横向分层由于需要将层与层之间进行整合，因此需要付出沟通和集成成本，引入测试是减少这种成本的最佳办法，而且是必须的，否则容易出质量问题。纵向分层按业务功能模块分配，将一个功能模块（包含业务和展示部分）交给一个人来完成，这种分配本身对负责的人要求比较高，有一定挑战性，需要理解业务，编写后台代码，负责前台展现，负责前后台的联合调试。由于所有工作由一个人完成，因此纵向分层不像横向那样是开放的，也就是说，你手头的工作与别人相关，同时要接受他人的约束，纵向分层的完成质量更多依赖于个人的能力和责任心，那么单元测试就完全是个人责任心的体现了。其实在我看来，单元测试跟开发方式的选择没有多大制约关系，也就是说无论采用哪种方式，理论上都是需要做单元测试，至于实际中能不能做，要不要做，还是跟具体的项目开发需求、以及开发人员来定。

所提到的测试后行这种情况，是一个开发习惯问题，毕竟测试驱动这种思想并不是人人都会去接受，但话说回来，有（寥）胜于无，尽管这种做法其实并不省时省力，而且其实还使单元测试的目的大打折扣。校验测试也属于单元测试范畴，放在集成测试中不合适，加大了集成测试任务，不利于做到重点突出，毕竟集成测试重点在于部分之间的接口。另外说纵向分层似乎表达不是很恰当，不过目前我也找不到合适的词，所以先为使用。

根据我参与过2个有做前端单元测试的项目（都是基于web）经验，推广前端单元测试有2个困难：
1. 前端单元测试很"难做"
2. "性价比"太低

"难做"我看到的几个问题：
1. 很多时候的前端测试不是在做"单元"测试，而是需要做集成测试，你很难像后台代码的单元测试那样，可以做隔离，做mock。
2. 前端是易变的，在我参与的这2个项目中，用户界面可以说每天都在根据用户反馈做调整优化，比如2个button换一下位置，比如操作成功的提示信息要更改用词。这样就导致前端单元测试的脚本也不停在改变。
3. 工具支持不好，一些地方用到了ajax的效果，特别是和鼠标，键盘事件结合的效果（autocomplete，认证码，拖拉），这些地方无法用现有的工具来做

"性价比"也有几个方面，
1. 和后台的单元测试相比，你很难有一个衡量前端单元测试的标准，比如怎么算覆盖率？什么样的HTML代码和js代码要经过单元测试？
2. 后台的单元测试在我们做新版本或者重构的时候可以提供很大帮助，而前端的单元测试在这方面提供的帮助几乎为0

我现在是不做前端单元测试的，甚至在Rails里面，把Controller的单元测试也省了，尽量把所有的逻辑都移到model和lib里面，只对他们做单元测试，而controller/view就用人工的方式做集成测试。

这是我对于前端单元测试的看法，和大家讨论一下。

你说的前端单元测试是指对页面的单元测试么？那还是免了吧。
页面交互那么复杂，而且还易变，不知道你是怎么保证测试覆盖率的（那得考虑多少种情况啊）。

我非常高兴有这么多大牛们参与到讨论中来,并且提出很多非常深入的疑问和解决方案.
就您的几个问题,我的想法是:
1.前端的测试是可以Mock的,但是有一些系统内置函数的Mock可能得花一些时间和技巧.最简单的,在测试代码里写一个函数名与无关调用函数名一致的空函数也算是最基本的测试桩了.
2.前端单元测试有其特点,需要集成进功能性测试的特点是肯定了的,比如senelium中的模拟鼠标事件等工作.因为事件是否绑定正确,等等界面操作性的问题应该程序员来负责而不是QA.
  如果换位置对模拟事件是不会产生影响的.
3.同上.

性价比:
1.这个是个有趣的问题,其实如果团队把代码规范制定好,比如私有函数以"_"开头等,其js代码的覆盖率是可以算的,至少可以人工算....
2.这不是单元测试的问题了,js的重构本来就是个非常棘手的问题,不可能像java那样爽的一个地方重命名,其他地方跟着变!
我觉得最后你说的很对,推广单元测试不光是工具的问题,更重要是开发思想上的根本改变.
MVC特别是视图层与其它层的分离是js开发中可测性最为重要的一个要点.

我觉得要根据真实的情况来决定，很多bs的应用确实没有做单元测试的必要。

你的理解对了。我记得有这类说法的。我们横向结构一般分为：表现层、业务逻辑层、数据映射层三层，大型软件都采用这个分配开发工作；我们的纵向结构一般就是按照模块来划分，比如人员管理、票据管理，目前大多数的中小型软件开发都采用这个分配开发任务。

基本上大多数项目可行，前提是，你的设计能力（粒度)能否达到横向分层的要求（至少要让后台开发人员知道要开发什么api），如果达不到，大家都会很累。如果达到要求，大家都很轻松。

习惯是可以养成的。对于如何省时省力的说法我们比较一下就知道了：
1. 整体：开发阶段在整个软件生命周期来说只是很短的一部分，更长的部分是维护，维护期间自动化测试省时省力还是人工测试省时省力？
2. 开发阶段：就静态语言的业务层来说，开发阶段耗费大量的时间在重启服务器、登录系统那个、调试、修改、重启服务器的n次循环中。单元测试能够直接进行调试，而不需重启服务器，你说这是省时省力还是费时费力？
3. 开发阶段：针对页面部分的开发，不需要重启服务器，这点与纵向分成扯平，但对方提供的api都经过测试，稳定性高于纵向分成的开发，同时单测也可作为api的调用文档、样例参考，你说是省时省力还是费时费力？
综上所述：横向分层不得不引入单元测试，纵向分层不太适合引入单测，如果你不能扭转开发模式，单元测试始终会受到抵触


简单的说就是：通过单元测试来完成类部分（service、model、dao）的调试、开发，通过集成测试来完成页面部分的调试、开发

关键是如何达到，策略方法有哪些。起码文档能力是其中一个环节。


习惯如何养成才是关键。人不仅是懒惰的，也是狡猾的，任何被逼的事情都有人能找到相应的接口或者手段对付。省时省力理论上可以作出分析，但实践中仍需要具体问题具体对待。比如说，项目维护量小，短生命周期，业务不复杂，这时就要考虑测试粒度测试成本和整体项目成本的关系。

我还是持原有观点，单元测试是否引入不在于何种开发形式，不是说因为需要解决层之间的接口才有必要引入单测，单测的目的在于将代码引入“轨道”，校验代码正确性、突破代码边界，从而提高代码质量，提高可维护性、可升级性和可重构性。打开任何一个开源库，无论大小，好的库必不可少的都会有test目录的踪影。

单测引入关键处在于：1）测试的实现必须是简易的，举例说来，ejb在原生期单测极为麻烦，一直被人诟病，同样的问题还出现在原生的servlet，直到webwork框架的出现，servlet action的问题才得到根本的解决，javaee的复杂度一个体现就是在组件的测试上，以前有很多不同的测试框架对不同组件进行了方案解决，但是这些测试框架本身就有复杂性，何况将它们组合集成在一起在一个软件项目中去使用。目前ruby on rails在单测当中是我见过的最好的测试解决方案，可以去参考。2) 开发人员能从TDD中寻找到利益、信心以及好处，从而形成习惯




集成测试绝对不是为页面部分的调试和开发而设计的

同意前一半,测试应该是在开发同时进行的,开发完成以后再去进行测试(当然这未免也不失为一种方法)那我们还谈什么测试驱动开发呢?
但是就工作量估算来说还是应该把测试的时间算在里面的,debug\重构不需要时间么?

之间的关系其实也就是法势术的辨证关系了，三者独立出来都不能够解决问题。这块的实践让我对这三者有更深刻的理解。

错了，是程序员通过集成测试进行的方式进行页面开发，相对程序员的单元测试，并不是说他开发完了不需要集成测试。大家做web开发应该很清楚这一点，也许是词不达意，那就叫做“集成调试开发”把。另外100%的覆盖率在实际项目中也是不太现实的，能把核心业务覆盖率提上去已经很不错了。

不要把单测看得那么美哟，通过项目实践，我发现单元测试的维护量其实也不小：最明显的就是测试前的初始化数据。是公用呢还是私用呢，随着项目的深入，这一块慢慢的会成为程序员头疼的地方。