如果在没有指标要求和管理者要求的情况下，你会自愿给你的代码+测试buff吗？
这个问题的假设是你认为写测试是有好处的，因为如果你不认可那就肯定不会去写。那又是哪些不可抗拒的力量导致你最终没写测试呢？
1. 没实践过，不愿意尝试？
2. 构造测试数据，mock, 打桩很麻烦，投入产出不高？
3. 不会写？不懂得测试方法？
4. something else?
TDD，自动化测试这些词在我还没工作的时候就已经在业界多年了，10年过去，感觉现状依然，还是很少有同事会提及“程序员测试”这个事。想和大家一起讨论下，有没有必要写测试？
分享下我的个人经历，首先我是写测试的，但对测试覆盖率没有要求，属于“随缘”。
不要求覆盖率指标：
2010年，在H公司某团队正好负责推广开发人员写测试，构建“low level质量防护网”的这事（high lvel由测试人员保证）。要求达到80%以上的代码覆盖。结果是在纯软件的团队中推广比在嵌入式的团队中要更容易接受一些。但普遍觉得麻烦，产出投入不高，不怎么愿意尝试。只有像我们这样在象牙塔脚下的人使劲在推广。在这个工作中我自己收获了几点，与大家分享：
一，追求高代码行覆盖率是没有意义的。对于不太了解的小伙伴我补充说明下，覆盖率分为代码行覆盖率，条件覆盖，判定覆盖和条件判定覆盖。覆盖度最高的是最后一种，但要写很多测试，且要对测试设计有所掌握才行。所以最常见的其实就是代码行覆盖，这是一种最低级别的代码覆盖，只要你的测试代码经过了这行代码就算一次覆盖。所以，理论上你完全可以在测试中一行assert都不写，而达到很高的代码覆盖率。
从而，得到的结论是：如果覆盖率低，有问题的风险会更大。但覆盖率高不能说明就没问题了。
二，与对代码没有洁癖的人聊这事，是个空谈。我见过很多同事代码的分层是混乱的，有的一个大函数1000行全搞定的。对于这种情况，你就不要和他谈测试了，有代沟。如果你是管理者，花点时间在思想上指引下，如果和你关系不大，把时间用来精进自己吧。
所以，我现在写测试是不会对自己要求覆盖率指标的。
对接口不对UI写测试：
这是我目前的做法，只对REST API接口/重要模块/核心算法写测试。并开启watch模式。只要修改一行代码，测试就会自动重新运行，看到测试结果。
UI层，由于前期变更非常频繁，这样测试代码的维护工作量非常大。所以我没写。业界有提过用MBT（model based test)来解决这个事的，但这个事在国内就更没几个测试和开发玩过了。在国内由其是小团队小公司基本不考虑的。
并没有TDD：
Kent beck提到TDD的原则是当你写代码时，同一时间只做一件事。要么是在写测试，要么是在写新功能，要么就是在重构。这个思想我是一直在实践，但还是无法做到先写用例再写代码。我是步骤是：
1. 写新功能代码
2. 写测试
3. 让测试通过
4. 补充更多的测试
5. 让测试通过
6. 重构
7. 让测试通过
我是尝到甜头的，所以会一直写测试，共勉。
不写测试。
之前尝试在自己项目里写测试，但是发现要把所有可能的逻辑写出来测试太费时间，如果不能把所有逻辑覆盖掉，写测试的意义又是什么？在纠结中，就放弃了。
除了这个以外，另外就是构造测试数据也很烦。我在区块链项目中，有时候想要构造测试数据难度太恶心了。
自动化测试的目的是做回归测试，也就是人已经测试过的测试逻辑。主要解决由于代码发动造成问题重复出现。或已经测试好的功能又变得不可用。
覆盖所有逻辑，是需要用测试设计方法的，如数据组合，pairwise, 路径，状态迁移等。我也见过有开发的兄弟直接用脚本穷举了所有数据组合的可能（这个有点暴力低效，哈哈。）。当然，要画更多时间，以前这些事都是testor去做的。
测试用例是分层的，每层能覆盖到的bug的类型是不同的。无法只使用一种测试技术完美实现。
而且，bug有个测试无穷理论，意思是只要你花时间，bug总会有的😂
构造数据是真心恶心，如果有些三方框架可以mock或faker data还会好一些。但我估计区块链项目，可能好多轮子要自己造吧。
会，我只写E2E不写单元，因为做的都是业务系统。
代码改了，如果不运行一遍我没办法确认每个业务点都是正常的。
你是用什么技术栈写E2E呢？
我写node, 用的NestJS，测试框架用的自带的Jest
肯定是会写单元测试，但是不会强制自己做到覆盖率多少以上，感觉测试还是挺重要的……
认同
项目初期可能不会写，先尽快上线可行性产品，等到稳定之后（集体看项目运行情况），会写一些必要的测试代码，保证核心逻辑全部有测试。
ps: 测试写一套比较标准的，后面项目复用性很高。
针对性很强，其实自动化测试主要也是真对回归测试。目前并不适合做发散测试或叫探索性测试
我觉得一般程序员写测试的时机应该是在每当发现自己需要去验证一些什么的时候，而往往这种情况下我们会选择打开一个 console 执行一下代码片断，或者在界面上输入点什么来看运行结果。
程序员所做的事情在我看来就是极限地 DRY，写测试也是这样：把日常重复性的手动验证给自动化了。
我觉得照这个思路写出来的测试不多不少，覆盖到的刚刚好都是自己不确定会不会出错的逻辑。
TDD 看过，觉得是一种 top-down 的设计方法，不是非常理解，所以暂时还不会用它。
为啥“往往”自动加粗了？
关于TDD，推荐你看下kent beck的《测试驱动开发》一本非常薄的小册子，用java写的（很多优秀的思想是java生态下诞生的，你懂得）。照着书打一遍代码，就感觉像有人手把手教你如何TDD，我觉得很不错的。
我到现在还能清楚记得里面的一些关键点：
1. 划分story的原则要求每个story都是可测试的
2. 每个story是一个由写测试，迅速让测试通过，重构的顺序执行。
3. 同一时间只做一件事，所以要时刻清楚你当前是在写测试/重构还是在开发新功能？
我觉得国内对质量/测试这些事看的比较云淡风清，有的公司连专业测试都不配置的。所以，可能大家对测试没有太大的兴趣和关注。
嗯。很久没登录，刚看到。你有空可以回来复习一下，再想想自己这几年真的 TDD 了吗。
从个人成长角度，用 TDD 的方式来写绝对是有收益的，不仅仅在质量的提升，有可能还会在过程中反思自己的设计是否合理、优雅。
但是在国内大部分环境下很难，业务、KPI 驱动的结果往往是功能优先，即使是大厂，部分项目有单测、也有覆盖率，很可能也是 “KPI”的产物，比如要求的覆盖率达到多少，大部分是为了写而写，你会发现所覆盖的单测的 case 只是 normal 的一种情况，just make it pass 而已，而不是真正的去用 TDD 的思想去写，这种情况下的收益就甚微了
有同感，一条大船，只靠自己不管怎么使劲，船都不会改变方向的。小公司可能对质量的要求就更没法说了。
所以，找到一群“臭味相同”的人，不比找老婆容易。
测试目前还没怎么写过， 不过在自己学习ror的个人项目时会去写，让自己有个习惯。
等到不写测试会有很大时间成本的时候会开始写测试
看时间了，如果时间充裕，会写。不充裕有时就省了。
不过重要的逻辑还是会写的。
做app的好像没人写TC吧，包括大厂
也不尽然吧，前两天还看到网易的一个测试APP测试框架的分享
没写过，不过实际操作中感觉应该很有用
建议尝试下，会打开另一扇窗
如同这次的新冠还有美国的新流感，没有被坑过，想让国内的出钱的花钱在写UT or TDD，那是异想天开。 不少算钱的写UT覆盖率都比较惨淡，更别说一般的系统了。
如果团队管理者和成员不能对这个事都达成共识，很难开展。有可能领导不支持不给时间，有可能成员应付差事。
我是一个想写又不愿意写的人
知道写单元测试是有用的，但是感受不到他的好处
写的话真的是太痛苦了，所以不愿意写
但是觉得应该写
目前处于无比矛盾，且很难跨越的障碍
是思路完全没有打开
对我来说写测试最烦的不是写testcase，而是构造测试数据。我是用的django写后端，主要写reset api和复杂的业务逻辑的测试，在python中可以使用factory_boy（与ROR中的factory_girl是一个东西）构造可重用的测试数据。而且支持数据的faker, 写起来容易多了。
其它框架应该也会有类似的框架吧，具体不太清楚。
在测试里面提到，bug是有群居性的，也就是说当一个模块出了一个bug，那很有可能还会出其它的bug。所以，要对这种模块写测试。每次修改代码的时候都检查一次，如果把以前的逻辑改出了问题第一时间就能发现和修复。有这么几次经历后就会觉得这是一件性价比很高的事。
会写，不过我一般都不太忙的时候才会写，有时候赶业务实在来不及写单元测试
确实，我有时候也是后补的，有时候一个地方代码反复出现bug的时候就补几个test
单元测试还是需要的
没有这个习惯，因为开发周期一直比较短，时间紧张。
不会
如果时间比较充足，还是会的。
从来不写测试，代码自己多自测就好。写测试浪费时间
这个真的看工期
老实说 只是简单的测试自己的接口~~~~这些年都没写过，只有刚入行的时候写过俩月😅😅
基本不会，因为时间就没富裕过。
偶尔遇到逻辑条件多的时候会写测试用例给前端说明一下。
看项目，周期紧张的，就是怎么方便怎么来了。
这不是必须的保障吗
必须写单元测试呀
看时间。