使用 Delphi IDE 中的 DUnit 并避免异常断点

Question

我正在使用 Delphi XE，并且有一个包含主应用程序和 DUnit 测试应用程序的项目组。有时，我会转到 DUnit 测试应用程序添加一些测试并运行现有测试。

一些测试代码生成由应用程序处理的异常，但由 Delphi 调试器显示多次，因为我习惯使用 F9 快捷方式运行测试应用程序，就像我对标准应用程序所做的那样：这是在这种情况下不太方便。

我知道 SHIFT+CTRL+F9 快捷方式无需调试即可运行，当我记得使用时，这很棒但我经常发现自己点击 F9，然后咕噜咕噜，然后关闭测试应用程序，然后点击 SHIFT+CTRL+F9< /kbd>。多么浪费时间啊。

所以我的问题是：有更好的方法吗？我可以定义一些设置或使用一些专家来使该特定应用程序默认运行而无需调试吗？当然我不是唯一一个有这个问题的人。

提前致谢。

Answer 1

不（至少直到 2009 年）。无需调试即可运行是 IDE 的事情。编译器标志无济于事，因为是 IDE 挂钩了 exe，而不是相反。唯一可以有这样的选项的地方是在项目设置中。但拥有它可能会使 IDE 稍微混乱，因为“运行”和“不带调试的运行”之间的正常区别将被推翻。然后，我猜您将需要第三个选项，“运行”，“带调试运行”和“不带调试运行”，其中简单的“运行”将从项目选项中获取提示。

Answer 2

禁用“通知语言异常”。

Answer 3

将运行而不调试图标添加到工具栏。您的问题是您忘记了热键，然后单击了图标。因此，删除另一个图标，或者将它们都移动，如下所示：

您的应用程序越大，我发现，调试器启动速度越慢。我现在大约 99% 的时间都在没有调试的情况下运行，因为我的应用程序的启动时间从 2 秒到 2 分钟，因为它使用了大量运行时包，并且调试器中的每个 BPL 加载都会受到巨大的影响我的生产力。这么长时间、缓慢的痛苦经历重新教育我问自己“我真的需要调试吗？”。如果不这样做，我会单击漂亮的绿色图标（在 XE 中），该图标取代了旧版本中的感叹号图标。 （我认为这是一个智能的 UI 改进。）在以前的delphi版本中，绿色的播放按钮意味着“调试运行”。

Answer 4

嗯，有点。您可以使用不间断断点[McKeeth][Jensen] 忽略您在测试中强制执行的异常。据我所知，保存断点的唯一方法是启用“工具”>“选项>自动保存>项目桌面。

Answer 5

我理解您的问题，但我个人认为更改 F9 的默认行为的选项没有那么有用。

您有一些预计会引发异常的测试用例。 （注意：我实际上正在考虑在给出错误输入时检查特定异常的测试。而不是应用程序“处理”的异常。）我同意在大多数情况下。但是，其他测试用例中的异常将是我希望尽快收到警报的问题。

所以我首选的运行模式是通常收到异常通知。并且在某些测试用例中具有显式代码，仅在将触发生产代码异常的测试上下文中显式禁用异常通知。

我有一种非常有效的技术。

在预计会引发异常的测试中，我编写了以下代码：

begin
  TIDEDebugTools.DisableBreakOnExceptions;
  try
    //Test code ...
  finally
    TIDEDebugTools.EnableBreakOnExceptions;
  end;
end;

我猜您想要这两种方法的源代码？ :)

unit IDEDebugTools;

interface

type
  TIDEDebugTools = class(TObject)
  public
    class procedure DisableBreakOnExceptions;
    class procedure EnableBreakOnExceptions;
  end;

implementation

{ TIDEDebugTools }

class procedure TIDEDebugTools.DisableBreakOnExceptions;
begin

end;

class procedure TIDEDebugTools.EnableBreakOnExceptions;
begin

end;

end.

你问剩下的在哪里？
没有——就是这样！

...但是您需要遵循一些说明：

• 向每个方法添加一个断点。
• 编辑断点属性。
• 选择高级选项。
• 关闭“中断”选项
• 并打开相应方法的“忽略后续异常”和“处理后续异常”选项。

这接近 jpfollenius' 编译器指令选项的想法。它还解决了 David 的关心如何再次启用这些例外。您需要做的就是禁用断点以再次报告所有异常。

---

其他想法：

您提到：

一些测试代码会生成由应用程序处理的异常。

如果您的应用程序正在处理所有这些异常，那么：

• 您的测试是否足够本地化？如果您正在测试如此大的功能块，则测试更像是系统测试 - 并且可能非常难以维护。
• 您是否在主线业务处理中过多地使用了异常？
• 您的应用程序是否执行了大量不适当的异常吞咽？

基本上，我觉得你的措辞暗示“一堆你不太关心的例外情况，因为它们已经被‘处理’了”，这似乎很可疑。许多人错误地认为他们正在处理异常，而实际上他们只是吞下了它们并隐藏了根本问题。