2018-07-04我待过一些中国的互联网公司，也问过一些创业公司，进行单测的不多。我也一直在想没有单测，但是整体的质量也还能“说的过去”的原因是什么。首先没有单测的主要原因还是和中国互联网的现状有关，中国的互联网本质是商业公司，在中国激烈的竞争环境下，业务的快速发展导致需求的快速上线是一个常态。这也导致了无论是产品还是开发经理，都是以支撑业务为kpi，其次才是质量。所以单测是一件不能直接体现到kpi上的隐形需求，项目排期一般也没有单测的时间。那整体质量还过的去的原因其实也是因为互联网对质量的容忍度，允许出现一些非严重的问题，需要测试人员或qa通过checklist、集成测试工具或方法的提升能发现核心问题就够了，甚至通过监控和用户反馈紧急召回就够了。从这个方面也能说明中国的功能测试短期内不会像google一样完全被代替掉，还是会存在，根本是研发底层对质量的要求没有变化。不过不可否认的是，测试的一个趋势是写以提高质量的代码为目标，或许研发测试完全一体化之后，测试来写单测也不是一件不可能的事展开 1 46
2019-02-26同在小的创业公司，根本不用问，没做单元测试，最近在学茹老师的课程，java基础知识，有研发看到，竟然说我一个测试干嘛去学开发的东西，我无语，我只能按照自己内心的想法去学习，知道自己想要什么，然后去努力，坚持打卡，加油！ 20
2018-07-04之前的一家公司曾经比较重视单元测试，当时具体单元测试代码是开发写的，对于测试部门的我而言，只是在CI这块，负责跑出各项目的单元测试结果后汇总成报告查看。具体单元测试的质量是由开发进行把控和审核。
再后来组织有些变动，不再重视单元测试，便流于形式，开发可能就写个假的代码保证跑出的报告好看，实际的单元测试本身则被忽视了……
目前就职的公司则是没有整体规划过单元测试这块，所以也是困惑怎么推动这件事情。 15
2018-08-17我现在的公司是比较重视单元测试的，也有专门也单测的人，我就是其中一个，我们单侧内容主要分两部分，一是基于mock的真正意义上的单元测试，这部分主要验证业务逻辑，二是与数据库的集成，应该算是集成测试，主要验证数据方面的一致性。另外，看评论有一位说在推行c#的单元测试，我们这边就是用的c#，框架之前用的Nunit,由于数据隔离性不是特别好，后来又换成了Xunit框架，Mock框架是moq，或许可以和那位哥们讨论一下，共同提高😊 8
2018-07-05在Accenture时候单元测试行覆盖率要达到99%，分支覆盖率要达到90%，仅一些exception分支可以不用覆盖，并且每个测试用例前面要注释好这个case测的是什么方法，输入什么输出什么，预计结果是什么等以便code review时可以快速的知道这段代码是做什么的，甚至一些大功能还要带上use case的id方便追溯原始需求，在测数据持久化层测试要通过内存数据库把CRUD流程都测出来作者回复: 埃森哲的所有项目都有这么高的单元测试需求吗？我的理解是一些和人的生命安全息息相关的软件才会有几近苛刻的代码覆盖率要求，比如航空航天，汽车电子，轨道交通，部分医疗器械软件等，如果所有项目都这样做成本还是很高的
7
2018-11-05我们开发了个单元测试框架，测试人员写用例只要修改yaml配置文件即可完成单元测试，比以前方便多了。 6
2018-07-04老师，我的学习方向是Python接口自动化，JMeTer，LR，是不是在学做性能之前就得先去学Java呢，在这学习方向中有什么建议么！谢谢 6
2018-08-16十分赞同茹老师的这个观点「并不是所有的代码都要进行单元测试，通常只有底层模块或者核心模块的测试中才会采用单元测试。」，这一定是首要前提，不然在落实的时候会发现，被测函数可能会完全被 Mock 代码取代了。
如果要做单元测试，那么对开发代码的要求也会更高，至少开发在代码分层上一定要做好，不然光去甄别哪些可以做单元测试哪些不能做，都需要花费很多的时间。
单元测试和接口函数测试要区分开，我们有个项目，本来是以单元测试的名义开展的，结果搞出来的却是接口函数测试，比如 windows 端的文件导出函数的测试，这样就不需要 Mock 代码了，而相对导出函数，又增加了内部函数的覆盖，但是不管怎样，这个只能算是接口测试了，也就是说，并不是所有针对代码级别的测试，都叫做单元测试。
最后，如果不是开发自己做单元测试的话，一定要考虑投入产出比的了。
以上，望沟通交流，公众号「sylan215」展开 5
2018-07-04不太理解老师说的输入数据那部分
只知道被测函数的参数进行设计
不知道如何针对函数的成员变量等进行设计用例？作者回复: 能问这个问题，说明你已经很好地理解了文章的关键内容。这里的成员变量指的是类的成员变量，逻辑上你也可以把它想象成是全局变量。因为函数内部会去读取类的成员变量，然后根据类的成员变量来决定后续逻辑等。
5
2019-01-21单元测试本身并不复杂，但在实践中又经常需要十填许多坑，如：事务的传递可能导致单元测试结束后事务回滚失败（若用内存数据库又存在解决sql兼容性的烦恼），多线程执行单元测试导致测试结果不正确，对第三方接口做mock困难，实现逻辑中会周期性计划任务的功能也不好做单元测试。作者回复: 涉及数据库的单元测试建议不要操作真实的数据库，而是使用dbmock。你说的非常对，单元测试是入门容易，工程实践比较难
3
2019-05-09自动化测试集应该是一把可信的、灵活的尺子。所以测试集不宜过大，应能支持在几个小时内给出稳定可信结果。测试集的大小应考虑以下几个方面：以时间窗口为首要敏感因素，然后考虑覆盖功能的重要程度，测试执行的稳定性。作者回复: 很棒的总结
2
2018-12-19倒是定义一下mock代码啊？都不定义然后就对比，一脸懵逼。。。。 2
2018-07-12我所在的是敏捷开发团队，QA需要review UT，那么我想知道QA 怎样review UT才更有价值呢？现在基本是根据业务需求去review UT的case是否有遗漏作者回复: 我建议qa从接口层面review效率更高，qa直接review ut可能并不是太合适
2
2018-07-06感觉小公司项目开发的同时写测试代码工作量不比写项目小，而且时间人员也不够用，老师请问怎么破这种情况?作者回复: 要真正做好单元测试，UT的代码工作量是不低，所以还是要看项目的性质来决定要不要UT，要的话需要做到什么程度，往往前端的代码做ut的相对比较少，后端代码尤其是比较核心和底层的，都会有ut的要求。
2
2019-02-27公司的测试 都是靠开发人员自测和测试人员测试，测试方法也是手动点击的这种笨方法,想写打哪元测试，同事们都说 代价太大，最后也没执行起来。感觉测试集成也是一套系统，光靠单个方法和技术点没有完整的系统 感觉就像是增加了工作量 1- 2018-08-31我在开发过程中会写单测，但是耦合性一直是个大问题，有时候想到很多测试用例，但是模拟起来很麻烦就放弃了 1
2018-07-12测试review ut也许不能提出很多意见，而且要开发来讲解一下，但是有两个好处1.防止假测试用例，也就是不做验证的用例，2.在进行上层用例的设计时可以知道哪些已经在ut层覆盖了，避免重复劳动 1
2018-07-04今年刚在团队推行单元测试，阅读过《单元测试的艺术2》，觉得非常受益，也强烈推荐其他同学阅读。我认为单元测试不仅仅是为了测试，也能让你写出结构更好，质量更佳的逻辑代码。在推行的这几个月中，也只能以新代码进行试水，遗留代码完全没有勇气进行。而且目前团队成员在接受程度上还远没有达到得心应手，也比较容易出现抵触情绪，我也正在思考如何才能更有效的推广。
另外，我们使用的C#语言，NUnit测试框架+JustMock Mock框架，从技术选型上我觉得还是比较好用的。
非常期待后续的课程，也非常想认识更多的在单元测试上想尝试亦或是有所心得的同学共同交流 1
2018-07-04项目中推行单元测试中，您提及的问题如何解决，后面会有介绍吗？
如单元函数中大部分都是对数据的CURD操作，如何获取有效数据，又如何防止脏数据。都很让人头痛。
期待后续文章，多谢！ 1
2018-07-04老师，后面会有实战部分吗？作者回复: 专栏后期会有专门的篇幅讲代码级测试，那里会提供更多实际的例子
1