[xwiki-devs] [Proposal] Default mock implementation for the xwiki-bridge component
Hi devs, All the components that depend on the model bridge need to provide a mock implementation of the bridge, which has as a main disadvantage the fact that the code is hard to updade (if I change the bridge, why would I look inside the office importer?) We currently have 4 mock implementations. A better approach: Make one mock implementation inside the bridge component, which will be packaged in a test package, and which will be used as a test-time dependency when needed. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Apr 10, 2009 at 6:51 AM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
All the components that depend on the model bridge need to provide a mock implementation of the bridge, which has as a main disadvantage the fact that the code is hard to updade (if I change the bridge, why would I look inside the office importer?)
We currently have 4 mock implementations.
A better approach: Make one mock implementation inside the bridge component, which will be packaged in a test package, and which will be used as a test-time dependency when needed.
WDYT?
+1
On Fri, Apr 10, 2009 at 8:10 AM, Asiri Rathnayake < [email protected]> wrote:
On Fri, Apr 10, 2009 at 6:51 AM, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
All the components that depend on the model bridge need to provide a mock implementation of the bridge, which has as a main disadvantage the fact that the code is hard to updade (if I change the bridge, why would I look inside the office importer?)
We currently have 4 mock implementations.
A better approach: Make one mock implementation inside the bridge component, which will be packaged in a test package, and which will be used as a test-time dependency when needed.
WDYT?
+1
Ummm, on second thoughts, different components might require their MockDocumentAccessBridges to behave differently... How do we handle this situation? - Asiri
On Apr 10, 2009, at 3:21 AM, Sergiu Dumitriu wrote:
Hi devs,
All the components that depend on the model bridge need to provide a mock implementation of the bridge, which has as a main disadvantage the fact that the code is hard to updade (if I change the bridge, why would I look inside the office importer?)
We currently have 4 mock implementations.
A better approach: Make one mock implementation inside the bridge component, which will be packaged in a test package, and which will be used as a test-time dependency when needed.
WDYT?
1) I'd much prefer to find a way to use a real dynamic mock and register it against the CM. 2) If this is not possible then I think a better solution would be to interact at the level of the ComponentManager itself so that we can control which instance is returned from lookup. This can be done by having a TestableComponentManager that wraps the ComponentManager and allows to control instances returned for some roles. 3) If this is not possible then +1 but provided we do a real mock and not a stub. Real mock means that we don't have a single line of specific logic. Here's an example for ex for implementing: DocumentModelBridge getDocument(String documentName) throws Exception; private DocumentModelBridge documentModelBridge; public void setGetDocument(DocumentModelBridge documentModelBridge) { this.documentModelBridge = documentModelBridge; } public DocumentModelBridge getDocument(String documentName) { return this.documentModelBridge; } This means that the behavior of the mock is fully controlled by the test using it (opposite to a stub which has a default behavior). Conclusion: I think that 2) is possible and would be the best solution since it allows using dynamic mocks and will work not only for DocumentAccessBridge but for all other components too. Thanks -Vincent
participants (3)
-
Asiri Rathnayake -
Sergiu Dumitriu -
Vincent Massol