Comments (15)
现在定了有啥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.
- 所谓“实际的web产品生产”是指不包含基础库的建设喽,但edp显然连基础库也要覆盖
- 难以长期贯彻执行是指我们做得不够好,不断受PM等的压力而放松对质量的把控,还是因为Web产品的自然属性决定其 必须不应该 长期贯彻单元测试?
- 这个长期是多久,我理解就是一个产品线的生命周期内(从开始到大改版?),这样大概我们真的没人能见证~
- “不涉及界面变化的代码、模块、结构”的代码占比不高是事实,但重构和代码结构优化往往在这些上发生,既然不多(覆盖率很容易上去),又容易发生重构等行为,自然应该去做下单元测试不是?
- 不知道你理解单元测试的执行是到什么样的程度,所有代码都测试?我这边的团队是严格分离View和其它逻辑,除View外要求单元测试覆盖率在一定程度以上,View通过自动化等其它方式再处理,这些在所有开发人员的KPI里面,我倒是很有信心能够贯彻。
- 如果说是任何代码都要单元测试覆盖,那我认为确实不易做,我们设计的做法是控件层隔离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.
另外,关于“贯彻的好”,我有一个很合理的定义:你在或者不在,执行就在那里,始终如一。
就是团队执行的不是你的个人情怀,而是实际驱动。
from edp.
所谓 盲目推动 是到了什么程度我不得而知,我也并不想把单元测试作为质量保证的唯一甚至是重要指标,抛开最基本的Selenium自动化外,我手上还有其它的工具来覆盖Web项目的测试,更进一步的也在探索。但是有几点我还是想说:
- 商业系统的UI非常规则,甚至连每个页的逻辑都是可高度抽象的,这是ECOM(至少现在的UB)所开发的系统的特征,在这些系统中,UI在经一次封装后很少有灵活和变动,可复用度高,而剩余的业务型逻辑就会更多,我上面也已经从代码行(1.5W的UI / 2.5W的非UI)的量化形式说明了,我认为这一类系统中,单元测是应该被重视的
- 对于基础库类,除控件、布局库,其它的如MVC体系、脚手架、模板引擎等,本身与具体的UI是无关的,单元测试在它们之间有且应当有非常强的的质量把控意义,除非我们没把单元测试做好。我就很难想象jQuery没有单元测试做为底子的话,如何能接受来自广大社区的pull request
- 我并不认为去研究单元测试代表是 盲目趋从传统 ,在我眼中前端在测试上连起步都不算,因此无论是单元测试有失败或者有成功都是正常的,其它任何的测试理论也同理而得,因此而不去探索并不合理。最近有位同学和我说,他在代码中用
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.
Related Issues (20)
- 如何地图markLine的线上加悬浮窗?
- [edp-build]加一个将text资源内联到js的处理器 HOT 2
- [edp-build] LESS procesor替换js文件中less依赖时,会提取依赖、去除注释、空行等
- windows上使用有路径问题
- edb web在Windows上使用路径不对 HOT 2
- edp import 不稳定 HOT 1
- edp ERROR Can not find the specified `project' command module from `edp-project' HOT 2
- [webserver]和babel 6一起用总是搞不定 HOT 6
- 对VariableSubstitution提一个小的改动,希望支持自定义边界符 HOT 1
- edp import 导入非edp项目的edp依赖 HOT 2
- 求提供一个TextInline插件 HOT 1
- resource.js里 response.removeHeader('Transfer-Encoding') 不生效
- edp test吐槽
- edp相关问题 HOT 2
- edp 怎么引入react呢?有相关的实践吗?
- edp webserver stylus 默认配置改进
- v1.2.0+ 版本build后有保留字的内容不会特殊处理
- edp ERROR Can not find the specified `project' command module from `edp-project'.
- 是否能支持 https
- 有没有考虑提供 HMR 功能呀?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from edp.