编写可测试代码（iOS中的TDD示例）

在这个博客中，我将讨论编写可测​​试的代码，将解释我主要使用的两种方法，由您来决定最适合自己的方法。

我不是测试专家，这只是我高度使用的两种方法。 也许他们可以帮助您制定自己的首选方法。 这不是一个博客来告诉您您应该做什么和不应该做什么。

我鼓励您关心的唯一事情是将代码分开编写，使其易于阅读并遵循软件设计原则。

您可以在此处找到完整的模块。

meguid /可测试

这是我个人编写可测试代码的场所。 主要是TDD，设计可测试和重写的代码…

github.com

我们需要编写一个简单的iOS模块，以帮助用户登录我们的系统。 我们将首先开始编写测试，然后再编写代码以通过此测试。

使用协议，我们可以将模块中的每一层完全分开，因此我们可以对其进行测试，而不必依赖于其他层。 对于我们的登录模块，我们将有两个核心层。 “交互者”的作用是控制模块逻辑，从模块外部（例如视图）采取措施，执行所需的逻辑，然后更新演示者。 “演示者”的作用是根据特定的逻辑来更新UI，演示者不应在意操作背后的业务逻辑。 另一个注意事项，将核心代码（演示者/交互者）与UI（仅导入Foundation）分开是至关重要的

让我们从一个快速的文件“ SignInProtocols”开始，该文件将负责管理层之间的交互，并且可以在解释模块具体功能方面发挥重要作用。 首先，我们需要定义我们的模块输入（也就是我们的模块要做什么）。 因此，我们使用3种方法来定义“ SignInInput”协议来登录和验证电子邮件，密码。

清楚吧？

那么，谁将成为我们的模块逻辑专家？ 交互器。 因此我们需要将Interactor的输入定义为模块的输入。 因此，我们可以将登录模块输入操作委派给交互器。

现在我们需要定义Interactor输出。 是登录成功/失败还是电子邮件或密码有效。

目前很好？ 那么谁来处理这个Interactor输出呢？ 我们的UI大师。 主持人毫无疑问。 因此，像之前一样，我们将Presenter输入设置为Interactor输出。

现在，让我们定义演示者输出，在其中更新我们的UI。

最后，我们需要将模块设置为Presenter输出。

Interactor层将实现Interactor输入协议。

Presenter层将实现Presenter输入协议。

因此，现在我们定义了模块中的每个单元，我们甚至可以在定义各单元所需目的的层类（Interactor / Presenter）中编写一行代码之前轻松编写单元测试，以便我们可以编写测试。

我们编写模拟来创建一个伪图层，该伪图层实现我们的待测试层输出，以便我们可以验证我们的待测试层是否触发了正确的输出。

因此，在测试Interactor时，我们将模拟Interactor的输出协议，并在此输出中编写代码以配置标志，以便我们可以使用它来测试Interactor的行为是否

现在，我们准备测试Interactor的行为。

如果我们尚待编写的Interactor方法正确执行了此测试，则此测试将成功。

我们对Presenter也一样。

并测试一下。

我们做到了。

meguid /可测试

这是我个人编写可测试代码的场所。 主要是TDD，设计可测试和重写的代码…

github.com

第一种方法使您能够分别测试每个层。 第二种方法基于将模块的测试写为黑匣子。 因此，我们削减了Interactor和Presenter之间的协议，并使每个协议直接直接调用另一个协议。 因此，我们可以有一个具有登录方法的Presenter，然后Presenter调用Interactor进行业务逻辑，然后根据Interactor响应更新UI。

在这种情况下，我们的测试将仅使用与方法1中使用的测试用例相同的方法来调用“登录”和“验证”方法。因此，我们可以获得测试模块功能的相同总体结果。 但是第一种方法可以帮助我们更多地测试每种独立方法的功能，但这有点复杂，但是我尽了最大努力使命名变得方便。

注意：无论选择哪种方法，都应该开始。 对我来说，编写测试不仅是必不可少的，而且非常有趣😉