10 Apr
2009
10 Apr
'09
3:21 a.m.
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/
10 Apr
10 Apr
4:40 a.m.
On Fri, Apr 10, 2009 at 6:51 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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
4:44 a.m.
On Fri, Apr 10, 2009 at 8:10 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
On Fri, Apr 10, 2009 at 6:51 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Ummm, on second thoughts, different components might require their
MockDocumentAccessBridges to behave differently...
How do we handle this situation?
- Asiri
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
9:11 a.m.
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
5735
days inactive
5735
days old
3 comments
3 participants
participants (3)
-
Asiri Rathnayake -
Sergiu Dumitriu -
Vincent Massol