单元测试相关功能 about edp HOT 15 CLOSED

现在定了有啥test framework了没？

from edp.

jasmine

发自我的 iPhone

在 2013-5-15，12:38，leeight [email protected] 写道：

现在定了有啥test framework了没？

—
Reply to this email directly or view it on GitHub.

from edp.

jasmine挺好用的：）以前还有个JSTestDirver可以搞远程浏览器测试，测IE之类的还比较靠谱，不过是JAVA的...
另外对于项目中单元测试的应用还是比较迷糊，应该做到什么地步，哪种层次，收益如何？

from edp.

关于测试，我觉得api测试的方法论——单元测试——工作的很好，但是web项目测试更多的属于gui测试范畴，目前还没有一个很好的实践方式。我们的经验是：前端自动化测试应该做，但如果把精力放到单元测试上会有些不合适；前端自动化工具集成单元测试表面可行，但多数忽略了web测试大部分属于gui测试范畴这个事实。

from edp.

单元测试的目的是在逻辑不变的情况下支持重构的展开，而GUI测试则重在功能和交互的正确

面对技术重构，最多的情况是不涉及界面变化的代码、模块、结构的梳理和重排列，而这又是保证一个系统长期具有对需求的快速响应能力的基本前提，因此我更愿意把UT放到和GUI测试同样的高度来对待

from edp.

1 重构不是时刻发生的，如果UT是为了重构而存在，那么工程师是选择平时即维护UT，还是重构前建立UT以保证重构的顺利？
2 据我们对公司内30+产品线的代码统计，那些“不涉及界面变化的代码、模块、结构”在系统中的占比是非常低的，把面向这些代码做质量保证的UT和GUI测试提到同样的高度来看待，虽然理想，但实际操作很难执行

from edp.

@otakustay 我在这里跟你打赌：“单元测试在实际的web产品生产中难以长期贯彻执行”。赌一顿饭。

from edp.

1. 所谓“实际的web产品生产”是指不包含基础库的建设喽，但edp显然连基础库也要覆盖
2. 难以长期贯彻执行是指我们做得不够好，不断受PM等的压力而放松对质量的把控，还是因为Web产品的自然属性决定其 必须不应该 长期贯彻单元测试？
3. 这个长期是多久，我理解就是一个产品线的生命周期内（从开始到大改版？），这样大概我们真的没人能见证～
4. “不涉及界面变化的代码、模块、结构”的代码占比不高是事实，但重构和代码结构优化往往在这些上发生，既然不多（覆盖率很容易上去），又容易发生重构等行为，自然应该去做下单元测试不是？
5. 不知道你理解单元测试的执行是到什么样的程度，所有代码都测试？我这边的团队是严格分离View和其它逻辑，除View外要求单元测试覆盖率在一定程度以上，View通过自动化等其它方式再处理，这些在所有开发人员的KPI里面，我倒是很有信心能够贯彻。
6. 如果说是任何代码都要单元测试覆盖，那我认为确实不易做，我们设计的做法是控件层隔离DOM，项目本身代码除控件外不得使用任何DOM，测试中各个控件有个Mock类型对应。对我们老版本系统的统计，控件约1.5W行，非控件代码约2.5W行，不算一个小比例了

至于赌嘛，有也行没有也行，下半年我去北京了一起吃饭先～

from edp.

@otakustay
在web产品上做单元测试，之所以难以长期贯彻执行未必是做得不够好的原因。存在即合理，那么“不存在”很可能就是因为其不合理。在测试这个问题上，相信你也同意我们应该抱着科学严谨的态度来对待，而不是盲目趋从传统的测试观念吧？

我想表述的是 单元测试在GUI类产品中能起到的作用非常有限 在GUI类产品中实现有单元测试可以，也非常容易实现，技术难度一点也不大。但以我个人的经历来看，单元测试在API类产品的测试执行非常合适，但在GUI类产品中就比较局限。不可否认，GUI产品都有着API的底层，但web产品又不太一样，因为它的API底层几乎就是浏览器了，剩下的API的分量就显得非常少。

