Skip to content

Add static test to detect blocks without name attribute #11092

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

Merged
merged 3 commits into from
Oct 11, 2017

Conversation

ihor-sviziev
Copy link
Contributor

@ihor-sviziev ihor-sviziev commented Sep 27, 2017

Description

This change covers an issue when block doesn't contain name attribute in layout file.
As was discussed in #10354 (comment) - need to covert missing block names issue with static test.

Fixed Issues (if relevant)

  1. N/A

Related issues

  1. Add missing block name to allow block customisation #10352: Add missing block name to allow block customisation
  2. Add missing block name to allow block customisation #10354: Add missing block name to allow block customisation
  3. #10824 add name for order items grid default renderer block #10936: Cannot add new columns to item grid in admin sales_order_view layout #10824 add name for order items grid default renderer block

Manual testing scenarios

  1. N/A

Contribution checklist

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

For now I didn't fixed all places, but we can see list of them in failed test. Will create backport PRs to 2.2, 2.1 if it's needed

@ihor-sviziev
Copy link
Contributor Author

@magento-team This task wasn't added to list of static tests. How I can add it to travis?
https://travis-ci.org/magento/magento2/jobs/280767003

@vkublytskyi
Copy link

@ihor-sviziev Integrity tests are not executed on Travis environment:

# .travis.yml
test $TEST_SUITE = "static" && TEST_FILTER='--filter "Magento\\Test\\Php\\LiveCodeTest"' || true
if [ $TEST_SUITE != "functional" ] && [ $TEST_SUITE != "js" ]; then phpunit -c dev/tests/$TEST_SUITE $TEST_FILTER; fi

Integrity tests are executed on the internal Bamboo environment. To run test locally you may use

vendor/bin/phpunit -c dev/tests/static/phpunit.xml.dist dev/tests/static/testsuite/Magento/Test/Integrity/Layout/BlockNamesTest.php

@vkublytskyi
Copy link

@ihor-sviziev Are you interested in fixing new test failures?

@orlangur
Copy link
Contributor

test $TEST_SUITE = "static" && TEST_FILTER='--filter "Magento\Test\Php\LiveCodeTest"' || true

Well, last time I runned full static tests suite on Travis it finished quite quick. I propose to expand it by removing filter in scope of this PR.

@ihor-sviziev
Copy link
Contributor Author

@vkublytskyi @orlangur will add running all static tests & fix new failures

@ihor-sviziev
Copy link
Contributor Author

@vkublytskyi @orlangur I updated this PR, please review it again.
I have one more question: is there any benefits to use \Magento\Framework\App\Utility\AggregateInvoker instead of data Providers?

PS: static tests are passed!

@vkublytskyi
Copy link

@ihor-sviziev I don't know the exact reason why AggregateInvoker is used instead of data providers but it has next differences:

  • PHPUnit executes data providers at test suite instantiation time (before all tests and even before applying --filter option)
  • Each data set from data provider counted by PHPUnit as an independent test

@ihor-sviziev
Copy link
Contributor Author

@vkublytskyi let's keep AggregateInvoker for now. I just asked, maybe it was incorrect to use it.
Right now one integration test failed, but I think it's not related to my changes. Please review it

@orlangur
Copy link
Contributor

Commits 38

Could you please logically group changes into few commits and force push to the same branch?

is there any benefits to use \Magento\Framework\App\Utility\AggregateInvoker instead of data Providers?

It was introduced by me so I know the exact answer. Data providers created too much overhead, in some tests there were hundreds to thousands cases passed, for instance each layout XML in system. The biggest problem was Bamboo artifacts sizing as it tracks statistics for each test case separately.

As there are no downsides, later it was used for a smaller data providers of only 10-20 cases as well.

@ihor-sviziev
Copy link
Contributor Author

@orlangur grouped commits by module names. If it will be just two commits - it will be harder to review it . Isn't it?

@orlangur
Copy link
Contributor

Not harder, I believe all added block names should be better in single commit (as those changes are similar, it's easy to review). One commit with enabling all static tests on Travis, one commit with test for block names, maybe there were some other changes also - like fixing some static tests besides introduced one.

@ihor-sviziev
Copy link
Contributor Author

@orlangur done. Please review

@@ -12,7 +12,7 @@
</head>
<body>
<referenceContainer name="content">
<block class="Magento\Tax\Block\Adminhtml\Rule\Edit"/>
<block class="Magento\Tax\Block\Adminhtml\Rule\Edit" name="content.tax_rule_edit"/>
<block class="Magento\Tax\Block\Adminhtml\Rule\Edit\Form" name="tax-rule-edit" template="Magento_Tax::rule/edit.phtml"/>
Copy link
Contributor

Choose a reason for hiding this comment

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

A bit confusing but changing existing name would be a BC break, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure. As for me - this is not BC change because you hadn’t ability to customize these parts, now you will have. I don’t know any case what these changes could brake existing website

Copy link
Contributor

Choose a reason for hiding this comment

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

Note the line I commented on - after change names are
name="content.tax_rule_edit" and name="tax-rule-edit"

normally they should have been
name="tax-rule-edit" and name="tax-rule-edit-form"

Choose a reason for hiding this comment

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

@orlangur, @ihor-sviziev Changing a name of a block is A BiC so let's keep tax-rule-edit even if it not consistent with other names.

@@ -0,0 +1,36 @@
<?php
/**
* Test block names exists
Copy link
Contributor

Choose a reason for hiding this comment

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

Copyright header should be static across all files and such comment should be placed in class PHPDoc.

Feel free to not change this now as there are a lot of such occurrences in code, it needs to be enforced and fixed once for all codebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you fix them during merging this PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it's worth neither mine nor your additional commit, just keep in mind for future contributions and I hope to contribute such PHPCS sniff to make all copyright headers and class comments consistent.

@orlangur
Copy link
Contributor

orlangur commented Oct 2, 2017

@ihor-sviziev great job 👍

Did you perform e57ef72 with bare hands or there was some kind of automation, like XSLT transformation?

All internal builds passed except missing block names in EE modules. I expect @vkublytskyi will handle this.

@ihor-sviziev
Copy link
Contributor Author

@orlangur I’ve done it manually. Hope it will be merged soon.

@ihor-sviziev
Copy link
Contributor Author

ihor-sviziev commented Oct 4, 2017

@vkublytskyi @orlangur are these changes will be accepted? Can I prepare backport PRs for 2.2 and 2.1?

@vkublytskyi
Copy link

vkublytskyi commented Oct 4, 2017

@ihor-sviziev, Yes, this PR will be accepted. It may take more time than usually as we need to fix new test failures on Magento Commerce and B2B extensions.

@ihor-sviziev
Copy link
Contributor Author

@vkublytskyi could you also process #11235 together, it will be more effective?

@magento-team magento-team merged commit e57ef72 into magento:develop Oct 11, 2017
@ihor-sviziev ihor-sviziev deleted the patch-9 branch February 2, 2018 12:18
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.

5 participants