对于Objective-C来说 Unit Testing的价值是什么？

最大的问题是“对于Objective-C来说 Unit Testing的价值是什么？”

服务端的小伙伴会Mock整个数据库，仅仅为了测试一条类似于“Hello World” 的SQL语句。
在iOS中，你需要如此的仔细吗？这大概是不需要的。
你需要将单元测试覆盖到iOS项目中的每一行代码吗？这毫无疑问是不需要的。

那么，让我们来看下，你应该怎样决定你的测试计划。

单元测试有两个目的：

• 首先也是最重要的（从我的观点来说）它可以帮你保持类的小而精。
• 其次，它可以为你提供自动化测试，这是非常有用的。

为什么我这么说？
如果你尝试编写一个类去通过某个API来获取数据，你会从对它行为的一些猜测来开始开发。
使用这个类，会依赖这些假设。假如你过了几个月忘记这些假设是什么，那么如果你更改了关于网络请求的代码，你很有可能在某个地方改变了之前的逻辑。这些可能发生在你毫不知情的情况下。

你应该通过手动还是自动去测试你的App？它并不意味着你需要将单元测试覆盖整个APP，但是在发版本之前，你应该测试一些关键之处，那么为什么还要通过手动做这些呢而不选择自动测试呢？

Matt Gemmell 曾经写过“thou shalt suffer no bugs to ship”（发版时必须不要有任何Bug），我认为他说的很对，并且我也是这样做的 。他也说到，无论你用哪种机制去保证在发版时没有bug，你只是需要有一种方法。Unit Tests， UI Acceptance Tests, 或者所有的测试都通过手动解决（但是这将会花费大量时间）。 Unit Test 或者UAT更加迅速。

上面说的所有都是“对于Objective-C来说Unit Testing的价值是什么？”这个话题的开场白。
让我们来思考一个好的架构的iOS app。它被划分为三个部分： Model，View，Controller。

426D1328D1E744999A88979FAF12C2C2.png

我有说 three parts？ 我的意思是 three-ish（暂时没搞清楚什么意思🤣）。 App需要API 的调用，你也需要写网络请求的代码。有的时候，代码会从Model中分离，有时候也会包含在Model中，在可避免的情况下它应该从不包含在View中，或者包含在Controller中（这应该永远是可避免的）。

View和Controller自检的相互作用不利于单元测试— 这些地方UAT可以帮你解决这个问题。 这篇文章并不会涉及这些。

橙色的区域是单元测试最有作用的地方。Model和网络请求代码中。

你可以很容易的测试网络请求代码，去验证你第一次写它的时候关于它的假设。如果你的Model比较精炼，你可能不会去测试。然而，这些models可能在任何地方被创建和修改，所以，你应该确保测试这些代码。

综上所述：单元测试 Models 和网络请求代码。如果你觉得值得，那么用UAT去测试其他的。可能手动测试Views和Controllers更加适合你的工作，特别是在比较小型的app中。

最后，无论你用哪种测试，请记录它，并且编成文档。这样你就可以在发版之前手动测试它了。