Skip to content
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

Fix exception handling and cover with unit tests the GetById media asset command #25547

Conversation

coderimus
Copy link
Contributor

@coderimus coderimus commented Nov 10, 2019

Description (*)

Cover with unit test the GetById command of the Media Gallery functionality. Provide two tests: successful action execution and fail at the not found entity by id.

Fixed Issues (if relevant)

magento/adobe-stock-integration#585

Manual testing scenarios (*)

N/A

Questions or comments

N/A

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds are green)

@m2-assistant
Copy link

m2-assistant bot commented Nov 10, 2019

Hi @coderimus. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento give me test instance - deploy test instance based on PR changes
  • @magento give me 2.3-develop instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Guide documentation.

$mediaAssetStub = $this->getMockBuilder(AssetInterface::class)->getMock();
$this->assetFactory->expects($this->once())->method('create')->willReturn($mediaAssetStub);

$this->getMediaAssetById->execute(self::MEDIA_ASSET_STUB_ID);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please, add an assertion here. The execute method returns a value, so it worth asserting that we have an expected value.

Copy link
Member

Choose a reason for hiding this comment

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

Hi @rogyar I don't think the assertion is necessary here as execute method is not supposed to return anything in this specific test (it is supposed to throw an exception instead)

Copy link
Contributor

Choose a reason for hiding this comment

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

Hi @sivaschenko. In this particular case, we test the positive scenario with no exception. As a result, the execute method should return an ID. An assertion of the mentioned ID might be useful here.
Probably, I've missed some points.

Thank you.

->method('critical')
->willReturnSelf();

$this->getMediaAssetById->execute(self::MEDIA_ASSET_STUB_ID);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please, add an assertion of the returned result here as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hello @rogyar , thank you for your review. I have a question about this: do we need to have an assertion here when we already expect an exception: $this->expectException(IntegrationException::class); In that case, I think that assertion is satisfied by the fact of throwing an integration exception. What assertion you would like to see here?

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 the assertion is necessary here

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree, missed the point that the test already asserts the exception. Thank you

@rogyar
Copy link
Contributor

rogyar commented Nov 10, 2019

Also, the execute method has a chance to throw NoSuchEntityException. It would be really great to have one more test that covers a case with throwing the mentioned exception.

@rogyar rogyar added the Auto-Tests: Covered All changes in Pull Request is covered by auto-tests label Nov 10, 2019
@coderimus coderimus force-pushed the 585/cover-with-unit-tests-getbyid-action branch from ea2f050 to d08eb44 Compare November 10, 2019 19:52
@coderimus
Copy link
Contributor Author

coderimus commented Nov 10, 2019

@sivaschenko @rogyar
I changed the GetById command: now every step in it has a try-catch block which allows controlling execution in a more logical way. Please, review those changes and covered tets.

But this semantic version test confused me. Do you have any idea why it failed? I didn't change anything according to its report. :(

@coderimus coderimus requested a review from rogyar November 10, 2019 20:58
@coderimus
Copy link
Contributor Author

Nevermind about the semantic version check. I re-run it, and everything is ok now. @rogyar @sivaschenko

Copy link
Member

@sivaschenko sivaschenko left a comment

Choose a reason for hiding this comment

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

Thanks for the pull request @coderimus ! Please see my review comments

$mediaAssetStub = $this->getMockBuilder(AssetInterface::class)->getMock();
$this->assetFactory->expects($this->once())->method('create')->willReturn($mediaAssetStub);

$this->getMediaAssetById->execute(self::MEDIA_ASSET_STUB_ID);
Copy link
Member

Choose a reason for hiding this comment

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

Hi @rogyar I don't think the assertion is necessary here as execute method is not supposed to return anything in this specific test (it is supposed to throw an exception instead)


/**
* Test the GetById command model
* @SuppressWarnings(PHPMD.CouplingBetweenObjects)
Copy link
Member

Choose a reason for hiding this comment

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

@coderimus can you please remove this warning suppression (and extract some tests to a separate file/class if necessary)

@ghost ghost assigned sivaschenko Nov 11, 2019
@coderimus coderimus force-pushed the 585/cover-with-unit-tests-getbyid-action branch from f224328 to b0fb363 Compare November 12, 2019 16:34
@rogyar
Copy link
Contributor

rogyar commented Nov 13, 2019

@sivaschenko, what do you think about the proposed approach? It would be really nice if we could prevent copying the setUp method over every test without involving a parent class. However, I don't see many options here (we have discussed a separate, 'context' class, but It was just an idea)

@coderimus
Copy link
Contributor Author

@rogyar you mean that it would be nice to initialise the setUp method at the successful test class and then extend all related test classes from it?

@coderimus coderimus force-pushed the 585/cover-with-unit-tests-getbyid-action branch from ee76ae8 to 4b03395 Compare November 13, 2019 13:55
@sivaschenko
Copy link
Member

@rogyar @coderimus I think in this case there could be unique setUp methods for each test as exception tests should not need all the mocks used in the main case test

@coderimus coderimus force-pushed the 585/cover-with-unit-tests-getbyid-action branch from 4b03395 to 061d5a3 Compare November 13, 2019 14:29
@coderimus
Copy link
Contributor Author

@rogyar @sivaschenko
Thank you for your review and comments. I tested both variants: with independent test classes and with the one which has the setup method and all other tests inherited it.

From my perspective, I can say that it will be better to have separate classes. Even with the setup method in most cases similar. In the scope of the Unit testing, this could be possible even better and applicable: we encapsulate the logic of every exception and the logical conclusion it produces. With this, we can avoid a situation when a possible change made for any part of the command can be possibly ignored and doesn't take into account.

About one class with the setup method and its inheritance: this is not so useful for us because unit tests, as I see them, should be as strict as possible to cover existed implementation. Add the inheritance of the setup method results in the fact that we rely on a parent class for tests in all cases and make the unit test structure more complicated.

My latest implementation consists of separate classes. Please, check them when you will have time.

@magento-engcom-team
Copy link
Contributor

Hi @sivaschenko, thank you for the review.
ENGCOM-6294 has been created to process this Pull Request

@magento-engcom-team
Copy link
Contributor

Hi @rogyar, thank you for the review.
ENGCOM-6294 has been created to process this Pull Request

@sivaschenko sivaschenko changed the title 585: cover with unit test the GetById media asset command Fix exception handling and cover with unit tests the GetById media asset command Nov 20, 2019
@magento-engcom-team magento-engcom-team merged commit c2209fb into magento:2.3-develop Nov 21, 2019
@m2-assistant
Copy link

m2-assistant bot commented Nov 21, 2019

Hi @coderimus, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.

@magento-engcom-team magento-engcom-team added this to the Release: 2.3.5 milestone Nov 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants