简介：测试驱动的开发（TDD）在理解中国的许多国内软件开发人员方面更加模糊，而且大多数人并没有清楚和有意识地实施TDD。因此，有一个说法：“练习是测试真相的唯一标准。任何结论的结论是，任何不容易通过实践的结论都是流氓。仅基于真正的经验，而没有适应，仅供参考
阅读前提：是的，有一点理解
案例：实现通用支持上限和下降 - down -down刷新的列表
使用示例进行整理：
一开始，只有三个用例被整理出来。为了集中精力，没有考虑所有场景可以被用例补充。首先，专注于这三个相对简单的案例。
尝试该过程：首先编写单个测试用例 - >使用的情况案例失败 - >写下最小运行单个测试版本以实现的实现
首先写一个测试
思考：目前尚无实施代码，这意味着如何编写单个测试以完全跳出特定的实现。怎么会简单以及如何来（没有模拟）。在这里，您甚至都不考虑合理性。
给定：首先，我必须准备一个，因为三种用例以不同的加载状态显示出不同的显示，然后我需要在重建中进行设计。
时间：加载和通行证的参数
然后：验证当前页面是否出现
代码实施：
用例操作故障
目前不得运行这种情况
首先，根本没有这样的小部件
其次，不可能拥有这个语义的小部件
编写最小值的实现可以运行单个测试版本
这样，以前的用例可以过去
思考：可以看出，当前的实施是挫败的。它与我们的功能性期望不符，而是只能通过用例传递的实现版本。根据我们的常规开发过程或习惯，我们可能不得不在实施时优化代码，请考虑各种代码边界条件，然后编写一个相对完整的实现版本。例如，在这里，我们可以习惯地定义各种状态的枚举，然后判断各种状态以实现各种状态的处理逻辑。这似乎很顺利。我们暂时不这样做。根据开发过程，在此步骤中，我们必须过早地优化代码以编写用法以外的实现。案例，即首先编写测试用例，然后写入实施
在这里我们可以忍受或调和，我们继续下降
首先写一个测试
有了以前的代码，第二种用例自然是在胃部，这也表明我们以前的设计迄今为止的测量得多。代码如下。
用例操作故障
增加了此用例后，现在进行单个测试：第一种情况是成功的，第二个情况失败了
显然，我们只意识到以前的加载状态，甚至没有判断参数，因此第二种情况必须失败。
编写最小值的实现可以运行单个测试版本
为了允许两种用例通过，现在我们必须加载判断的逻辑
这样，两个用例都可以通过
对于前两个用例和实施，在第三个用例中无话可说。添加判断逻辑。最终的单检验代码和实现如下。
这是一个小的单个检验小知识：使用一组相关案例将一组案例结合在一起，这将有助于对问题进行分类。
思考：我可以在一开始写所有三种用例，然后统一编译并意识到所有三种情况的实现吗？
这里的当前情况相对简单，三个状态具有很强的相关性，但是状态不同，因此可以写下这三种情况。如何控制粒度？我觉得这是遵守原则的：分裂的任务足以集中精力，而且不容易分歧。
例如，这里提到的三种用例有限，因此足以集中精力。假设我们已经写下了单个测试和降低的测试，并且一次降低了一个刷新。变得非常复杂，很容易导致单个测试通过单个测试。
继续改善功能，增加用例：加载成功，数据不是空的，列表显示相应数据的项目
写一个测试
思考：我们希望通过A，B和C进行。加载成功后，页面可以显示A，B和C三项。这次，先前设计的参数还不够。我们需要通过列表。在这里，我们暂时设计为数据类，其中包含一个状态和列表。
单个测试代码如下
单个测试操作失败
编写单个测试的最低实现版本
为了进行单个测试通行证，这不难实现。它只需要一个。使用传输数据作为参数，然后对其进行调整。
添加用法案例：如果仍然有下一页，则滑到最后一个项目时，请显示更多小部件
例子
单个测试故障
编写单个测试的最低实现版本
思考：合并一个字段，意味着是否仍然有页面；同时，当列表滑到最后一项时，返回加载小部件
范围
加载小部件是一个假数据，因此我们需要根据原始数据为 + 1；如果没有下一页，则不需要虚假数据和加载小部件。所以
实施代码如下
这样，刚刚写的用例就通过了。
但是，我们发现先前的用例“成功加载和数据没有空，列表显示相应的数据项”失败
可以看出，在以前的用例中，我们预计构建项目的数量为4，但实际上只有3个。为什么是这样？
在此之前，单个测试始终通过，表明我们刚刚意识到我们已经破坏了先前的用例。由于以前的用例，我们尚未引入我们，默认参数为。在实现中，我们认为，当我们返回加载窗口小部件时，而不是回调的参数。因此，我们仅注册了三次，这也导致先前的用例失败。
那么我们只需要添加一个判断
这种情况很容易出现在我们的日常发展中。当我们开发新功能时，很容易忽略某些边界或更改上一个逻辑。此时，开发过程中，您可以在开发过程中扼杀这个不良案例，这使我们能够提供更质量的保证代码
思考：代码评论可以轻松找到它吗？
连续增加功能：
从这里开始有一定的复杂性。以前的用例基本上是静态的（无状态）。状态是通过参数传递的，即状态是从一开始就确定的，没有更改的可能性。加载结束后的验证。
从列表中获得并触发了一种从外部返回的方法，以便我们可以判断何时结束
这种思维过程实际上是一个测量过程，可以帮助我们编写更多测量的代码。更测量的代码通常意味着设计更合理
这里忽略了单个检验代码（这不是重点），直接查看：
向参数添加功能并返回一个
确定列表何时滑到最后一项，触发此处
可以看出，这里有一个。为了在加载结束后进行更新，先前设计的饲养清单必须
在这一点上，我发现电流变得越来越沮丧。使用时，必须将其传递到数据的第一页中，然后再加载。简而言之，此设计对用户不友好
我们之前说过，不需要过早地重组。我们想重建或优化的是一些不优雅的现实。这次，我们要重建的代码将使整个框架更改。具体而言，构造函数将发生很大变化。因此，如果在此阶段，如果您不进行一些更改，那么将来许多案件（包括先前书面的案例）可能会被放弃。
所以现在，这是重建的更合适的时机
重建：简化构造函数，首次均匀加载，然后将加载时间移交给内部处理
执法保留的两个：
代码
在此处使用数据的第一页（请参阅注1）指示是否加载第一页。当触发器加载更多时，将其设置为并更新新数据时。目前，列表使用新的数据渲染列表（请参阅注释4）
可以看出，重建后，它比以前更合理，但仍然不够优雅。例如，每当您加载更多加载时，它都会重建整个小部件，这会带来很多不必要的重建，但是我们不再在这里焦虑。重建，我们的目的是简化构造函数。随后的重组仅经过修改和实施，不会导致结构发生重大变化。所以
由于重建已修改了建设性参数，因此先前的单个测试还必须对相对较大的重建进行再次运行。
之后，案例的写作基本上是平滑的。它不会在此处列出。当所有功能基本完成时，我进行了另一个重建。这次，我用它来减少不必要的不必要的。RE-绘制和制作代码逻辑更均匀。因为这次我只重组了特定的实现，所以我可以看到我对代码的实现进行了很多更改，但是单方面代码尚未移动
REDF屏幕截图的重建部分
单个测试没有改变
重建完成后，所有先前的用例
尽管重建更改代码非常大，但单个测试的结果使我感到放松
本文中涉及的所有代码都可以在这里移动以在此处检查
所有用例梳理：
实施代码：feed_list.dart
单个测试代码：feed_test.dart
覆盖率：