New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Auto Expiry Feature #111
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.
*/ | ||
protected function _getAutoExpiringLifetime($lifetime, $id) | ||
{ | ||
if ($lifetime) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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) {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Done.
return !empty($matches); | ||
} | ||
|
||
public function setAutoExpireLifetime($lifetime) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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! |
Implementation of feature discussed in #110.