Repository navigation
Add Auto Expiry Feature - #111
Conversation
Use a new test case class where the instance is set up differently. None of the other properties have setters.
| * @return int Cache life time | ||
| */ | ||
| protected function _getAutoExpiringLifetime($lifetime, $id) | ||
| { |
There was a problem hiding this comment.
No reason to check if it matches the pattern if the feature is disabled. I recommend short-circuiting by changing this to:
if ($lifetime || ! $this->_autoExpireLifetime) {|
|
||
| return !empty($matches); | ||
| } | ||
|
|
There was a problem hiding this comment.
Other options are not exposed this way... Is there a reason they need to be set aside from the constructor?
There was a problem hiding this comment.
The reason I added the setters was to be able to change the properties for testAutoExpiry. Maybe there's a better way, but I'm not sure. I tried Googling to see if setUp could tell what test method as being called, but couldn't find any information about that.
There was a problem hiding this comment.
I think the proper way would be to have a new test case class for these tests that require a different setUp method.
There was a problem hiding this comment.
@colinmollenhour Updated with a separate test case. I'm following the pattern introduced with forceStandalone where a protected property is used and can be changed in the new test case class. Happy to squash these down as a final step if you'd like.
|
Looks good! Thanks, Max! |
2 participants
Implementation of feature discussed in #110.