Open PeterKnealeCMRI opened 2 months ago
@jrobinso Using playwright/browser automation to do full end-to-end testing of igv.js works quite nicely. The markup you're generating is particularly clean which makes it very easy to write the matching test models for.
I noticed you had a selection of scenarios in the /dev folder and started writing assertions against a few of them as tests just as an experiment for now.
If you're interested: https://github.com/PeterKnealeCMRI/igv.js/wiki/End-to-End-tests-of-igv.js-via-Browser-Automation The only change I made to the igv codebase itself was add classes to the zoom in and zoom out divs in the zoom widget just to identify them a little more easily. Apart from that no changes.
@eternal-flame-AD Just tagging you there is a bit of overlap with your idea around typescript adoption.
@PeterKnealeCMRI Look interesting! I'm just posting to let you know I'm swamped with other issues, I will look into this as soon as I can find some time. Just leave it open until then. Thanks.
Also, BTW, the html under "dev" is not stable, that is a sandbox and items in there come and go as we develop. The code under "examples" is more stable. That however runs against the build igv.js.
I am going to be embedding
igv.js
in a small web application and wanted to add some browser automation tests usingplaywright
.I had a look at the markup generated by igv and while I can find the necessary elements eventually it would be nice if the
data-testid
convention was applied.Technically its also possible to do this with the css classes but overloading them with another purposes often causes issues as the styling and the semantics diverge over time.
I thought this might be something handy to add because it would enable both browser automation testing of igv.js itself and also let end users automate tasks by driving headless browsers against igv, manipulating controls and generating screenshots etc.