Open tapika opened 2 years ago
What is to hinder that you register the Mock
implementation in the container? It would make sense to have a composition root for testing. Also the SimpleContainer
is just as it implies supposed to be simple that is why Caliburn.Micro
can be extended to use other IoC
containers. I am not sure it would be valuable to build in support for automatic Mocks
.
What is to hinder that you register the Mock implementation in the container?
That can be done as well. But why container cannot do this automagically ? I guess container has knowledge on interfaces which it supports, as well it can get also information on class which it needs to instantiate. The rest is more or less computable. Only thing which is missing is maybe interfaces caliburn does not have - then it could query via separate callback function what to do about them.
=> Instantiate mock container dynamically, mock type is determined at run-time.
=> Potentially plug it under logger context.
CommandContext is such example of such dynamic mocking container, which I would like to see in context of IoC container as well.
Dynamically created mock can be used then later on by the test itself.
"container" side:
client side:
Documentation on everything if someone wonders how everything ties together:
https://github.com/tapika/swupd/blob/master/docs/testing.md
(Irrelevant from this ticket perspective)
Normally when you want to perform unit testing - instead of using normal implementation - you use
new Mock<interface>
object instead.SimpleContainer
operates on real implementations obtained from real assembies, real interfaces.Would it be possible to create such auto-mocking container so container itself would instantiate mocks as implementation requires ?
In theory if we have:
Normally when doing normal implementation, you could write something like this:
(Or similar
SimpleContainer
calls)When testing - you can either instantiate new Mock's for each interface and register to container (manual work), or container itself could automatically create new Mocks for each interface.
This is of course pseudo code, in reality new Mock would require figuring out Mock constructor method and call it (see https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/how-to-examine-and-instantiate-generic-types-with-reflection)
Using this kind of approach could simplify test writing.