一段时间后，我们的培训期间，我们的教师投助了我们一个假设的问题：
您的数据中心是在火灾中，您的所有应用程序代码都在一个驱动器上，您的所有测试都在另一个驱动器上，您只能救出一个驱动器。你做什么工作？
最近，出于好奇心，我在Twitter上投球了同样的问题。在Twitter上，大约80％的受访者表示，他们会保存申请代码，20％表示他们会保存测试。
人们给出了不同的原因。可预见的是，许多受访者表示让它全部燃烧，有些人试图通过断言他们有备份来证明这种选择。但＆＃34;让它全部燃烧＆＃34;没有提供的选项之一，这些响应没有出现在结果中，所以我们现在可以安全地忽略这些意见。
大多数剩余的受访者似乎根据自己的假设基于对实际进行详细和具体的假设来做出决策。有些人说，在不知道关于测试的情况下，不可能做出决定。有些人说要保存应用程序代码，因为其他驱动器包含其测试，将是空白的，或者至少包含任何价值。有些人表示他们会保存申请代码，因为虽然测试可能存在，但甚至是非常强大的，它们不会指定足够的应用程序和＃39; S行为，以便进行重新创建申请。有些人补充说，他们会尝试从已保存的应用程序代码库重建测试。当然，这也涉及关于申请的可测试性的显着假设。
但是，有些人认为，他们的测试将令人遗憾地足够令人遗憾地重建从测试代码中的应用程序会更容易。
因此，这一切都是为了娱乐讨论，它在原始培训课程和推特期间产生了一些有趣的结果。
询问这个问题的教师＆＃39是关于测试驱动的发展和具有良好代码覆盖的主张。如果您有足够的详细的单元测试，我们被告知，那么应用程序的结构是如此清楚地指定了从测试中重建原始应用程序的单位测试或多或少地进行了微不足道的。事实上，它是最小阻力的路径。因此，您应该拯救单位测试。而且，您应该遵循适当的TDD实践，并始终具有良好的代码覆盖范围。如果你这样做，它就没有，如果申请被吹走，那么你可以很容易地重新开始。
在培训课程中，我们都发现这是非常令人信服和有洞察力的，我们在同意中点头，了解课程。
显然，所呈现的实际情况是荒谬的。为什么测试和应用程序代码将保持在两个单独的离散驱动器上，并排在同一数据中心并排进行？你为什么要在那些确切的时间内在数据中心，并且面对这些具体的驱动器，并选择只有救援人员的选择？如果这种情况实际上发生，那些偏转了这个问题的原始受访者都有正确的答案。它＆＃39;火灾。你刚刚出去了。您的皮肤价值超过任何软件，都有备份，或者至少在其他开发人员上的本地副本;机器。
因此，这种数据 - 陆上情景显然是其他真实场景的代理。但是真正的情景是什么？
为什么能够从其单元测试中完全重建应用程序有用或希望是有用或希望的？什么，以及如何在销毁申请和单位测试幸存下来的情况下？
有很多真正的案例，测试获得＆＃34;丢失＆＃34;因为忽视了。或者他们永远不会写的地方。我猜这是因为火灾情景类似的选择，你有有限的软件开发资源，而且你没有时间做你想做的一切，所以有些东西会被忽视。
但如果是那个＆＃39;我们的情景，我们是在说（1）之间的选择，维护应用程序和（2）维持测试，我们应该始终保持测试？因为，如果测试足够严格，我们可以随时提取杠杆并使用这些测试来产生工作申请？
这可以＆＃39; t是它。它真实的，应用程序代码和测试之间的开发时间通常不均匀地分裂（以及十几个其他东西）。和它＆＃39;如果平衡通常可以从测试的方向转移。但是你可以＆＃39; t只有测试，没有申请。您可以＆＃39; t刚刚编写了一个新功能的测试，并声明要完成和交付的功能。你可以吗？
（在某些协议或规范中，您可能正在开发标准化测试套件的狭窄和罕见的情景，其中测试套件本身是产品，但是从传统的软件开发中提供全部其他球比赛。我会称之为题外话。）
所以，随着这些讨论的娱乐活动，我们在这里实际学习了什么？任何事物？
我们可能会意外地学习与预期课程相反。奴役遵守TDD，以及穷举的单元测试的维护，使得如果应用程序代码丢失，则可以毫不费力地再生，是毫无意义的，因为从来没有发生过。
如实，我认为强大的单位测试具有很大的价值，但是整合驱动器的这种寓言不会照亮那个价值。我不认为单位测试需要这种详尽无遗。我认为TDD有价值，但它只是一个工具，而不是一种生活方式，而且通常不会留在工具箱中。
也就是说，我确实认为，一旦你到达了在观看了应用程序代码并照顾了测试之间做出决定的地步，事情已经出错了。它们应该是不可分割的，保持在一个寓言驱动器上。我们应该拒绝承认两者之间的区别。我们应该拒绝接受或维护，没有另一个。
您的数据中心是在火灾中，您的所有应用程序代码都在一个驱动器上，您的所有测试都在另一个驱动器上，您只能救出一个驱动器。你做什么工作？
那里！我是一个人的意见，可以安全地忽略，完全应该是。
我从未见过一套单元测试，我可以习惯于跨越真正的应用程序。那是人们做的真实事吗？我希望测试开发工作需要天文学。
我2个月前，完成了整个服务的重写，因为我们有理由。 我从前一个服务中禁用了测试，直到靠近尾端，然后将它们转向验证它会表现相同......发现了一些错误，但其他令人惊讶的是无痛 不太储蓄测试......我有一个openapi.yaml，描述了每个端点应该做什么......但除此之外
您已被非法打开了贝壳的竞争对手和＃39; S CI服务器，可以删除其应用程序代码或其测试套件的Zip。一旦您的会话从磁盘读取其中一个文件，将被检测到，并且您可以赢得＆＃39; t能够触摸其他文件。 你偷了哪一个？
只对假设情景说话，而且关于TDD的优点，或者＆＃34的案情。作为文档测试和＃34; （我会打电话给单独的考虑），我会称为： ＆＃34;您收到了一个通知，即包含备份的数据中心已被销毁。作为预防措施，您立即插入冷库以运行例行验证。正如该过程确定您的驱动器要腐败，您会收到您的主要数据中心也在火灾中进行通知。你已经与之相关的，因为你几乎总是是，因为项目的敏感性意味着所有开发人员都在远程上工作。作为负责冷存储备份的人，您当然是这些规则的例外，因此您立即开始将文件复制到本地系统。 你首先复制： - Toplevel目录，希望您在连接失败之前获得足够的重要位 - 文档/规格 - 测试 - 应用程序
在你＆＃39; VE＆＃34;重建代码＆＃34的时间，测试是多么好的测试。从测试你＆＃39;重新出售。没有测试的运行代码赚钱。没有运行代码的测试Don＆＃39; t。
出于某种原因，这让我在神经网络生成的代码中。这可能导致您有一堆测试的情况，拉动杠杆，获得另一个潜在可行的代码，并使用现有的测试（必须是*彻底的*彻底），然后衡量其他一些健身。 也许在未来的程序员中只会成为人类请求和机器可读测试之间的翻译，然后机器人脱离并编写通过测试的代码。 （当然，您可能刚刚结束[覆盖函数==返回true]那么它会导致所有测试通过）
这是＆＃34的代理;大爆炸＆＃34;重写。示例：电子医疗记录的后端应用程序太慢，因为您的数据库架构是垃圾。你＆＃39;在过去的十五年里，你的数据学到了很多关于你的数据，并且现有的系统可以＆＃39; t容忍任何更多的调整。但是你＆＃39;如果迁移是完美的，那么，如果迁移是完美的，那么纪录的记录和人们将死亡。您如何确保迁移到新的DB架构才能正确？您可以冻结架构和存储层（让应用程序代码刻录），写作尽可能多的测试（拍摄测试代码），而不是释放您的新数据库代码，直到测试所有通过（使用测试重建应用程序）。 显然大爆炸重写aren＆＃39; t一个好主意（c.f. https://lafkblogs.wordpress.com/2014/06/22/big-bang-rewrite/），但有时你可以＆＃39; t周围。
移植到新语言，是一个。您的测试需要足够简单转换，但随后它只是一个验证产出没有变化的输出。
如果您可以从测试中重建软件，这意味着您的软件架构在这些测试中被编码。 由于架构权是典型软件开发的最难部分（缺少一些边缘案例），这意味着您实际上有任何测试，因为您声称的代码是您的测试实际上是一个开发平台（具体而言，您正在开发架构的平台），您可能应该为您的架构开发平台写一些测试。 （这是我的主要牛肉与TDD实际上 - 你可以＆＃39; t让测试驱动开发，因为最重要的开发部分可以像那样测试）
我在这里谈到了无知，但如果（好的）测试的价值是它们允许你重建原始应用程序，那么我们将原始应用程序定义为真实的价值？所以它将至少有意义地保存应用程序？ 此外，如果我们在现实地看待这个，那么甚至非常好的测试仍然是又好的＆＃39; t完美，并且可能不会完美地重建原始应用程序的能力。但如果您保存原始应用程序，那么，嗯，您有原始应用程序。
只要添加到混合中，我最近读到了一个可以从代码生成测试的AI工具，以实现实际的完整覆盖范围。测试甚至是人类可读的。当然，他们不证明你的现有代码是正确的，但它确实使您用任何给定的提交更改了明确的所有行为，因为之前的座位现在“失败”。 我认为这是一种为日常开发和重构提供全面覆盖的方式，也偶尔也是一个系统的某些部分的大爆炸重写是不可避免的。 这是我想到的另一件事：对于大幅关键的应用程序，可能需要使您的功能甚至依赖于特定公司的整体*云*。想象一下，如果AWS下来，你可以切换到IBM或Azure，你知道你有完全等同的功能。或者，您只需切换到任何在任何特定时间就可以有效更便宜，特别是如果您的供应商意外地颠簸了价格..没有供应商锁定。 您针对两个/所有实现运行的完整测试套件可确保功能等效。
Whybird引发了＆＃34;云不可知论的诱惑思想＆＃34;哪个是你能做的事情，但你在那点利用你的云平台，只需用它只用作＆＃34;一个运行VMS＆＃34的地方;最多可能＆＃34;没有利用平台＆＃39;允许结构和身份管理＆＃34; 这完全是你能做的事情，但它将是，最重要的是，在大多数时间内最终效率低下，偶尔会储蓄。 而且你仍然需要一种足够便携式的站立基础架构的方式。所以，你＆＃39; d需要将自己的基础架构规范语言和编译器写入多个不同的后端格式（或者只是多个不同的地形文件文件，也可能是＆＃39;在这一点上的交叉供应商的最广泛的跨度） 。
对现有的Codebase构建测试套件，然后将火灾设置为原始码布是一个充分的清洁室逆向工程描述。
超级简单。如果测试在另一个驱动器上，则无法维护或运行测试，并且完全无价值。 另一方面，应用程序的源代码可能只是有点腐烂，缺乏最新的测试。
我的代码几乎与测试密不可分，因为有断言和完整的Sanity检查全部。所以，我猜这意味着我＆＃39; d去参加代码？
查看Rubyspec可能是有益的，这是Ruby编程语言的一组测试。其存在是实施若干替代实施的Ruby，包括Rubinius，JRuby和Ironruby。 https://en.wikipedia.org/wiki/rubyspec.
这感觉就像一个问题，＆＃39;唯一对开发人员似乎有意义的问题，而不是操作或德文 - *课程*你＆＃39; d保存了应用程序，所以你可以恢复灾难并再次上升，比你快得多必须从测试场景中重建应用程序 - IFF甚至远程逼真的可能性。
我的答案与Hobbs相同：如果您保存测试，则您没有代码，因此在您重建时没有业务。同时，如果保存代码，可以在重建测试时保持和运行。 我相信这一假设场景背后的动机是代码重写（例如在另一种编程语言中）。在这种情况下，问题很有意义：当你宁愿有测试或原始代码重写以另一种语言的代码库？
测试可能是不完整的，代码可能有bug。真理的唯一来源是规范：那个＆＃39; s允许您确定错误的行为。只要这部分项目是安全的，一切都会好的（但昂贵）。 我会保存代码，我们*知道它＆＃39;自＆＃39; live＆＃39; l live。我们还知道代码是可测试的，因为我们在大烧烤前测试了：D 测试是一个工具，没有什么比＆lt; 3 ps：作为antispam作为-1的平方根，因为antispam是奇怪的：不确定每个人都知道/记得它（我没有＆＃39; t：d），询问机器人解决方案; p