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

Question

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

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

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

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

提前致谢。

Answer 1

不是（至少在D2009之前没有）。没有调试运行是IDE的事情。一个comiler标志无济于事，因为它是连接exe的IDE，而不是相反的方式。您可以拥有此选项的唯一地方是项目设置。但是，如果没有调试，运行和运行之间的正常区别可能会让IDE略微混乱。然后，您需要第三个选项，“运行”，“运行调试”和“无需调试运行”，其中简单的“运行”将从项目选项中获取提示。

Answer 2

将run-without-debugging图标添加到工具栏。您的问题是忘记了热键，然后单击图标。因此，请删除其他图标，或将它们四处移动，如下所示：

我发现，应用程序越大，调试器启动得越慢。我现在大约99％的时间没有调试运行，因为我的应用程序的启动时间从2秒到2分钟，因为它使用了大量的运行时包，并且调试器中的每个BPL负载都受到巨大冲击。我的生产力。这么久，缓慢的痛苦经历再次教育我问自己“我真的需要调试吗？”。如果我不这样做，我会点击绿色图标（在XE中）替换旧版本中的感叹号图标。 （我认为智能UI改进。）。在以前的delphi版本中，绿色播放按钮意味着“运行调试”。

Answer 3

禁用“语言例外通知”。

Answer 4

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

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.

你问的其余部分在哪里？
没有 - 这就是它！

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

• 为每个方法添加断点。
• 编辑断点属性。
• 选择高级选项。
• 关闭＆＃34; Break＆＃34;选项
• 并打开＆＃34;忽略后续例外＆＃34;和＆＃34;处理后续例外＆＃34;相应方法的选项。

这与编译器指令选项的jpfollenius'概念接近。它还解决了David's对如何再次启用这些异常的担忧。您需要做的就是禁用断点以再次报告所有异常。

---

其他想法：

你提到：

  

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

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

• 您的测试是否足够本地化？如果您正在测试如此大的功能块，那么测试更像是系统测试 - 并且可能很难维护。
• 您是否过多地使用主线业务处理的例外情况？
• 你的申请是否会吞下许多不适当的异常？

基本上，对我来说，你的措辞建议＆＃34;一些你不太关心的例外因为他们已经处理了＃34;而且似乎很可疑。许多人错误地认为他们正在处理异常，而实际上他们只是吞下它们并隐藏根本问题。