LibUp was getting caught out by the false-positive hit to
es-x/no-resizable-and-growable-arraybuffers, so doing a
manual fix to make progress.
Otherwise just whitespace changes.
Change-Id: Ibf20dd2d88613b0a74813c33239e7d0bac682b17
tests\selenium\specs\importingFilters.js
81:1 warning This line has a length of 106. Maximum allowed is 100
max-len
Change-Id: Ic8bee37971afb6fe4ba7102d687f0fa212092f4c
- Do not try to switch the editor if CodeEditor is not installed
- Make sure that the state before the test runs is known
- Add more specific assertion on error message
- Add missing await to async function call
- Re-enable test disabled in I47b4794c4098a25696ffe42c42d00fd767971b5d.
Selenium tests were run 100 times in CI in PS2 and they always passed.
Bug: T300790
Change-Id: Id9ca618dcc59396980b1ee38819677583107738c
WebdriverIO has dropped support of sync mode, hence changed to async.
Update npm packages: @wdio/*, wdio-mediawiki
because async mode needs at least @wdio v7.9.
Remove npm packages: @wdio/dot-reporter and @wdio/sync.
Bug: T300790
Change-Id: Ifcc95a8c7e47ba4513f6910620ecce83e1ead15a
These are part of legacy styles and aren't provided by all skins.
Using Html::successbox abstracts the classes away.
Internally that uses div class="successbox" instead.
Bug: T280766
Change-Id: I0cca59e2f391510095c2c6fb187ace5e91fdde8b
Since WebdriverIO v5, Puppeteer is available as a Chromedriver
alternative.
Puppeteer is bundled with WebdriverIO. Chromedriver needs to be installed
(and started/stopped) separately. Getting rid of Chromedriver simplifies
our documentation, among other things.
The commit updates tests/selenium/wdio.conf.js to use Puppeteer.
Bug: T269566
Change-Id: Ib2a547792a34e6d40137432f7800b5f71c254c36
This deals with data inconsistencies in buildFilterEditor. Every
property of $row was tested in all 5 scenarios (also using Selenium) to
check when it's set. The result is in the normalizeRow method, which
aims to remove any inconsistencies, so that buildFilterEditor always
receives a "complete" row with all defaults set.
The code in buildFilterEditor is now cleaner (because there are no
isset() checks), and it gives us a unique place where we can set
defaults (rather than partly doing that in
loadRequest/loadFilterData/loadImport, and partly relying on isset).
This will be especially useful when introducing value objects to
represent filters, because now you just have to look at normalizeRow()
to tell which properties are allowed to be missing, and thus what "kind"
of filter object you need (see
I5f33227887c035e301313bbe24d1c1fefb75bc6a).
Additionally, reduce the properties that get passed around during
export/import, and make the selenium test try a roundtrip, rather than
relying on hardcoded data that may get outdated. A future patch will
refactor the import/export code.
Change-Id: Id52c466baaf6da18e2981f27a81ffdad3a509e78
It's possible that we try clicking this button before it's ready. This
theory is hard to verify because I get no problem locally, but this
shouldn't hurt.
Also specialize input selectors for a couple elements that might not be
univocally determined within the page.
Change-Id: Ida65c3c5fd4d8b3b35ecbee7e99977c71c7c4b96
The editing view is currently full of tech debt, brittle and surprising
code and whatnot. It's basically a miracle if it works without problem,
and it'd be an even bigger miracle if you could change something there
without breaking anything.
For these reasons, and because that class must be refactored as part of
the upcoming overhaul, this patch adds a bunch of selenium tests to test
the main functionality of that page.
In particular, these tests cover all possible cases (each corresponding
to a data source) for which buildFilterEditor can be called, which FTR are:
1 - View the result of importing a filter
2 - Create a new filter
3 - Load the current version of an existing filter
4 - Load an old version of an existing filter
5 - Show the user input again if saving fails after one of the steps
above
Having automated tests to cover these cases means that we don't have to
manually test all the scenarios manually each time the class is touched.
Bug: T201193
Change-Id: I408e0a132905416effe0d6d6dc0921991edd66bd
* Update ESLint config with Selenium WebdriverIO test suite
* Update modules and Selenium pageobjects and specs per ESLint
requirements
* Update grunt-eslint package to 23.0.0 as required by
eslint-config-wikimedia 0.16.0
Bug: T254495
Change-Id: Ibfcf9115adedf9f2c3e7dac1ac626b41fc97b7c4
Follow-up Iabd0ae5b18571f8cad44ef2d86bcf2519e7f95ba.
This patch:
- Moves some save-related code to a separate method
- Reduces conditionals nesting
- Fixes an edge case where the content of the form would be
wiped in case the token didn't match.
- Adds another (basic) selenium test
- Standardizes return types
- Moves data load outside of buildFilterEditor
Change-Id: I89444b59f04c495c9ab59244151c8ed5d38cf0fe
In Ib7427e15f673a575738489476e604c387f449ddd, I thought that $parameters could've only been null if $action wasn't
enabled, but actually, they're null even if the action is just not set.
Which is true for all actions when creating a new filter, and all
non-set actions when editing an existing one.
Hence, revert the part that touched ViewEdit.
Also add a selenium test to ensure that warn parameters are visible.
Bug: T236286
Change-Id: I8150baa077208eb1fc54ebc1d8415a243d0f3bd3
This is some sort of Hello World for selenium. This patch adds the
config files and a couple of very basic tests.
Bug: T214478
Change-Id: I8193b4edb40332bea1d08e24ec020bf36004320d
