大部分没接触过或者不愿意写前端单测，大家觉得主要原因在哪里？

问题就再这，宁可推倒不重构，原来的系统烂 是前人和时间的锅，重构出问题就是你的锅

何况是虽然烂但是修修补补居然能正常跑的那种，才是最恐怖

逻辑部分写单测还是很有用的，但是有些产品变化快，UI 的单元测试就要频繁改动比较麻烦，而且基准也得变。

工资 时间 不到位

工期有限

你需求和交互变得比女朋友心情还快，一份代码根本等不到重构就要被推翻丢弃，写个鬼的单元测试

1. 需求频繁变动；
2. 时间太紧；

投入与产出不成正比,而且应该是自动化测试或者测试人员来写

因为页面 ui 型的月抛吧，不停更换重组，业务更新很频繁….

做工具数据层，扩展支持多，就想着怎么搞稳。

@evada 我现在也是想着给工具类等公共函数补充单测，然后给业务组件那些写一下，其余的业务代码由于迭代频繁，我也觉得可以不写。

@qq73666 自动化测试用在项目重构是真的香，特别是大版本重构。但是业界好像没有比较成熟的方案，一直在造轮子，内耗严重。

@otakustay 这个确实，业务强相关的个人感觉也不需要做单测，但公共函数这类可以考虑写写。

@murmur 现在就是在重构别人的代码，与其说是重构，不如说是重写，真的比写业务难受多了，还要保证质量。引进自动化测试跟单测，保证基础业务以及工具类业务组件不受影响。

1. 额外的工作量
2. 没时间
3. 有时间也不会写 懒

工具类的组件可以写一写，修改这类函数牵扯太多，有单测比较稳妥。业务侧的代码一般改了就测了，不改也不怎么会变（除非修改了公共代码）
做这些事情还是需要有企业 /团队文化来支撑的。适量的单测能提高自己的工作效率，减少 bug 。但做得太细也不会被计入产出，反而要被教育一顿，要聚焦关键问题。

1.单测耗时间
2.很多跟界面相关的，写不了单测
3.很多简单类似的操作，没有必要写

前端是最靠近用户的业务，变化最快。

测试推动无论在哪个地方，都不适合高速变化的场合。所以本质是剧烈的变化，让测试失效了，而不是前端测试有什么问题。

你要是比较稳定的业务并且愿意给时间，前端单元测试一样搞的起来

业务重 UI 短周期的可以没必要，我认为单测有价值点或者说对于技术有反哺的点在于，如果你真的要写一份可靠的测试，你会想怎么推翻设计或者改写原先 [又不是不能跑] 的代码，你会想办法去做方法抽离，然后想办法让他遵守单一职责链，减少 /剥离外部依赖，增加适配器(减少冗长不可测的判断)，UI 和组件怎么做状态剥离，我认为这是对我有帮助的点。至于对于业务，其实没多少价值的，远比不上这周上 5 个让用户多点几下广告的需求来的重要。

时间紧、任务重、变化快

@james2013 第二点是核心。测试界面必须靠人看。

钱。你给双倍工资试试？

本来测试的工作就交给测试做好了。现在都堆给研发了。