从忽略到重视，Stack Overflow 改变了对单元测试的态度

在很长一段时间里，Stack Overflow 都忽略了单元测试，但现在 Stack Overflow 正在努力改变这种状况。

在早期的时候，Stack Overflow 是一个以快速精益运营为主的网站，像所有初创公司一样，优先考虑对企业最重要的质量属性，单元测试这样的事情被搁置到一旁。如果存在 Bug，主要靠用户在使用中发现并报告给他们，Stack Overflow 开发人员再进行修复或解决。 

Stack Overflow 认为单元测试是一种自动化测试，测试最小的代码片段以确保其正常运行，不会与进程外的依赖项对话。企业最佳实践是应该有大量的单元测试，中等数量的集成测试，并且只有少数端到端测试。 但以前 Stack Overflow 几乎没有单元测试， 虽然 Stack Overflow 有集成测试套件，但测试基础设施尤其是单元测试，远远落后于产品的成熟度。 

几年前，Stack Overflow 为 Teams Enterprise 推出了付费产品，企业用户并不愿意在生产时发现并报告错误了。而且在未来规划中，Stack Overflow 需要一个弹性代码库，在必要时重构代码，测试代码是让开发者创建干净代码的基础，而且 Stack Overflow 未来还想强制执行代码“clean beach rule”来保持代码的干净整洁。另外，编写良好的测试可作为一种文档形式，新加入的成员也可以通读测试并准确了解相关代码在做什么。所以他们不得不改变策略，对单元测试予以重视。

Stack Overflow 开始完善软件开发流程，但也并没有试图突然对已经部署在生产中的每一段代码进行测试覆盖，毕竟之前大部分代码都经过了开发者社区的实战测试。 

Stack Overflow 针对未来发展规划，在数据库层面提供了一种方法来指示测试何时提取模拟数据。因为使用 Dapper 和.NET 中的实体框架来管理数据库连接，因此 Stack Overflow 创建了一个扩展接口 DbContext，以便可以将模拟数据视为数据库连接。 另外还引入了一个 builder 而不是 constructor，为测试创建模拟站点数据。并且在前端实现了一个Jest来测试代码，并将它引入了所有的前端代码中。最后，他们还在 Stack Overflow for Teams 实例中设置了一个测试手册，详细介绍了如何编写良好的单元和集成测试。

Stack Overflow 表示编写一个好的单元测试并不是那么难，这些改变也意味着他们的代码质量变得越来越重要。

了解更多：

https://stackoverflow.blog/2022/07/04/how-stack-overflow-is-leveling-up-its-unit-testing-game/