[
https://issues.apache.org/jira/browse/DISPATCH-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469870#comment-17469870
]
ASF GitHub Bot commented on DISPATCH-2221:
------------------------------------------
jiridanek commented on pull request #1451:
URL: https://github.com/apache/qpid-dispatch/pull/1451#issuecomment-1006542577
In a subsequent discussion it was decided that we want to test websites with
JUnit + Selenium instead of this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> 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.
> * https://github.com/Microsoft/playwright/issues/8955
> * https://playwright.dev/docs/trace-viewer/#recording-a-trace
> * https://playwright.dev/docs/next/inspector/
> * https://github.com/microsoft/playwright/pull/8990
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
