You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2021/11/23 20:32:00 UTC

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17448254#comment-17448254 ] 

ASF GitHub Bot commented on DISPATCH-2221:
------------------------------------------

jiridanek opened a new pull request #1451:
URL: https://github.com/apache/qpid-dispatch/pull/1451


   Hi, I've put together the minimal amount of things that shows how this could look like
   
   https://www.youtube.com/watch?v=NM_C899M5MQ
   
   The video shows a sample test (which opens the Playwright homepage) and then a trivial assert-nothing test that clicks through the main sections of the dispatch console one by one.
   
   My goal is to have all the major parts in the PR, while not spending too much time on the tests and through that getting attached to something that has not yet been approved. I am hoping that Playwright will be acceptable automation technology, given its characteristics (see e.g. https://playwright.dev/docs/browsers/). I feel that the JavaScript/TypeScript API is the most appropriate one, given that console itself is written in that, and the console developers might not necessarily be too friendly with Python.
   
   One (minor) thing I haven't figured out is how to use Yarn 2 the right way. Other aspects, such as installing the headless browser, starting dispatch, and running the test in GitHub Actions, are there. One thing missing is storing artifacts on failure. Playwright can take browser event dumps for replay, and also record videos if a test failed.
   
   Next up, we have to agree on the test framework (see the Jira, where I considered Selenium, Playwright and Cypress) and decide what kind of tests we need. I am thinking for every CRUD form, try to create/delete/update router entities.


-- 
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: dev-unsubscribe@qpid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org