这里每天分享一个 iOS 的新知识，快来关注我吧
前言
昨天的文章讲了如何在 iOS 项目中写单元测试，有兴趣的可以去翻看一下。
今天突然想到有些重要的内容遗漏了，写单元测试有些需要注意的点，今天特意来补充一下我认为的写单元测试的最佳实践。
写单元测试要具有以下特点
1、自动化执行
单元测试必须是完全自动运行的，不需要人工干预，可以在每次提交代码之前或者在 CI 流程里通过 Pipeline 流程执行一次全量的单元测试。
最后自动输出“通过”还是“失败”，而不是依赖程序员查看日志文件得出结论。
一方面保证提交的代码正确性，另一方面保证没有改坏之前的代码。
2、独立性
相对来说，每个单元测试都应该是相互独立的，可以单独运行每个测试。
每个测试用例应该只关注一个特定的功能或行为（一个单元），一个固定的函数或方法。单元测试的独立性也要求函数本身的独立性，这样既能保证代码的健壮性，也能保证代码可维护。
3、快速执行
一般来说我们每次提交代码都要执行一次全量的单元测试，因此每个单元测试都应该保证能够快速执行完成，不然每次提交要等很久。
快速执行也能提供快速的反馈，帮助开发者及早发现问题。
保证快速执行的建议是不要执行耗时的操作，比如网络请求，尽量用 mock 数据来保证数据的准确性和快速。
4、命名清晰
给每个测试用例取一个有意义的能读懂的名字，可以帮助其他人理解这个测试在测试什么。
5、覆盖尽量多的边界情况
写测试用例的是尽量考虑到更多的边界情况，覆盖的情况越多，代码的安全性越高。
6、定期维护
随着业务需求的不断变更，有些单元测试已经过时了，不再能准确的测试函数功能，因此需要及时维护单元测试，确保测试的有效性。
7、测试驱动开发？
最理想的情况下是先写单元测试，再写实际代码来完成这个测试，这种模式叫做测试驱动开发（TDD）。
国外一些团队的实践表明 TDD 这种模式的确能降低 bug 数量，但是也带来了一些隐性的成本，比如过多的测试维护成本高，测试繁琐拖慢研发进度等等，因此对于这一条我打上了问号。
8、合理的覆盖率
单元测试的覆盖率取决于很多方面，不是所有代码都适合写单元测试，我对我个人项目的要求是，只需要为核心代码写测试用例就好，而且核心代码的单元测试率不低于 80%
这里每天分享一个 iOS 的新知识，快来关注我吧
本文同步自微信公众号 “iOS新知”，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！
