第三方软件 API (AutoCAD) 单元测试的最佳实践
我们正在开发在 AutoCAD 中使用的应用程序。 基本上，我们创建一个类库项目，并使用命令 (NETLOAD) 在 AutoCAD 中加载 .dll。
因此，我们可以使用命令、“调色板”、用户控件、表单等...
AutoDesk 通过一些 dll 提供 API，在其程序目录中运行。 引用这些 dll 时，您只能在运行时在 AutoCAD 中加载应用程序时调用 dll（这是 AutoDesk 的许可安全性）。
对于我们来说，在开发时，这不是问题，我们需要在 AutoCAD 上下文中进行直观测试，因此我们只需设置“调试属性”，以便它们启动 acad.exe 并使用 acad.exe 参数中的脚本加载我们的 dll 。
问题是，当尝试对我们的代码进行单元测试时，NUnit 或 mstest 未在 AutoCAD 上下文中运行，并且它们也无法启动它。 有一个名为 Gallio 的工具，它提供了与 AutoCAD 的接口，以便可以通过带有命名管道的 IPC 来运行单元测试。
然而，这个解决方案对我来说太麻烦了。 我希望能够快速编写测试，而不必离开我心爱的 IDE。
那么，从“良好的设计角度”来看，什么是解决这个问题的好方法呢？ 我想我基本上需要一个不引用 AutoCAD dll 的可测试代码库和一个引用不可测试的 AutoCAD dll 的不可测试代码库。
我确信有一些方法可以让它发挥作用：（IOC、DI、适配器模式……）我只是没有深入了解这些原则，因此我不知道哪条路线最适合我的目的和目标。
We are developing applications for use within AutoCAD.
Basically we create a Class Library Project, and load the .dll in AutoCAD with a command (NETLOAD).
As so, we can use commands, "palettes", user controls, forms etc...
AutoDesk provides an API through some dll's, running in their program directory.
When referencing these dll's you can only call the dll's at runtime while loading your app in AutoCAD (This is a licensing security from AutoDesk).
For us, while developing, this is not a problem, we need to visually test within the context of AutoCAD, so we just set the Debug Properties so that they start acad.exe and load our dll with a script in the acad.exe parameters.
The problem is, when trying to unit test our code, NUnit or mstest are not running from within the AutoCAD context and they also cannot start it.
There exist a tool called Gallio, which has provided an interface with AutoCAD, so that it can run Unit test through IPC with Named Pipes.
However, this solution is, for me, too much of a hassle. I want to be able to quickly write tests without having to leave my beloved IDE.
So, what, from a "good design view" would be a good approach to this problem? I'm thinking I would basically need a testable codebase which is not referencing the AutoCAD dll's and a non-testable that does references the untestable AutoCAD dll's.
I'm sure there are ways to get this to work: ( IOC, DI, Adapter Pattern,. .) I just don't these principles in depth and thus I don't know which route will best suit my purposes and goals.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
第一步是将代码分类为需要 AutoCAD 的部分和真正独立的部分。 像平常一样为独立部分创建单元测试。
对于其他部分，您需要行为类似于 AutoCAD 的模型。 使它们尽可能简单（例如，仅在方法中返回正确答案而不进行任何计算）。 现在，您需要几组类：
您的代码用于实现某些功能（例如，加载绘图）的一组接口。
调用 AutoCAD dll 的所述接口集的一组实现。
一组尝试在 AutoCAD 上下文中实现的类。 只需创建一个带有几个按钮的小型 UI，即可在其中运行此代码。 它用于让您自己放心，您的模型做了正确的事情。 将方法参数和结果记录到某个文件中，以便您可以尝试 AutoCAD 如何响应。 如果模型损坏，您可以使用此代码来验证 AutoCAD 正在做什么，并且可以在开发模型时将其用作参考。
当您了解 AutoCAD 如何响应后，即可创建模型。 在您的测试中，使用所需的结果（和错误，以便您也可以测试错误处理）创建它们。 因此，当您有
boolean loadDrawing(File filename)时，创建一个模型，该模型为文件名exists.dxf返回true和false< /code> 其他任何内容。使用工厂或 DI 告诉您的应用程序代码要使用哪个实现。 我倾向于有一个大的全局配置类，其中有很多公共字段，我只是在其中存储要使用的对象。 我可以一开始就设置好，速度很快，也很容易理解。 如果您需要在运行时创建对象，请将工厂放入为您生成对象的配置类中，以便您可以交换它们。
The first step is to triage your code for parts which need AutoCAD and parts which are really independent. Create unit tests for the independent parts as you usually would.
For the other parts, you need mockups which behave like AutoCAD. Make them as simple as possible (for example, just return the correct answers in the methods without doing any calculations). Now, you need several sets of classes:
A set of interfaces which your code uses to achieve something (for example, load a drawing).
A set of implementations for said set of interfaces which call the AutoCAD dlls.
A set of classes which try the implementations within the context of AutoCAD. Just create a small UI with a couple of buttons where you can run this code. It is used to reassure yourself that your mockups do the right thing. Log method parameters and results to some file so you can try how AutoCAD responds. If a mockup breaks, you can use this code to verify what AutoCAD is doing and you can use it as a reference when developing the mockups.
When you know how AutoCAD responds, create the mockups. In your tests, create them with the desired results (and errors, so you can test error handling, too). So when you have
boolean loadDrawing(File filename), create a mockup which returnstruefor the filenameexists.dxfandfalsefor anything else.Use a factory or DI to tell your application code which implementation to use. I tend to have a big global config class with a lot of public fields where I simply store the objects to use. I can set this up in the beginning, it's fast, it's easy to understand. If you need to create objects at runtime, then put factories in the config class which generate the objects for you, so you can swap them out.
我写了……后来又破坏了……一个 AutoCAD 测试运行程序。 它位于 https://github.com/CADbloke/CADtest。 如果您对此感兴趣，请推动我，我会更快地修复它。 在解决这个问题之前，我正在等待 NUnit v3 发布。
如果您重置到该存储库中的第三次提交（我认为）并从那里摆弄它，它应该运行。
I wrote ... and later broke ... a Test runner for AutoCAD. It is at https://github.com/CADbloke/CADtest. If you're interested in it nudge me along and I'll fix it faster. I am waiting for NUnit v3 release before I tackle it.
If you reset to the 3rd commit in that repo (I think) and fiddle with it from there it should run.
这是有关如何对 AutoCAD 插件进行单元测试的详细指南。
要点：
Here's a detailed guide on how you can do the unit testing for AutoCAD plugins.
The key points: