做了一些前端单元测试的调查，可以帮助了解一下前端单元测试的现状；

　　根据现有的经验提出些施行构想，对执行步骤进行预估和比较；

　　以下是现在想到和总结的一些问题，考虑的还不是很全面。

　　单元测试的价值是什么？

　　答：1、保证前端代码的健壮性与易维护性，前端的JS问题及早发现；

　　2、提高前端开发工程师单元测试的意识，提高代码质量，规范代码，增加代码健壮性，提高产品质量。

　　3、回归的价值场景：单个应用涉及其他应用变更，能迅速反馈错误。

　　业界的单元测试模式是什么？

　　答：业界有许多单元测试框架，基本模式如同一辙，页面加载 -> 查询页面中的测试用例 -> 执行JS用例脚本 -> 捕获异常 -> 结果显示。

　　其测试大部分是时时的，或者是本地测试用的比较多，无法在时间的维度上进行问题跟踪、分析，不容易管理JS脚本等。

　　与业界前端单元测试对比，我们能做什么？

　　1、使前端测试代码与开发代码分离，易于维护；

　　2、可以与UI自动化结合，前端单元测试的自动化，让更多的前端测试脚本借助现有的自动化去跑；

　　3、与测试平台集成，方便的JS异常错误显示与跟踪；

　　淘宝前端单元测试现状？

　　答：淘宝UED 有一套JS单元测试系统??云谦的”CloudyRun”，基于nodeJS + Jasmine，

　　CloudyRun驱动的直接是浏览器，让浏览器打开页面，支持各种浏览器，不仅局限于IE，火狐，更能支持chrome，safari。

　　现在的前端测试遇到什么问题？

　　答：

　　1、现有自动化产品不完善：

　　- 在异常数据处理上面存在问题，没有具体的错误异常日志，如：测试的结果数据采用了发送邮件的方式，而测试的历史记录却不好跟踪，假如想查看过去一个月的测试结果，无法办到；

　　- 查看执行过的用例，只能查看测试代码；

　　- 没有数据分析

　　2、推行中遇到的问题：

　　- UED各应用的代码沙箱闭包无法调用接口和方法，除非开发有单元测试意识，特地开放；

　　- 代码结构每条线各自有规范，比如开发什么样的全局变量，标准的封装方法不是很统一；

　　- 前端开发任务比较多，做单元测试的精力比较少；

　　- 开发不太喜欢写测试代码。

　　我们做单元测试可达成的目标是什么？

　　答：在测试平台上试行，针对测试平台一个系统的做前端代码的单元测试，覆盖率工具。

　　初步只能在现有我们的平台上面做一些验证与改进，长远的来看还是利大于弊；

　　短期的目标是什么？

　　答：1、短期的目标是在测试平台试行并改进；去业务线推广还要等稍微成熟的阶段；

　　2、更长远的目标是基于平台目标达成，在一条产品线试行，去业务线轮岗推行。

　　我们推动是不是也会遇到的同样问题，优势有哪些？

　　答：1、我们推动必然也会存在开发人员写代码的习惯问题；

　　2、但是我们有着天然的优势，前端测试数据可直接继承到测试平台，用户忠诚，开发测试每天工作都在平台上面，可以潜移默化的影响开发人员的编码习惯；

　　3、UI自动化可以解决我们前端脚本自动化执行的问题，技术上面，有积累更多。

　　我们构想有哪些不同？

　　答：如果我们来做前端单元测试和CloudyRun重合度预估是25%。