Closed (fixed)
Project:
Site Alert
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
6 Feb 2020 at 08:51 UTC
Updated:
4 Mar 2020 at 14:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
Anonymous (not verified) commentedHello,
I have created a simple test that checks if the module is active on "admin/config/system/site-alerts". It checks if we can create an alert message, delete an alert message and if we can place the block and if there is an alert in the block.
Comment #3
pfrenssenThanks a lot for working on this! I have enabled automatic testing and ran the test. The result is green, but it generates a number of coding standards errors:
I have not yet reviewed the test manually, but let's already fix these before continuing.
Comment #4
Anonymous (not verified) commentedHello,
thanks for pointing out. Here is fixed patch
Comment #5
Anonymous (not verified) commentedHey,
sorry I missed 4 lines. This one should fix all issues.
Comment #6
Anonymous (not verified) commentedComment #7
Anonymous (not verified) commentedComment #8
kbrodej commentedReviewed the patch from #5. All coding issues are fixed.
Comment #9
bcizej commentedI reviewed the patch and there are few things that stand out:
1. Incorrect group annotation
2. There are four tests which means that four times a drupal installation and teardown is performed which slows the execution of tests. All four tests could be merged into a single test with assertions in correct order:
- Alerts list assertions
- Alert creation assertions
- Block placement assertions
- Alert deletion assertions
- No block after delete assertions
3. Previous point would also fix the next problem in tests, eg.
Tests are calling another test that already ran and succeeded/failed.
Comment #10
Anonymous (not verified) commentedComment #11
bcizej commentedOne more thing I found, probably just nitpicking here but lets follow the standards. Each module in the list should be in separate line.
Comment #12
Anonymous (not verified) commentedHello,
here is an updated version of the patch. Thanks for all the feedback.
Comment #13
Anonymous (not verified) commentedComment #14
pfrenssenAwesome, thanks so much for working on this! Assigning for review.
Comment #15
Anonymous (not verified) commentedAnother patch. I just cleaned up my code a bit. Sorry for so many patches. And thanks for reviewing.
Kind regards, Denis
Comment #16
pfrenssenWe're not testing any menu's so the name of the test is a bit misleading. Since this is testing the adding and removing of an alert through the web interface a better name would be
SiteAlertUiTest.It is no longer needed to explicitly add the dependency on the
optionsmodule, this has been fixed recently in #3111058: Missing dependency on the Options module.This user doesn't have the permission to access the toolbar, so let's change this to
A test user with permission to administer site alerts..This documentation seems to be unrelated to what is being tested, we are not altering any pages in the test. Let's put a description here that explains what this is about, maybe something like
Tests the creation and deletion of site alerts through the user interface.We don't need to call
$this-assertSession()again, it has already been called before and stored in the$assertvariable. Also it is not needed to check the existence of actual HTML snippets since this is brittle; any change in the theming (like adding a class) would break this test. Instead we can useWebAssert::elementExists()to check if the block is on the page.There are a few cases where this inline declaration of the variable type is left over in the code from earlier iterations. We can remove the duplicates, it is sufficient to keep only the declaration at the moment the variable is instantiated.
The comment from this seems to be unrelated, possibly copied from a different test? Also let's add a test to check that this empty text is no longer visible once we created a site alert.
Comment #17
pfrenssenCrossposted with comment #15. Some of my remarks were already addressed, great :)
Here are the rest of the fixes. This will be good to go when tests come back green. I would like to get this in first before any other issues so that we can run the test and check that there are no regressions.
Comment #19
pfrenssenThanks a lot!