You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Jiri Daněk (Jira)" <ji...@apache.org> on 2021/11/05 18:51:00 UTC
[jira] [Updated] (DISPATCH-2221) Create automated webconsole tests
using either Webdriver (Selenium) or Playwright
[ https://issues.apache.org/jira/browse/DISPATCH-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jiri Daněk updated DISPATCH-2221:
---------------------------------
Description:
Here's a reasonably recent overview of website end-to-end test automation tooling: https://www.testim.io/blog/puppeteer-selenium-playwright-cypress-how-to-choose/ (presentation https://www.youtube.com/watch?v=JuSF6BDs7Ow).
End-to-end should mean that the test interacts with the Dispatch web console by sending clicks to the browser window. The clicks are targeted using CSS-like selectors (often button/link texts and aria selector), and they are dispatched through browser debug protocol, so it is not _exactly_ simulating the user, but it is simulating the user to a very great degree. The advantage of doing the clicks this way is obviously maintainability; if a link moves 10 px to the left, it will still be clicked just fine.
The idea for writing (and structuring) the tests is to first start with record/playback, then export the recording as a program in a supported programming language using supported assertions API (Java, JavaScript, Python, ... Pytest, Playwright Test, Jest, ...), and finally mold it into well-factored and maintainable test suite (by extracting common steps, creating helper functions, page objects, ...).
I considered Selenium with Python and Pytest, Selenium with Java and Junit, and Playwright with Typescript.
Python is the language of the router, and it is usually known by QA-minded folks. Java is statically typed (which I prefer), is used by ActiveMQ messaging projects (that also need webconsole testing), and should be also well known. JavaScript/TypeScript is the language of the webconsole, so the tests will be easily understood by anyone developing the webconsole.
Selenium Webdriver is old and well-known. Playwright is more recent iteration on the same theme, and it has nice test framework in TypeScript on top.
Both PlayWright and Selenium can run with headless browsers in Docker container.
For reverence, my tests from 2017 in Webdriver, Python binding, written for the Hawt.io Dispatch plugin, https://github.com/jirkadanek/dispatch-console-tests.
I personally feel a deep dislike towards Cypress, but I have no factual basis for it, and in fact the tooling and the supporting documentation and some of the debugging features seem excellent https://github.com/muratkeremozcan/playwright-vs-cypress#readme.
was:
Here's a reasonably recent overview of website end-to-end test automation tooling: https://www.testim.io/blog/puppeteer-selenium-playwright-cypress-how-to-choose/ (presentation https://www.youtube.com/watch?v=JuSF6BDs7Ow).
End-to-end should mean that the test interacts with the Dispatch web console by sending clicks to the browser window. The clicks are targeted using CSS-like selectors (often button/link texts and aria selector), and they are dispatched through browser debug protocol, so it is not _exactly_ simulating the user, but it is simulating the user to a very great degree. The advantage of doing the clicks this way is obviously maintainability; if a link moves 10 px to the left, it will still be clicked just fine.
The idea for writing (and structuring) the tests is to first start with record/playback, then export the recording as a program in a supported programming language using supported assertions API (Java, JavaScript, Python, ... Pytest, Playwright Test, Jest, ...), and finally mold it into well-factored and maintainable test suite (by extracting common steps, creating helper functions, page objects, ...).
I considered Selenium with Python and Pytest, Selenium with Java and Junit, and Playwright with Typescript.
Python is the language of the router, and it is usually known by QA-minded folks. Java is statically typed (which I prefer), is used by ActiveMQ messaging projects (that also need webconsole testing), and should be also well known. JavaScript/TypeScript is the language of the webconsole, so the tests will be easily understood by anyone developing the webconsole.
Selenium Webdriver is old and well-known. Playwright is more recent iteration on the same theme, and it has nice test framework in TypeScript on top.
Both PlayWright and Selenium can run with headless browsers in Docker container.
For reverence, my tests from 2017 in Webdriver, Python binding, written for the Hawt.io Dispatch plugin, https://github.com/jirkadanek/dispatch-console-tests.
> Create automated webconsole tests using either Webdriver (Selenium) or Playwright
> ---------------------------------------------------------------------------------
>
> Key: DISPATCH-2221
> URL: https://issues.apache.org/jira/browse/DISPATCH-2221
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Console, Tests
> Reporter: Jiri Daněk
> Assignee: Jiri Daněk
> Priority: Major
> Fix For: 2.0.0
>
>
> Here's a reasonably recent overview of website end-to-end test automation tooling: https://www.testim.io/blog/puppeteer-selenium-playwright-cypress-how-to-choose/ (presentation https://www.youtube.com/watch?v=JuSF6BDs7Ow).
> End-to-end should mean that the test interacts with the Dispatch web console by sending clicks to the browser window. The clicks are targeted using CSS-like selectors (often button/link texts and aria selector), and they are dispatched through browser debug protocol, so it is not _exactly_ simulating the user, but it is simulating the user to a very great degree. The advantage of doing the clicks this way is obviously maintainability; if a link moves 10 px to the left, it will still be clicked just fine.
> The idea for writing (and structuring) the tests is to first start with record/playback, then export the recording as a program in a supported programming language using supported assertions API (Java, JavaScript, Python, ... Pytest, Playwright Test, Jest, ...), and finally mold it into well-factored and maintainable test suite (by extracting common steps, creating helper functions, page objects, ...).
> I considered Selenium with Python and Pytest, Selenium with Java and Junit, and Playwright with Typescript.
> Python is the language of the router, and it is usually known by QA-minded folks. Java is statically typed (which I prefer), is used by ActiveMQ messaging projects (that also need webconsole testing), and should be also well known. JavaScript/TypeScript is the language of the webconsole, so the tests will be easily understood by anyone developing the webconsole.
> Selenium Webdriver is old and well-known. Playwright is more recent iteration on the same theme, and it has nice test framework in TypeScript on top.
> Both PlayWright and Selenium can run with headless browsers in Docker container.
> For reverence, my tests from 2017 in Webdriver, Python binding, written for the Hawt.io Dispatch plugin, https://github.com/jirkadanek/dispatch-console-tests.
> I personally feel a deep dislike towards Cypress, but I have no factual basis for it, and in fact the tooling and the supporting documentation and some of the debugging features seem excellent https://github.com/muratkeremozcan/playwright-vs-cypress#readme.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org