创建 Pex 测试来测试 DLL 和由该 DLL 控制的硬件？
创建 Pex 测试来测试 DLL 和由该 DLL 控制的硬件？
我有一些硬件，其中有一个由 DLL 控制的 api。我在 nunit 中编写了一些单元测试，它们将调用 API 的适当部分并进行测试。
例如，我可能有一个“获取数据测试”，一侧有 1. 打开，2. 读取，另一侧有 3. 发送，断言是数据是否正确。
我认为 Pex 可能会很好地处理该数据。
我的问题是，由于我坐在 DLL 之上，并且我确实需要将几件事拼凑在一起进行测试，因此我如何在这里实现 Pex（此时我对 Pex 几乎一无所知）？
我是否需要以某种方式创建一个我在已读取和发送的 DLL 之上控制的 API，并让 Pex 在这一层创建它的测试？
编辑： 我做了更多研究并观看了一个很棒的视频 http://channel9.msdn .com/posts/Peli/Getting-started-with-Pex-in-Visual-Studio-2008/
我质疑执行此操作的能力。听起来 Pex 非常适合创建测试，但并不是真正的整个系统（api 加硬件加数据）
Create Pex test to test a DLL and hardware controlled by that DLL?
I have some hardware that has an api in that is controlled by a DLL. I have written some unit tests in nunit that will call the appropriate pieces of the API and do a test.
For instance I might have a "get data test", that has an 1. open, 2. read on one side and 3. send on the other, and the assert is whether or not the data is correct.
I am thinking Pex might do a good job of manipulating that data piece.
My question is since I am sitting on top of a DLL and I really need to piece several things together for the test how do I implement Pex here (I also know next to nothing of Pex at this time)?
Do I somehow need to create an API that I control above the DLL that has read and sends and let Pex go at this layer to create it's test?
Edit:
I did some more research and watched a great video over at
http://channel9.msdn.com/posts/Peli/Getting-started-with-Pex-in-Visual-Studio-2008/
I am questioning the ability to do this. Sounds like Pex will be great to create tests but not really a whole system (api plus hardware plus data)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它必须检测代码来生成测试，因此它不会达到外部行为。如果你的 API 非常薄弱并且没有做太多事情，那么你不会从中得到太多。
如果该 api 中有相当多的逻辑以及硬件调用，我会将所有这些逻辑与与硬件进行实际交互的代码分开 - 定义一个接口并在其余代码中使用该接口。这将允许您使用所有涉及的逻辑。
上述内容包括将解析/分析数据与发送/接收之类的内容分开。您将能够涵盖所有这些。
It has to instrument the code to generate the tests, so it won't reach the external behaviors. If your API is v. thin and doesn't do much then you won't get much from it.
If you have a fair amount of logic in that api along with the hardware calls, I would separate all of that from the code that does the actual interaction with the hardware - defining an interface and using that in the rest of the code. That will allow you to use on all the logic involved.
The above includes separating stuff like parsing/analyzing data from sending / receiving. You will be able to cover all that.