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

【问题标题】：Using DUnit from the Delphi IDE and avoid breakpoint on exceptions使用 Delphi IDE 中的 DUnit 并避免异常断点
【发布时间】：2011-02-08 10:16:07
【问题描述】：

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

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

我知道 SHIFT+CTRL+F9 快捷方式无需调试即可运行，当我记住时这很棒> 来使用它，但我经常发现自己按 F9，然后发出咕噜声，然后关闭测试应用程序，然后按 SHIFT+CTRL+F9。真是浪费了时间。

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

提前致谢。

【问题讨论】：

+1 在这里相同。如果可以使用编译器标志禁用此行为，那就太好了。类似{$DoNotBreakOn EArgumentException}
程序已经支持“不调试运行”和“语言异常通知”开关。这些是做你需要的正确方法。如果你按照 Smasher 的建议添加编译器标志，那么想想当你想调试时它会有多烦人，但你不能。
正如大卫建议的那样，您可能希望能够在不调试的情况下运行，而不是在不调试的情况下运行。如果您想在没有调试的情况下运行，请在没有调试的情况下运行。如果你的大脑习惯是问题所在，那就去研究大脑的习惯吧。我被卡住了，就像你被卡住一样，这对我有用。
@Smasher：我不确定编译器标志是否是正确的方法，因为 David 是对的，如果您想稍后调试它可能会很烦人。 @David：在当前状态下确实是正确的方式，但可以改进。我正在考虑 XCode，其中编译按钮会根据您的最后一个操作而更改，在没有或有调试的情况下进行编译。也许每个项目的可配置编译按钮可能是这里的解决方案。 @Warren：我的大脑是问题，但作为一名开发人员，我习惯于尝试找到解决这类问题的方法，而且似乎我的大脑并不孤单；）

标签： delphi debugging dunit

【解决方案1】：

没有（至少直到 D2009）。在没有调试的情况下运行是 IDE 的事情。编译器标志无济于事，因为它是挂钩 exe 的 IDE，而不是相反。唯一可以有这样一个选项的地方是在项目设置中。但是拥有它可能会使 IDE 有点混乱，因为 Run 和 Run without debug 之间的正常区别将被否决。然后我猜你需要第三个选项，“运行”、“运行调试”和“运行不调试”，其中简单的“运行”将从项目选项中得到提示。

【讨论】：

你的回答是最完整的，所以我接受它。第三个选项正是这种情况下需要的，正如我在上面的 cmets 中提到的，这就是 Apple 在 XCode 中所做的事情，也许 Embarcadero 可以实现这样的选项。无论如何，谢谢。

【解决方案2】：

将无需调试的运行图标添加到工具栏。您的问题是您忘记了热键，然后单击图标。所以删除另一个图标，或者将它们都移动，像这样：

我发现，您的应用程序越大，调试器启动就越慢。我现在大约 99% 的时间都在不调试的情况下运行，因为我的应用程序的启动时间从 2 秒变为 2 分钟，因为它使用了很多运行时包，并且调试器中的每个 BPL 负载都对我的生产力。这么长时间，缓慢的痛苦经历重新教育我问自己“我真的需要调试吗？”。如果我不这样做，我单击漂亮的绿色图标（在 XE 中），它替换了旧版本中的感叹号图标。（我认为这是一个智能 UI 改进。）。在以前的 delphi 版本中，绿色的播放按钮表示“运行调试”。

【讨论】：

2 分钟启动？哎哟!调试器在做什么？
我同意大卫的观点，2 分钟太长了。也许您应该考虑为您的开发机器添加更多资源。关于图标，我从不使用它们，所以这个技巧不起作用：我总是使用 F9 键，这就是问题所在。
那台机器是带有 16 gigs ram 的 core-i7。 CPU 进入“14%”（单核 100% 使用率）持续 2 分钟。更快的 PC 无法解决这个问题。这是 IDE 内部的设计问题。

【解决方案3】：

禁用“语言异常通知”。

【讨论】：

它适用于所有项目，但这不是解决方案，因为我只需要它用于那个特定的测试项目。无论如何，谢谢。

【解决方案4】：

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

【讨论】：

不幸的是，我没有强制任何异常，它们是由测试代码本身触发的。所以这行不通。

【解决方案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's 对如何再次启用这些异常的担忧。您需要做的就是禁用断点以再次报告所有异常。

其他想法：

你提到：

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

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

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

基本上，我觉得你的措辞暗示“一堆你不太关心的例外，因为它们是'处理'的”。许多人错误地认为他们是在处理异常，而实际上他们只是在吞下它们并隐藏根本问题。

【讨论】：