通过创造混乱来进行单元测试竞赛条件（快速）

多线程竞争条件不会始终如一地发生，这使得它们很难重现。 另一方面，最佳软件实践要求我们编写自动化测试以验证我们的更改。 我将分享我的技术来创建足够的混乱，以使那些罕见的崩溃变得足够可靠以进行测试。

什么是比赛条件？

如果您有多个线程试图同时变异和访问数据，可能会发生不好的事情。 一个线程可能会更改一个值，而另一个线程正在使用它！

避免这种情况的最好方法是以不可能的方式构造代码。 Swift的结构是一个很好的起点，因为它们是在写操作时复制的（额外的功劳：从功能上考虑！）。

但是我们不能总是做理想的事情。 我们在现实世界中发展，但我们的控制范围之外。 也许我们陷入了遗留代码库。 也许我们没有时间或金钱来重构所有东西。 有时，我们所能做的就是实施最佳实践。

最佳实践之一是： 修复错误时，编写一个可重现该错误的单元测试以防止退化。 通常这是直截了当的，但是这些竞争条件崩溃可能很棘手。 它们很少出现在崩溃报告器中，并且您从未在设备上看到过这种情况。

让我们崩溃

首先，设置一个包含一些不安全代码的简单方法：

不料？ 更像预期的那样。 现在，您可以修复它，并且可以放心，将来的更改不会使它恢复正常。

肖恩每天在 Livefront对抗 混乱 。