I am going to develop some kind of a mock object framework that is intended to mock up a Win32 device. This mock should be useful for developers who write user-mode code using Win32 API to collaborate with a kernel device driver and like to use the Test Driven Development or Behaviour Driven Development approaches in their activity. Collaborating with a real device has a lot of drawbacks, so it would be very useful to substitute the device with some kind of Test Double in the code's Unit Tests.
I have the following vision of the concerned framework:
The framework is implemented as a Win32 kernel mode driver. Initially the driver creates an auxiliary DEVICE_OBJECT and corresponding file object used by the Unit Test to setup the mockup withing the Fixture Setup Phase of the Four Phase Test approach. In general, setting up the DeviceMock consists of specifying expected I/O request packets (IRPs) to be sent to the driver from the SUT code and expected reaction of the driver on those IRPs. Specifying of the expected IRPs assumes also the file object that the IRPs are targeted to. So the Unit Test should specify this file object and the DeviceMock will create it and the device object that the file object correspond to.
On the Exercise SUT Phase, the SUT iteracts with the mocked device as it were a real device.
Then, on the Result Verification Phase the driver's verifies that the sent IRPs match to the expected ones. At last, on the Fixture Teardown Phase the driver will deletes all created file and device objects as well as releasing of other resources allocated at the Fixture Setup Phase.
The DeviceMock framework is seen as very low-level mock object. It is not expected that all unit tests of the whole SUT will rely only on the DeviceMock. The DeviceMock will substitute the interaction with the mocked device on very low level. This interaction consist of operating with Win32 OS primitives like file handles, raw memory buffers etc. In upper layers of the SUT this primitives should be wrapped, transformed or aggregated as parts of the application domain objects. Thus for the domain objects themselves it would be better to implement a wrapper of the collaborated device and well as a mock object of this wrapper. In this scenario, the DeviceMock framework will be used only to develop and test the device wrapper. The upper domain object and their unit tests will use the mock of the device wrapper implemented with common Mock Object Frameworks, like the Rhino Mocks.
I have the following vision of the concerned framework:
The framework is implemented as a Win32 kernel mode driver. Initially the driver creates an auxiliary DEVICE_OBJECT and corresponding file object used by the Unit Test to setup the mockup withing the Fixture Setup Phase of the Four Phase Test approach. In general, setting up the DeviceMock consists of specifying expected I/O request packets (IRPs) to be sent to the driver from the SUT code and expected reaction of the driver on those IRPs. Specifying of the expected IRPs assumes also the file object that the IRPs are targeted to. So the Unit Test should specify this file object and the DeviceMock will create it and the device object that the file object correspond to.
On the Exercise SUT Phase, the SUT iteracts with the mocked device as it were a real device.
Then, on the Result Verification Phase the driver's verifies that the sent IRPs match to the expected ones. At last, on the Fixture Teardown Phase the driver will deletes all created file and device objects as well as releasing of other resources allocated at the Fixture Setup Phase.
The DeviceMock framework is seen as very low-level mock object. It is not expected that all unit tests of the whole SUT will rely only on the DeviceMock. The DeviceMock will substitute the interaction with the mocked device on very low level. This interaction consist of operating with Win32 OS primitives like file handles, raw memory buffers etc. In upper layers of the SUT this primitives should be wrapped, transformed or aggregated as parts of the application domain objects. Thus for the domain objects themselves it would be better to implement a wrapper of the collaborated device and well as a mock object of this wrapper. In this scenario, the DeviceMock framework will be used only to develop and test the device wrapper. The upper domain object and their unit tests will use the mock of the device wrapper implemented with common Mock Object Frameworks, like the Rhino Mocks.
No comments:
Post a Comment