ee('CP/Pagination')
requires a second parameter of total, which makes it hard to inject it as a dependency into one of my classes where I don’t know the total yet. It basically means I have to call ee('CP/Pagination')
right in one of my class methods, which isn’t great and makes testing hard.
Basically, ee('CP/Pagination')
needs to not require the total parameter and needs a method to set it.
It is a controller. In this case, I’m using the MCP file as essentially a router. So the method in my MCP file looks like this:
public function index()
{
return ee('myaddon:MyController')->get();
}
My services key in addon.setup looks something like this:
'MyController' => function () {
return new MyController(
ee('CP/Sidebar'),
ee('Model'),
ee('CP/URL'),
ee()->input,
ee('CP/Table')
);
}
And there in addon.setup is where I would like to inject the pagination service. I’m striving for everything in my classes to be injected so that they can be mocked and tested. Up until this I have been successful.
Typically, part of class design is requiring things the class absolutely needs to function so that you don’t instantiate it and have it be useless. Pagination is useless without knowing a total count. And mocking this many things is typically considered an anti-pattern, you may find that you’re spending more time wiring up and maintaining your mocks than testing the actual class logic, plus it’s a maintenance nightmare down the road. This is typically referred to as “mock hell.” Maybe an integration test is more in order here, or an MVVM architecture.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.