Hi All,
Is there any possibilities to create a mock object for an activity in BW? For example, a mock object for a JDBC Query activity.
http://xunitpatterns.com/Mock%20Object.html
Thank you
Hi All,
Is there any possibilities to create a mock object for an activity in BW? For example, a mock object for a JDBC Query activity.
http://xunitpatterns.com/Mock%20Object.html
Thank you
Hi Livingston,
Yes, you can create mocks for activities, such as JDBC Query activities. I'll create an example and post it here for you, but at a very high level, it involves moving the activity into a sub-process, creating a mock sub-process with the same input and output, and then using dynamic overrides to so the SUT calls the mock.
Hi Livingston,
I've attached a DB mocking example. Unzip it to BWUnit/examples/DBMock.
As mentioned before, we use a dynamic override to control if the SUT uses the real implementation or the Mock. We find it is extremely important in these situations to have the process name set to the real implementation. This is so the navigation through the processes follows the path of the real implementation and does not end up in dead-ends, which would force the developer to backtrack and interpret the process override to try and figure out where the real implementation is.
In the example we are using XSI to pass the path of the mock into the SUT. Some developers prefer to use global-variables; however if you do use a global variable, you cannot use different test doubles in different tests for the same SUT. Personally, we prefer the XSI approach as it communicates the dependency injection far more clearly within the test, whereas a global variable is disconnected from the test, making the test harder to read.
In terms of the dynamic override itself, some developers would be very reluctant to allow this testing code to progress into production and in fact, you'll notice that we've added a global variable to toggle the dependency injection on and off. We find this approach for "switching off" the test code acceptable in most situations. In cases where that approach is not acceptable (either for performance reasons or for cultural reasons), when compiling the ear, we have a pre-processing step that removes the relevant processNameXPath elements and pd:coercions elements from the *.process files.
Please let me know if you have any questions or if you are happy that this answers your question.