Mocking container generated factories

Notice: This thread is very old.
Vojtěch Vondra
Member | 11
+
0
-

Hey, I need some help with mocking factories created by the DI Container

config.neon

pageImporter:
			parameters: [param]
			class: PageImporter(..., %param%)

Presenter:

$importer = $this->context->createPageImporter('param');

Say I'm now writing a test for the presenter and I want to mock the behaviour of the service created by createPageImporter

There is no possibility of dynamically overriding the behaviour of the createPageImporter function (something like __call)

I've thought about creating “config snippets”, tiny configuration file overriding the main config with my own implementation, e.g.

testing < development:
	factories:
		pageImporter:
			parameters: [param]
			class: Tests\PageImporterStub(..., %param%)

However, addConfig assumes every file exists on its own including referenced config sections.

Having a complete copy of my basic config.neon with changes to mock only the necessary things is not feasible, I can't update all these configuration files when I change something in the main one.

I hope I'm just missing something trivial, thanks!

HosipLan
Moderator | 4668
+
0
-

Testing presenters by mocking services is not a good way to go. Presenters are complex creatures. Have a look at selenium.

Vojtěch Vondra
Member | 11
+
0
-

That wasn't the answer I was looking for. I have the application covered with Selenium tests, but there is some logic, be it trivial, in presenters that I want to have covered with unit tests.

I've seen a lot of effort here put into testing presenters and just saying don't test them surprises me.

voda
Member | 561
+
0
-

What is the dependency of the presenter? The DI Container or the the service? If its the container, then mock the container.

HosipLan
Moderator | 4668
+
0
-

Vojtěch Vondra wrote:

but there is some logic, be it trivial, in presenters that I want to have covered with unit tests.

Why there is logic in presenters? Decouple it!