即便少，我们还是要做，毕竟是白给的可测性部分，单测搞定也还好。但我想强调，web项目真正的测试方法论还没有出现，这种情况下，我们不应该把单元测试当做保证web项目质量的主力方案来盲目推动，其悲催结果在过去的3年里不断在我面前上演。

from edp.

@otakustay

另外，关于“贯彻的好”，我有一个很合理的定义：你在或者不在，执行就在那里，始终如一。

就是团队执行的不是你的个人情怀，而是实际驱动。

from edp.

所谓 盲目推动 是到了什么程度我不得而知，我也并不想把单元测试作为质量保证的唯一甚至是重要指标，抛开最基本的Selenium自动化外，我手上还有其它的工具来覆盖Web项目的测试，更进一步的也在探索。但是有几点我还是想说：

1. 商业系统的UI非常规则，甚至连每个页的逻辑都是可高度抽象的，这是ECOM（至少现在的UB）所开发的系统的特征，在这些系统中，UI在经一次封装后很少有灵活和变动，可复用度高，而剩余的业务型逻辑就会更多，我上面也已经从代码行（1.5W的UI / 2.5W的非UI）的量化形式说明了，我认为这一类系统中，单元测是应该被重视的
2. 对于基础库类，除控件、布局库，其它的如MVC体系、脚手架、模板引擎等，本身与具体的UI是无关的，单元测试在它们之间有且应当有非常强的的质量把控意义，除非我们没把单元测试做好。我就很难想象jQuery没有单元测试做为底子的话，如何能接受来自广大社区的pull request
3. 我并不认为去研究单元测试代表是 盲目趋从传统 ，在我眼中前端在测试上连起步都不算，因此无论是单元测试有失败或者有成功都是正常的，其它任何的测试理论也同理而得，因此而不去探索并不合理。最近有位同学和我说，他在代码中用this遇到了些BUG，因此建议我们以后代码杜绝this这个关键词，你说合理吗？

对于“贯彻的好”的定义，我非常赞同你的看法，我们的团队也一直是这么做的，当然理念、技术、经验的相互分享和推进还是必要的，“在和不在如一”并不表示每个人都应该像不在一样，而是每个人都是在的，执行是将所有人的意见和倾向进行融合和权衡后的结果，所以必须每一个人都强烈主张自己的想法，随后再讨论、竞争、取舍、实施，这样才不会“因任何一个人的情怀而驱动”

from edp.

在测试的理论上，我们恐怕还一时难以说服彼此，但只要你们团队能达到“贯彻的好”的标准，就说明你们的方法是正确的，我相信你们做到了。希望后续可以持续观察你们对于单元测试的实践，我坚信web前端最终能走上高度自动化测试的道路，正如同我相信爱情一样。在这之前，任何对这个方向的尝试没有对错，都是值得敬佩的。

from edp.

我们现在的UI部分的测试由一套小工具来协助，这套工具会将一个浏览器中的操作行为同步到多个浏览器上，以达到节约手工测试时间的目的，也确实是因为UI的自动化太难做，只能出此下策

from edp.

我在这里跟你打赌：“单元测试在实际的web产品生产中难以长期贯彻执行”。

@otakustay 确实在各个framework和library上做的很好。但是从业务线开发来看，我不得不武断的说，还是@fouber赢了。

前几天听人讲个case，一做java的人，在传统软件公司，做了两个核心模块，没qa，ut覆盖很全，bug基本没有。我当时觉得挺佩服这人的精神。后来讲到，这人在那个公司干了5年，最后一年基本没啥事情干。心中一悟，还是慢工出细活。对互联网来讲，需求整天变，上个版本做的功能和交互，下个版本可能要推翻。业务线搞ut，我个人觉得还是不现实。

至于web前端最终能走上高度自动化测试的道路，我还没看到很靠谱的路，所以继续观望，没有相信也没有不相信。

from edp.

edp test

from edp.