现在该地区的故事then即将结束，我们将行动的结果与我们之前对故事的期望进行比较。诚然，这不是一个特别令人兴奋的故事，因为我们提前做出了假设，这些假设应该在故事结束时实现。但这正是我们在单元测试中想要的：满足期望。最终，一个好的单元测试应该像一个简单的故事一样容易理解。因此，不应该有任何突然的站点故事（代码中的跳转）迫使我作为读者在故事中来回跳转以了解更大的图景，而是我只想从上到下阅读单元测试底下，可以理解。
可重复我们的单元测试应该能够在不同的环境中频繁运行，并且对于相同的输入始终产生相同的结果。这意味着单元测试
无论环境如何
总是返回相同的可理解的结果。
S-自我验证
单元测试旨在以编程方式评估结果。我们不想在每次测试执行 厄瓜多尔 whatsapp 数据 后自己评估结果，例如通过查看日志文件。特别是经过充分测试的项目可以轻松进行数千个单元测试。想象一下必须通过如此数量的单元测试手动评估结果。此外，单元测试应该给出明确的和二元的反馈，即“success或”fail并且没有介于两者之间的反馈。有时世界只是黑与白，或者红与绿。
T - 及时/彻底
Robert C. Martin 将 FIRST 中的“T”定义为“及时”。这意味着单元测试应该在生产代码之前编写。这使得编写单元测试变得更容易，并且生产代码不可避免地变得可测试。从一开始就编写可测试的高效代码比已经有一个迫使您使高效代码可测试的单元测试要困难得多。
随着时间的推移，除了“T”之外，另一个原则也悄然出现，即“彻底”。 “彻底”就是“彻底”的意思。所以我们彻底地编写了单元测试。我们通过编写测试用例来实现这一点，不仅为成功案例，还为错误案例、边界案例和等价类编写测试用例。
下面的例子旨在说明这一原则的最终含义：
让我们来看一个著名的型（小型完整练习）“FizzBuzz”。任务是：
对于能被 3 整除的自然数，控制台上会打印“fizz”，
对于能被 5 整除的自然数，在控制台上打印“buzz”，
对于可以被 3 和 5 整除的自然数，“fizzbuzz”应该打印在控制台上，并且
对于所有其他数字，相应的数字本身应输出在控制台上。
我们还添加了仅计算 1 到 30 之间的数字的条件。对于超出我们的区间的数字应该抛出错误。
此任务现在会产生各种测试用例：
阳性测试用例
给出的是数字 2。当fizzbuzz 函数执行时，答案应该是“2”。
给出的是数字 3。当fizzbuzz 函数执行时，答案应该是“fizz”。
给出的是数字 5。当fizzbuzz 函数执行时，答案应该是“buzz”。
给出的数字是 15。当fizzbuzz 函数执行时，答案应该是“fizzbuzz”。
错误案例测试用例
给出的是数字-10。当fizzbuzz 函数执行时，应该抛出一个错误。
给出的数字是 310。当fizzbuzz 函数执行时，应该抛出一个错误。
限制测试用例
给出的是数字 1。当fizzbuzz 函数执行时，答案应该是“1”。
给出的数字是 30。当fizzbuzz 函数执行时，答案应该是“fizzbuzz”。
给出的数字是 0。当fizzbuzz 函数执行时，应该抛出一个错误。
给出的数字是 31。当fizzbuzz 函数执行时，应该抛出一个错误。
等价类覆盖测试用例
给出的是数字 6。当fizzbuzz 函数执行时，答案应该是“fizz”。