认真一点!
在谈到调整构建缓慢的代码的成本时，我提到了构建缓慢导致的延迟。
让我们定义一个慢速构建。
如果要花费超过4分钟的时间，速度将会很慢。
如果测试耗时超过30秒，那么它的速度也会很慢。
建造比这个家伙慢
我完全意识到，许多构建都比我的规定阈值慢得多。 关键是我们应该尽最大努力不容忍这些缓慢的构建，或者至少是缓慢的构建阶段。 我参与了每个构建需要30分钟的项目。
虽然可以并行测试多个分支，但将分支与主分支合并实际上是一个队列。 在我们的Sprint结束时，我们需要空中交通管制来使合并发生，因为在一个工作日内没有太多30分钟的封锁！
为什么您当前的构建如此缓慢？
嗯……含糊不清，与数据访问层和Oracle有关……含糊不清，客户端机密。
这里有趣的挑战是，有些服务与其他实际资源绑定在一起，因此要对它们进行有意义的测试需要一个真实的环境。 Docker让我们构建了这些环境，因此我们使用Docker。 然后我们的测试变慢了……同时是对还是错。
这完全取决于您对客户端层对实际服务的信任程度。 如果您完全信任它，则可以完全存根，只有在进行端到端测试时才对其进行测试。 但是，如果客户端层是软件的固有风险，或者如果您受到高级测试环境的限制，那么在构建中进行大量针对服务的集成测试可能是一件好事。
我认为这是一件好事，但这也是一件缓慢的事。 在这里很难两全其美。
今天我打破了周期
今天，我花了大约90分钟来构建内存数据库。 我本可以在现有的ORM层中使用H2，但这可能有用，尽管我怀疑它会引入一些奇怪的Oracle模式怪癖，而这可能会花费更多时间。
相反，我构造了在数据访问层中公开的相对简单的操作的内存中实现。 我进行了一些重构，以使其能够生成双重测试/伪造，而不是使用Mockito进行模拟。
测试双打/假冒是一个很好的工具。 如果构建正确，它们将是您为实际资源创建的接口的完美实现，但不会受到现实世界的限制。
在同一项目中，我（不是第一次）创建了内存版本的S3。 再次这是因为我有一个内部BLOB存储接口，该接口简化了该应用程序使用S3的方式。
我花了90分钟才能完成我的内存服务。 从真实数据库中将一些参考数据导入数据源花了几分钟。 然后花了几分钟写我想写的测试。
测试的目的是在我们要重写的现有系统与新系统之间进行100％的比较。 它产生完全相同的输出吗？
我需要能够调试正在运行的解决方案并一遍又一遍地重新运行测试。 我有针对真实数据库运行的测试，甚至还利用JUnit 5测试套件开创了一些技巧，以使我的测试可以针对本地长期存在的Docker映像或CI构建中自发创建的容器运行。
但是，目标是在几秒钟内一次又一次地运行测试，我觉得使用真正的服务会遇到麻烦吗？
它还清吗？
简短的回答：是的。
有一个错误。 它花费了许多时间进行调试。 实际上，当我将测试数据汇总在一起时，还发现我还有其他一些规范需要充实和检查。 我也发现了缺少的功能。
我遍历代码并在一个小时左右的时间内测试了约40次，然后一切正常。 如果没有可以在4秒内运行的测试，这根本不可能实现。
我拒绝创建数据库的内存欺骗，因为在创建数据库时，我确实需要看到数据访问层能够解决实际问题。 这些问题本来不可能在云中运行的应用程序中进行调试，并且会被内存中的模拟掩盖。
但是，每种技术在项目中都有其位置。 在这种情况下，我有一个完美的问题来进行双重测试。 面临的挑战是快速迭代，而模拟和伪造让您做到这一点。
通常情况下，人们都在模拟游戏之上，然后必须添加一些现实的测试来弥补这些空白。 我只是碰巧这次做了另一种方式。
翻译自: https://www.javacodegeeks.com/2020/05/seriously-how-long.html
认真一点!