重现错误的责任

我正在使用另一个程序员（他在同一家公司工作）制作的库来开发程序。最近，我在库中发现了一个泄漏，该泄漏在某些网络条件下运行了几个小时后才发生。我提交了一个错误，并附有导致此泄漏发生的条件说明。该开发人员回答说，“这还不够”，“重现错误不是他的责任”，我必须创建单元测试来重现此错误，否则他什么也不做。

1. 是吗
2. 在这种情况下我能做什么？创建单元测试是不可能的，因为它取决于一些随机的网络时间。

他说得对吗，可能是一个不了解您的公司就无法真正回答的问题。但是，他当然不是很有帮助。

我会向他提出错误（您已完成此操作），如果这会导致您的项目出现问题，那么我会与您的项目经理一起将其作为阻止程序，并非常清楚地说明您已适当地提出了该错误人，但如果未及时解决，它将影响您的项目。

我也将与开发人员进行交谈，并解释为什么创建单元测试不可行，但是您很乐意将其显示在您的计算机上（假设这是可行的？）。

他100％正确地指出，您必须提供足够的信息以使该错误可再现-否则就没有机会找出他提供的任何修补程序是否真正起作用。

但是-他恕我直言100％错误，这一定是单元测试的形式。如果您可以以某种方式描述测试方案，以便他可以重现故障（至少在合理的时间内有很高的可能性，或者通过手动测试），那么您就有问题存在的证明-这应该使您的同事感到满意负责修复它。当然，如果您能够创建一个可以更快地重现该错误的方案，那对他会有所帮助。理想情况下，将对此进行自动测试，这取决于您的组织对此负责。

双方都应该付出一些努力。

即使没有单元测试，图书馆开发人员也应该付出更多的努力，因为某些问题无法通过单元测试重现。有时是硬件，有时是程序其余部分中某些特定的正确操作序列，这会使库产生不好的结果。

您应该付出更多的努力，因为毕竟这不是库中的错误，而是程序其余部分不正确操作的结果（例如，损坏的堆可能会使任何库表现异常）。因此，尽可能地减少错误复制所涉及的非库代码是有意义的。与不熟悉您的应用程序代码的人相比，您可能会更快，更干净地进行此操作。

如果库的作者无法根据您的报告重现该错误，那么指望他花大量时间在此上是不合理的，更不用说修复它了。

但是，您花在开发与您的兴趣相关的产品上的时间也很有限。不幸的是，这可能意味着该错误继续存在，并且没有任何工作来解决它。

幸运的是，这并不一定是灾难。尽管在理想情况下，所有软件都不会出现错误，事实并非如此，因此我们必须根据它引起美国的问题来确定优先级。

这意味着如果您要解决的话，开发一个可重现的测试用例确实是您的责任。您可能并不在乎它是否已修复，在这种情况下，您已经做了所有可以而且应该期望得到的一切。您可能希望将其修复，但不足以花费时间使其在此时可再现。这是完全可以接受的。

在必须处理故障时尽其所能报告错误只是一种良好的公民身份，除非您的程序有此必要，否则您无需超出此范围。而且即使在那时您可能也不想这样做，可能还有另一个库可以使用，或者可以在合理的时间内滚动自己的库。基本上，由您来决定对您来说值得什么和什么样的努力。

我倾向于暂时让躺下的狗撒谎-您提出了问题，并且分配给了他。大概有适当的流程来跟踪未解决的错误并追逐这些错误？

如果您希望进一步积极地进行下去，建议您与您的经理联系，以查看是否有可用的测试工具可以可靠地重现该问题。

从开发人员的角度来看，鉴于您已提供了必需的信息，因此对它们不采取任何措施将是非常惰性的。但是，他们可能有大量的工作量，因此无法花时间跟踪问题。

您发现了一个错误，并报告了该错误，而他对此很讨厌。

如果你们两个是亲密的朋友，他本来可以做些帮助的，但他宁愿把问题再推回去。

您可以执行更多操作，方法是报告更多详细信息，并尝试证明它正在泄漏内存。尽管如此，您仍然有自己的责任，需要完成自己的工作。

尽可能多地将信息记录到错误跟踪器中，然后继续。

如果您以后再见到此人。友好一点，尝试谈论共同的利益，并了解良好的关系是更有效解决问题的方法，那么您可以提供任何数量的事实来支持索赔。

通常，我在类似情况下遇到的一个假设是，应该修复所有错误，并且虽然值得赞赏，但这绝对是一个伟大的目标（让我们面对它，我们从未着手编写错误！），这最终是不现实的任何大小合适的项目，仅因为它是一个错误（如果您可以找到它），就可以修复错误。这就是我们拥有项目管理以及编码方法，模式和实践等的原因。

因此，在图书馆所有者的辩护中（我从事某些大型项目时就是这种情况），我要说的一件事是，开发时间会花费金钱并且是一种有限的资源，因此决定如何处理报告，由谁进行调查，进行/需要进行哪些测试，以及最终（如果有的话，何时）实施修复程序，完全是基于业务影响。如果一次重新启动长时间运行的进程失败，将会产生什么影响，而您是否可以轻松地自动执行该进程（也许您不应该将其作为防御性编程措施吗？）只是时间还是更多呢？ ？

还要从他们的角度看待它，一个用户的错误报告会报告一些代码中无法预测的问题，这种情况很少发生，仅与他们的代码结合使用，可能仅在一台计算机上并且仅在一组异常时间下发生如果有可能的话，条件将不会有大量的开发时间来寻找和修复。但是，如果这是一个足够强大的业务案例，使该用户希望/需要花时间进行更彻底的调查，并提供可靠的测试案例/应用程序，或者比其最初的案例提供了更为详尽的问题描述，那么可能完全是另一回事。

图书馆所有者可能没有考虑过这样的交流问题，如果您有强有力的业务案例（例如您的代码对企业而言成本高昂，有法律合规性要求，安全漏洞或有某些问题，其他重要的连锁效应），现在是时候将其踢向管理层，让他们与之抗争了。

您已经提到“我提交了一个错误，并附有导致这种泄漏发生的条件说明”。

如果您确定描述确实足以重现错误，那么您已经知道确切的条件。现在，如果您在知道条件后就无法编写单元测试，那么这显然意味着您无法模拟其中涉及的某些组件，或者某些代码部分过于紧密，以致无法创建实用的单元测试。

您应该要求库所有者重构代码以允许您创建单元测试。您将必须清楚地解释库中阻止您创建单元测试的内容。他将不得不重构代码，否则将承认当前代码无法进行单元测试。两种方式都可以赢。

如果这不起作用，则可以使用以下选项：

• 您可以使用更多证据重现错误。
• 尝试让上级主管介入，并请他/她评估您的证据。
• 尝试在具有模拟环境的原型应用程序中使用库，使其仅被编码以重现错误。这样，您至少可以证明该错误存在。