使用Delphi IDE中的DUnit并避免在异常处设置断点

Question

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

一些测试代码会生成异常，这些异常由应用程序处理，但是由于我惯用的方式是像普通应用程序一样使用F9快捷键运行测试应用程序，因此调试器会多次显示这些异常信息，这在这种情况下不太方便。

我知道可以使用SHIFT+CTRL+F9快捷键来运行而不进行调试，当我记得使用它时，这很好，但我经常发现自己按下F9，然后咕哝一声，然后关闭测试应用程序，接着再按下SHIFT+CTRL+F9。这浪费了很多时间。

所以我的问题是：有更好的方法吗？我能否定义一些设置或使用一些专家使得该特定应用程序默认情况下无需调试即可运行？我肯定不是唯一遇到这个问题的人。

提前感谢您的回答。

- jonjbar

---

+1 我也是这样认为。如果能够通过编译器标志禁用此行为，那将是非常好的。就像 {$DoNotBreakOn EArgumentException} 这样的东西。 - jpfollenius

该程序已经支持“无调试运行”和“语言异常通知”开关。这些是您需要做的正确方式。如果您像Smasher建议的那样添加编译器标志，那么当您想要进行调试但无法进行时，您会感到多么烦恼。 - David Heffernan

正如David所建议的，也许你希望能够在不使用调试的情况下运行程序，那么就直接选择“Run without debug”。如果问题出在大脑习惯方面，可以尝试改变这些习惯。我曾经和你一样遇到过卡顿的情况，而这种方法对我很有效。 - Warren P

@Smasher：我不确定编译器标志是否是正确的方法，因为David是对的，如果您以后想要调试，这可能会很麻烦。 @David：在当前状态下确实是正确的方法，但可以改进。我正在考虑XCode，其中编译按钮根据您的上次操作更改，编译时带或不带调试。也许每个项目都有可配置的编译按钮可能是解决方案。 @Warren：我的大脑是问题所在，但作为开发人员，我习惯于尝试找到解决这种问题的方法，而且似乎我的大脑并不是唯一遇到这种问题的人 ;) - jonjbar

Answer 1

不行（至少在D2009之前不行）。无调试运行是一个IDE的功能。编译器标志是无法帮助的，因为它是IDE钩住exe，而不是反过来。唯一可能有这样选项的地方是在项目设置中。但拥有它可能会让IDE稍微有些混乱，因为正常的运行和无调试运行之间的区别将被推翻。你会需要第三个选项，“运行”，“带调试运行”和“无调试运行”，其中简单的“运行”将从项目选项中获取线索。

- Marjan Venema

---

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

Answer 2

禁用“语言异常通知”。

- Rafael Colucci

---

它可以工作，但适用于所有项目，这不是我需要的解决方案，因为我只需要针对特定的测试项目。无论如何，谢谢。 - jonjbar

Answer 3

将“无调试运行”图标添加到工具栏中。您的问题是忘记了热键，而点击了该图标。因此，请删除其他图标或将它们都移动，如下所示： 随着应用程序越来越大，我发现调试器启动速度会变得越来越慢。现在我大约有99%的时间是不带调试运行的，因为我的应用程序的启动时间从2秒变成了2分钟，因为它使用了很多运行时包，在调试器中每个BPL的加载都会对我的生产力造成巨大的影响。长时间、缓慢而痛苦的经历已经让我重新认识到要问自己“我真的需要进行调试吗？”如果不需要，我就会点击漂亮的绿色图标（在XE中），它取代了旧版本中的感叹号图标。（我认为这是一个聪明的UI改进）。在以前的Delphi版本中，绿色播放按钮表示“带调试运行”。

- Warren P

---

2分钟启动？哎呀！调试器在干什么？ - David Heffernan

我必须同意David的观点，两分钟的时间实在是太长了。或许您应该考虑为您的开发机器添加更多资源。至于图标，我从来不使用它们，所以这个技巧对我没用：我总是使用F9键，而这就是问题所在。 - jonjbar

那台机器是一台带有16GB内存的Core-i7。CPU在2分钟内达到了“14％”（单核心100％使用）。问题无法通过更快的电脑解决。这是IDE内部的设计问题。 - Warren P

Answer 4

我理解你的问题，但个人认为更改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关于如何重新启用这些异常的担忧。你只需要禁用断点即可再次报告所有异常。

---

额外的想法：

你提到：

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

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

• 你的测试是否足够本地化？如果你测试如此大块的功能，测试更像是系统测试 - 并且很难维护。
• 你是否过多地使用异常来进行主线业务处理？
• 你的应用程序是否在做很多不适当的异常吞噬？

基本上，你的措辞让我感到可疑，因为它暗示了“一堆你不太关心的异常，因为它们被‘处理’了”。许多人犯了一个错误，认为他们正在“处理异常”，但实际上他们只是将其吞噬并隐藏根本问题。

- Disillusioned

Answer 5

有点儿可以。您可以使用非中断断点[McKeeth][Jensen]来忽略您在测试中强制引发的异常。我知道保存断点的唯一方法是启用“工具”>“选项”>“自动保存”>“项目桌面”。

- Kenneth Cochran

---

很不幸，我并没有强制引发任何异常，它们是由被测试的代码本身触发的。因此这种方法行不通。 - jonjbar