在 TestComplete 中使自定义控件更具可测试性
（这在 TestComplete 论坛中可能会更好，但我想我还是应该在这里尝试一下）
我们正在研究使用 TestComplete 对 Delphi 2010 应用程序进行自动化测试>。我们的应用程序使用的主要控件是我们自己的自定义控件，它直接派生自TCustomControl。
（作为参考，该控件就像一个绘图工具，显示其中包含文本的框。可以选择这些框。该控件完全是自定义绘制的，包括选择）。
我们正在寻求使其对 TestComplete 更加友好，以便我们可以从中读取数据（例如，将哪些数据加载到控件中，选择哪些数据）
我还应该提到，我们的应用程序使用 MVC 架构并使得大量使用接口。 TestCompletes 调试代理似乎无法返回有关接口的任何类型信息，因此我们无法从中获取任何数据。我怀疑这是我们问题的根源
我正在考虑这两种方法：
向控件添加新属性，该属性将返回有关当前选定框的信息。例如，框中的文本、屏幕上的位置、分层路径，并通过 TestCompletes 调试代理访问它们。
看看为 TestComplete 创建一个自定义控件附加组件（我什至不确定您是否可以使用 Delphi 控件来执行此操作）
第一种方法的问题是链接器通常会删除不使用的属性和函数。我们希望使用我们的发布版本来测试而不是调试版本。
有人对此有任何建议或有此类事情的经验吗？
谢谢
编辑：我刚刚阅读了 SDK 帮助，并且只能为 .net 和 WPF 控件创建自定义控件插件。
(This might be better in the TestComplete forums, but I thought I'd give it a shot here anyway)
We are looking in to automated testing of our Delphi 2010 application with TestComplete. The main control that our application uses is our own custom control that derives directly from TCustomControl.
(For reference the control is like a digraming tool that display boxes with text in them. These boxes can be selected. the control is completely custom drawn, including the selection).
We are looking in to making this more TestComplete friendly so we can read data out of it (e.g. what data is loaded in to the control, what data is selected)
I should also mention that our application uses an MVC architecture and makes heavy use of interfaces. TestCompletes debug agent can't seem to return any type information about interfaces and thus we can't get any data from them. I suspect this is the root of our problem
I'm considering these two approaches:
Add new properties to the control that will return information about the currently selected box(es). e.g. text in the box, position on screen, hierarchical path, and access them via TestCompletes debug agent.
Look at creating a custom control add on for TestComplete (I'm not even sure you can do this with Delphi controls)
The problem with the first approach is the linker will often elimate properties and functions if they are not being used. We want to use our release build for testing not a debug build.
Does anyone have any advice on this or experience with this type of thing?
Thanks
Edit: I've just read the SDK help and custom control addons can only be created for .net and WPF controls.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该重新考虑使用发布版本进行测试的决定。原因是 TestComplete 需要一些魔法来让您的测试生活更轻松，而您不希望这种魔法出现在发布版本中。因此，如果您能详细说明不使用调试版本进行测试的原因，我们可以尝试找到解决方案来撤销此决定。结果可能是，如果您仅显示 TestComplete 的所有可用功能，您将可以访问控件的所有相关数据。
现在回到最初的问题：您可以通过创建一些包装这些接口的特殊类来克服接口问题，从而使属性在 TestComplete 中可用。
创建一个小型（可能不可见）测试表单，在其中集中对这些类的实例的访问。 （现在是发布模式链接）仅在调试模式下创建此表单，因此，经过精心设计，您仅在需要测试时链接相关代码。
You should reconsider your decision to use the release build for testing. The reason is that TestComplete needs some magic to make your testing life easier while you don't want this magic be present in the release build. So if you can elaborate on the reasons for not using a debug build for testing, we can try to find a solution to revoke this decision. The result may be that you will have access to all the relevant data of your control if you only reveal all available power of TestComplete.
Now back to the original question: You can overcome the interfaces problem by creating some special classes that wrap those interfaces and thus make the properties available in TestComplete.
Create a small (perhaps invisible) test form where you centralize access to instances of these classes. (Now the release mode link) Only create this form in debug mode so, when carefully designed, you only link in the relevant code when needed for testing.
您对调试信息的看法是正确的 - 您可以将其从发布版本中删除。因此，您将测试发布版本并同时访问内部结构。
关于这种情况的注释：“如果不使用属性和函数，链接器通常会删除它们。”您可以在此处作弊以使链接器为这些函数生成调试信息：
var t: Boolean; begin t := False; if t = True then TheFunctionThatNeverExecutes(); ... end;You are right about the debug info - you can strip it out from the release build. Thus, you will test a release build and have access to internals at the same time.
A note regarding this situation: "the linker will often elimate properties and functions if they are not being used." You can cheat here to make the linker generate debug info for those funcitons:
var t: Boolean; begin t := False; if t = True then TheFunctionThatNeverExecutes(); ... end;