Skip to content
This repository was archived by the owner on Jan 29, 2020. It is now read-only.

Conversation

@ezimuel
Copy link
Contributor

@ezimuel ezimuel commented Sep 24, 2018

This PR improves the unit tests coverage.

Copy link
Member

@weierophinney weierophinney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First off, great work - you jumped from 27% to 85% coverage!

There's still some room for improvement, though the improvements I suggest may not necessarily add coverage; they'll mainly make intent of tests more clear. In broad strokes:

  • Testing constructors to ensure they create an instance of the class is mostly useless, unless you also test for default property values.
  • Rename the various test methods to describe the behavior being tested. This will make the intent more clear, and may help you identify when you need to split a test into multiple tests and/or use a provider.

if (empty($config['grants']) || ! is_array($config['grants'])) {
if (empty($config['grants'])) {
throw new InvalidConfigException(
'The grant value is missing in config authentication'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be "grants"; otherwise, users might add a grant configuration value, and still get the exception. I would also likely add a note that the value must be an array.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I changed in "grants" and added "must be an array" in the exception message.

}
if (! is_array($config['grants'])) {
throw new InvalidConfigException(
'The grant must be an array value'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed.

/**
* @expectedException Zend\Expressive\Authentication\OAuth2\Exception\InvalidConfigException
*/
public function testGetPrivateKeyNoConfig()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update your test names to indicate what behavior is being tested. In this case, the method would become something like testGetPrivateKeyWhenNoConfigPresentWillResultInAnException.

This practice makes understanding the intention behind the test clearer when maintainers are trying to understand a failure later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I supposed was clear enough :)

<?php
/**
* @see https://github.com/zendframework/zend-expressive-authentication-oauth2 for the canonical source repository
* @copyright Copyright (c) 2017 Zend Technologies USA Inc. (https://www.zend.com)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and elsewhere you introduce new test classes: since the file was introduced this year, use 2018 as the copyright year.

use PHPUnit\Framework\TestCase;
use Zend\Expressive\Authentication\OAuth2\Entity\AccessTokenEntity;

class AccessTokenEntityTest extends TestCase
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this test. If it's just testing that the constructor returns an instance of the class, that's something we know already.

If there's other behavior to test — e.g., default property values, property values based on constructor arguments, etc. — then tests make sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remove the AccessTokenEntityTest we need to use @codeCoverageIgnore to omit this class from the code coverage. IMHO I think a test class like this, even if just checking for constructor, can be useful as a constrain for future changes. For instance, if someone changes the AccessTokenEntityInterface this test is able to intercept it.


class RefreshTokenEntityTest extends TestCase
{
public function testConstructor()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here as for the AccessTokenTest.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed to testImplementsRefreshTokenEntityInterface to test the interface implementation, not just the constructor.


class RevokableTraitTest extends TestCase
{
public function testRevoked()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Break this into two tests, or use a test provider, to detail what happens with each of the boolean arguments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

$this->entity = new ScopeEntity();
}

public function testConstructor()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed into testImplementsScopeEntityInterface.


namespace ZendTest\Expressive\Authentication\OAuth2\Entity;

use DateTime;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question: should we be using DateTime, or DateTimeImmutable? Which would make more sense for the domain?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say accept DateTimeInterface, convert to DateTimeImmutable if mutable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used DateTimeInterface as parameters of TimestampableTrait and DateTimeImmutable in TimestampableTrait::timestampOnCreate() function.

/**
* @expectedException ArgumentCountError
*/
public function testConstructorWithoutParam()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test doesn't have any assertions. Assert against the default identifier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assertion is in the phpdoc, I rename the function to testConstructorWithoutParamWillResultInAnException.

@Xerkus
Copy link
Member

Xerkus commented Sep 25, 2018

I would suggest explicit class level @covers annotations with forceCoversAnnotation="true" phpunit option to avoid false/accidental coverage

@ezimuel
Copy link
Contributor Author

ezimuel commented Sep 26, 2018

@weierophinney I updated the PR including your feedback.

- Commas after all array entries
- When splitting to multiple lines, move all arrow operations to their
  own lines when operating on an object
Writes three test methods that ensure the arguments passed to the
constructor affect the instance state.
s/testJsonSerialize/testEntityIsJsonSerializable/
- New files: 2018
- Existing files: range adds "-2018"
So we can test against PHP 7.3.
@weierophinney weierophinney merged commit 7acf6b8 into zendframework:master Sep 26, 2018
weierophinney added a commit that referenced this pull request Sep 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants