全新的单元测试,我的意思是非常新的。我读过很多东西,而且正在慢慢地移动,试图在我走的时候遵循最佳做法。我在Visual Studio 2010中使用了MS-Test。模拟测试对象事件的策略
我想出了一个我不太确定如何继续下去的要求。我正在研究一个负责与外部硬件交互的组件。这个项目还有一些开发人员,他们没有硬件访问权限,所以我实现了组件的“虚拟”或模拟实现,并尽可能多地将共享逻辑上移到基类中。
现在,只要允许它们编译和运行代码,它就可以正常工作,但它对于模拟单元测试所需的事件和内部状态更改并不是很有用(不要忘记我是新手)
例如,我想测试组件上有几个事件,但是我需要调用它们才能测试它们。通常情况下,我会按下硬件上的按钮或分流两个终端,但在模拟对象中(显然)我不能这样做。
有两个担心/我有要求:
- 需提供本人的状态变化,并引发事件为我的单元测试
- 需提供本人的状态变化,并引发事件我的团队测试在组件上的依赖关系
对于我想到一些复杂的控制面板对话框,将让我的触发事件,并且通常后者(如在WPF视图一个按钮变为当特定硬件事件发生时启用)模拟硬件运算演讲和用户互动。这很复杂,因为它需要一个没有消息泵的组件来提供一个带有控件的窗口。臭。或者另一种方法可以是实现模拟组件来获取我可以用来改变对象内部的“StateInfo”对象。
这不是一个新问题,我相信你们中的很多人不得不做类似的事情,我只是想知道你用什么模式或策略来完成这个。我知道我可以通过访问器访问私有字段,但这并不能真正提供交互式(在运行时模拟的情况下)更改。
听起来像“模拟对象”,这是我一直称之为“虚拟对象”;) 现在的斗争是如何设计您的对象,以避免来自实际实现和模拟对象的代码繁重的重复。换句话说,如果引发事件的系统很复杂,我需要在模拟对象中复制它以便测试它。这当然会造成维修问题。我想尽可能多地将一些功能转移到基类中会有所帮助,但似乎仍然会有大量的重复。 –
我写了一篇很长的评论,关于我如何仍然难倒,但最后我有我的“阿哈片刻”。你的声明: “......你需要在包装类中包装硬件调用,所以你嘲笑它......”是关键。 告诉我,如果我有这个正确的: 1.创建一个硬件SDK包装对象的接口(例如IHardware) 2.更改我想测试的对象,使IHardware实例以某种方式注入(目前不是使用任何DI) 3.创建一个公开的状态属性和方法来设置内部状态的IHardware的模拟实现 4.(下一条评论) –
4.找到某种方式让单元测试注入模拟对象而不是实际对象 5.在模拟对象上调用方法和设置属性来模拟我的硬件事件 Man ...为了测试某些东西,这是很多额外的努力。虽然如果这确实是适合这种情况的策略,那么我会从中吸取教训,并在下次开始时使用它。 那么我有这一切正确吗? –