工作从测试开始。

在每个开发人员的生活中，都会有片刻他想为自己的创意创建测试组件的机会。 在每一个优秀的开发人员的生活中，我都会变得更好。 当您是初级用户且不承担任何特殊责任时，您有权犯很多错误，您可以随时纠正它们。 您不对自己创建的产品负责，也没有动力花费额外的时间仔细检查生成的代码。 “什么都没有，这个门框无法复制”，“这东西似乎起作用”，“至少，它确实满足了它所需要的功能”-如果您想超出程序员托儿所的水平，则必须否定所有这些想法。

随着您自己编程经验的发展，您将拥有越来越多的全新酷/大客户。 您甚至会对其中的一些（如果幸运的话）感到高兴-人们很好并且慷慨地付出，并且对出现的问题不挑剔。 让我们看一个这样的简单案例（非常简单，但是背后的主要问题），它是由一个不知道麻烦的程序员创建一个表单处理程序的。

因此，简单的任务到了-编写表单处理程序。 目的是接受客户购买砖块的申请。 客户很大，他要大量散装地运送砖块（例如，为了感觉到至少要承担一定程度的责任，要支付500,000卢布以上）。 竞争非常激烈-如果客户在一天之内不响应，则可以迅速联系砖块供应商。

我们的程序员被告知，有必要从表单中保存客户数据-代表姓名，电话号码，客户企业名称，订单量和可选的订单描述字段。 Porakinin大脑很快就创建了一个简单的表格，其中包含网站前端的标准字段：



表单中的数据通过AJAX请求发送，而无需重新加载页面。 此外，程序员负责表单处理程序的设计，他需要应付一个相当琐碎的任务-将新客户的条目添加到已经存在的订单表中，并向客户发送一封电子邮件，其中包含有关新客户的通知。



表格有效，数据成功保存，客户满意。 但是突然之间有一个来自客户的愤怒电话：“他们这么说，订单到了-百万富翁公司想从我这里购买所有砖块，但是电话号码不是来自表格，我现在该如何联系他们？！ 明天他们将找到另一个供应商！ 你是怎么做到的？ 是你的错...” 客户流泪和折腾，不安，不安，不安，不安。 对于初级用户而言，这种情况非常标准-无需对表单中的传入数据进行任何验证和测试。 通过添加验证规则，可以非常简单地解决第一个任务（验证）：



此后，站点客户端将仅指示我们需要进一步处理的正确数据。 在同一阶段，开发人员具有测试代码的想法，以进一步避免这种尴尬的情况。 例如，测试姓氏字段将如下所示（为简化基本示例，禁用了csrf保护）：



我们知道，在没有此字段的情况下，代码应返回错误并由我们指定状态为400。针对每种特定情况（或特定的字段验证，都取决于任务和开发人员的想象力）规定了此类测试方法。

但是，开发方法是否不同于“我做了，但现在我要检查”？ 我们首先编写代码，偶然发现执行障碍，对其进行修复，然后记住测试。 鉴于失去了数百万的客户，这种方法可能对我们和我们的客户有所偏颇（尽管从理论上讲，所有此类客户都是这样）。 然后我问自己一个问题-如果我们从另一端开始创建应用程序的逻辑呢？首先我们对“执行者”提出要求，然后使它满足这些要求？ 让我们尝试一下。

我们像以前一样保留任务，只更改方法。 我们需要编写一个表单处理程序，其中包含字段fio，phone，corp，quant和content。 成功执行的结果是状态200，向订单添加消息“ ok”的字段，并返回输入记录中的数据，其他选项-状态400和错误列表。

首先，我们需要编写一个测试方法来有效地填写表单数据：



接下来，创建必要的路由和控制器方法（当为空时）。 如果我们现在运行测试，则可能会出错。 验证有效数据并不是我们所需要的。 现在，我们开始测试表单字段验证。 我们确定哪些字段是必填字段-fio，电话，公司，数量，并添加一种验证方法（注释为可选）：



表单处理程序将只需要检查传入数据，例如电话，公司，数量。 由于我们从请求中删除了所有必填字段，因此应该为每个错误字段返回错误错误。 如果其中至少有一个不存在-执行问题。 如果需要，您可以像以前一样添加检查邮件的信息（检查“确定”）。
我们将检查fio，phone和corp字段的最小长度（将对这些字段的最大长度和无效字符进行类似检查）。



我们的检查已经到位，您可以运行并检查



太好了 我们的应用程序在5个测试中有5个崩溃了。 我们的进一步目标是通过测试方法来为字段设置无效值，并为传入数据形成验证规则。 逻辑是这样的：fio字段不能为空； 长度不小于3且不大于120； 这是一个字符串，其中包含名称中允许的字符集（字母，连字符，缩进）。 此逻辑在所有字段中的结果：



作为对文件的响应，已添加了错误列表，这些错误列表对应于每个“问题”字段的错误。 这将帮助我们检查特定字段以进行验证（测试文件中的assertJsonStructure）。 接下来，我们添加验证方法并获得最终版本：



最后，我们可以检查脚本如何进行测试（我记得，在5个测试中有5个失败）。



如您所见，所有测试均成功通过，并且只有一个条目输入了数据库（因为只有一种方法被配置为可以正常工作）。



有什么发现？ 从测试开始的应用程序开发是比通常编写功能更好的选择。 仅从方法中获取所需的需求就可以与军队纪律相提并论-该代码完全按照您的要求行事，而不是退一步。 但是，这种方法具有不利的一面（尽管有争议）-事实是编写附加功能（正在测试）也需要花费一些时间来开发项目。 对我来说，选择很明确-优秀的程序员应该编写测试，而从测试功能入手有助于编写功能良好且可靠的项目。 我将尝试在一些不那么琐碎的方面使用它。