Making FilterWPQuery Reusable, Swappable, & Flexible #5
Conversation
This interface is a contract that strictly defines how to interact with each "getting the content" implementation. We can use this contract for type hinting when we inject an implementation into FilterWPQuery.
Notice that this implementation implements the ContentGetterContract. Therefore, it has the standard `getContent` method, which will be invoked by FilterWPQuery.
Notice how getPosts() uses the new generic $contentGetter object to invoke through the contract to the specific implementation that is bound to the $contentGetter property.
Notice that we are type hinting the injected object using the contract. This contract serves an interface between the FilterWPQuery and each implementation. Using this design, the FilterWPQuery class does not care which implementation is wired to it. Rather, it serves as a generic object. But because of the contract, the FilterWPQuery knows how to interface with it.
During the launch, we initialize the FilterWPQuery by injecting which implementation we want for our project.
|
Travis is failing with |
|
@Shelob9 I'll take a look and resolve it. |
|
Running tests locally: |
|
I didn't realize I was pushing into your branch. We can reset that into its own if the idea I had in the last two commits don't work out. I made BTW I added a mock Also, tests are not working, same reasons as above. Let's get those sorted and then finish updating the interfaces. Then a factory to glue them all together. Also an interface for |
|
@Shelob9 To keep this PR clean and synchronized with the Torque code review article, I'm going to rollback last changes and force push. Then we can create a new branch and PR to build out the Factory and glue it all together, per our discussions. |
We'll use Brain Monkey in the unit tests. Mockery we'll use in both test suites.
The new FilterWPQuery requires an implementation for getting the posts. This commit mocks the interface and then loads it via the `init()` method. In addition, switched to using Mockery and Brain Monkey instead of a separate mocked stub.
WP_Post mock begin autoloaded can cause the integration tests to fail. Load it only if needed. With the latest version of PHPUnit, a fatal error is thrown in WP Core Test Suite: Class PHPUnit_Util_Test may not inherit from final class (PHPUnit\Util\Test) in /tmp/wordpress-tests-lib/includes/phpunit6-compat.php on line 18 Downgraded to version 5.7.9 to resolve the issue.
1. Whoops, forgot to import the classes. 2. The private method is on the object and not static.
Before we can go get the posts, first we need to initialize FilterWPQuery by loading the implementation.
This pull request separates the task of "getting the content" from
FilterWPQuery. It makes the class reusable while providing a mechanism to wire up specific project implementations for getting content for the search query.It's built off of PR #4. Therefore, the commits for this PR begin at commit d08fac0.
Improvements include:
init()method toFilterWPQueryand injected the implementation.getPosts()to use the generic object and invoke thegetContentmethod on whatever implementation is wired to it.With this change,
FilterWPQuerydoes not care which implementation is used. It provides a clean way to reuse this code from project-to-project.This PR is Part 4 of my article series on Torque Magazine.