[
https://issues.apache.org/jira/browse/SOLR-8474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-8474:
------------------------------
Description:
This issue originally (back in 2015!) proposed introducing Karma and friends to
unit-test the then-new AngularJS Admin UI JavaScript. That never materialized,
and the issue is now re-purposed for the approach we ended up with a decade
later.
h3. Chosen approach
Instead of a JavaScript unit-test toolchain, we test the Admin UI end-to-end in
a *real browser* against a {*}real Solr{*}, wrapped into Solr's existing JUnit
test framework:
* [Selenium WebDriver|https://www.selenium.dev/] drives a headless Chrome —
pure JVM dependencies from Maven Central, no Node.js toolchain. Tests skip
cleanly on machines without a Chrome/Chromium binary (e.g. ASF Jenkins).
* A new opt-in {{JettyConfig.Builder#enableAdminUi()}} makes
{{JettySolrRunner}} / {{MiniSolrCloudCluster}} serve the Admin UI exactly like
the production {{web.xml}} does.
* Tests live in {{{}solr/webapp/src/test{}}}, grouped per screen/feature, and
cover both display (asserted against live admin API responses, never hardcoded
values) and write actions: create/delete collections, aliases and replicas,
index documents, edit the schema, change log levels, manage
users/roles/permissions with BasicAuth, core admin add/rename/swap/unload and
leader/follower replication on standalone nodes, streaming expressions, SQL,
and more.
* The test catalog, deliberately skipped areas, and a list of possible UI bugs
surfaced by the tests are tracked in {{{}dev-docs/admin-ui-tests.md{}}}.
PR: [GitHub PR #4738|https://github.com/apache/solr/pull/4738]
h3. Closing remarks
They say the best time to add UI tests was ten years ago; the second best time
is now, right before axing it 😜. A big shoutout to [~upayavira] for standing up
the then-revolutionary UI back in 2015 — I don1t know if you read this, but who
would have thought this code would live this long. It has for sure served us
well all these years!
was:
The Solr UI has no tests. This is less than ideal. This ticket is aimed at
facilitating discussion around such a test framework for functional/end-to-end
testing components within the Angular UI.
Having a unit testing framework will encourage developers of the UI to make
more modular, and thus hopefully cleaner, code, as well as providing a means to
identify regressions.
For functional testing, I am proposing a Karma/Protractor/Jasmine combination.
Karma runs the tests, as with the Unit testing framework, Protractor interacts
with the pages effectively via a programmable browser (click here, enter there,
confirm that) whilst Jasmine provides a BDD style syntax for constructing the
tests themselves.
My proposal is that, for functional tests, we will fire up a full Solr server
via the existing test framework, then invoke Karma/Protractor within that
context. That will mean that the functional tests will be interacting with a
real Solr instance, presumably with real data in it.
Karma/Protractor/Jasmine can be installed by npm, which would become a
dependency for the Lucene/Solr build process, as for SOLR-8473.
As with SOLR-8473, there will be a dependency on either Chrome (and a UI such
as X) or a UI-less browser such as PhantomJS.
> Test Framework for functional testing Angular UI
> ------------------------------------------------
>
> Key: SOLR-8474
> URL: https://issues.apache.org/jira/browse/SOLR-8474
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
> Affects Versions: 5.4
> Reporter: Upayavira
> Assignee: Jan Høydahl
> Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-8474.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This issue originally (back in 2015!) proposed introducing Karma and friends
> to unit-test the then-new AngularJS Admin UI JavaScript. That never
> materialized, and the issue is now re-purposed for the approach we ended up
> with a decade later.
> h3. Chosen approach
> Instead of a JavaScript unit-test toolchain, we test the Admin UI end-to-end
> in a *real browser* against a {*}real Solr{*}, wrapped into Solr's existing
> JUnit test framework:
> * [Selenium WebDriver|https://www.selenium.dev/] drives a headless Chrome —
> pure JVM dependencies from Maven Central, no Node.js toolchain. Tests skip
> cleanly on machines without a Chrome/Chromium binary (e.g. ASF Jenkins).
> * A new opt-in {{JettyConfig.Builder#enableAdminUi()}} makes
> {{JettySolrRunner}} / {{MiniSolrCloudCluster}} serve the Admin UI exactly
> like the production {{web.xml}} does.
> * Tests live in {{{}solr/webapp/src/test{}}}, grouped per screen/feature,
> and cover both display (asserted against live admin API responses, never
> hardcoded values) and write actions: create/delete collections, aliases and
> replicas, index documents, edit the schema, change log levels, manage
> users/roles/permissions with BasicAuth, core admin add/rename/swap/unload and
> leader/follower replication on standalone nodes, streaming expressions, SQL,
> and more.
> * The test catalog, deliberately skipped areas, and a list of possible UI
> bugs surfaced by the tests are tracked in {{{}dev-docs/admin-ui-tests.md{}}}.
> PR: [GitHub PR #4738|https://github.com/apache/solr/pull/4738]
> h3. Closing remarks
> They say the best time to add UI tests was ten years ago; the second best
> time is now, right before axing it 😜. A big shoutout to [~upayavira] for
> standing up the then-revolutionary UI back in 2015 — I don1t know if you read
> this, but who would have thought this code would live this long. It has for
> sure served us well all these years!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
